Как передать реальный IP при переадресации NAT с помощью iptables?

Question

[Серёга]

Есть VPS. Цель с VPS направлять трафик в локальную сеть серверам за домашним роутером. Микротик подключен к VPS по туннелю Wireguard. Адрес Микротика интерфейса Wg 10.9.9.5, адрес шлюза Wg 10.9.9.1. Локалка за Микротиком 192.168.1.0/24.
На VPS открыт порт и сделана переадресация:

sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

sudo iptables -t nat -A PREROUTING --dst 90.100.131.195 -p tcp --dport 443 -j DNAT --to-destination 10.9.9.5
sudo iptables -t nat -A POSTROUTING --dst 10.9.9.5 -p tcp --dport 443 -j SNAT --to-source 10.9.9.1
sudo iptables -t nat -A OUTPUT --dst 90.100.131.195 -p tcp --dport 443 -j DNAT --to-destination 10.9.9.5
sudo iptables -I FORWARD 1 -i ens3 -o wg0 -d 10.9.9.5 -p tcp -m tcp --dport 443 -j ACCEPT

Трафик из вне прилетает на интерфейс ens3 и перенаправляется в туннель Wg интерфейс wg0, Микротик в свою очередь принимает и перенаправляет трафик из туннеля Wg в локальную сетку на сервер 192.168.1.100.
Трафик ходит, всё хорошо, кроме того, что система безопасности сервера не видит реального IP клиентов, а видит любого приходящего как IP шлюза 192.168.1.1. Из-за этого возникаем множество проблем.
Спросите, а зачем ещё на микротике перенаправление? Ну так мне удобнее, но... Я пробовал и другой вариант. Прописал на VPS в Wg доступ сразу к локалке. Перенаправление в VPS iptables сделал сразу на 192.168. 1.100. Но проблема та же, все клиенты определяются адресом шлюза 192.168.1.1. Я мониторил трафик микротиком, он уже получает трафик без реального IP, все они локальные, стало быть они не передаются от VPS, а не теряются в самом микротике, как можно подумать.
Скажете - используй обратный прокси. Ответ НЕТ. Потому, что львиная доля - это не http/https трафик, и даже не только tcp. Для проброса в nginx требуется модуль stream. Я поставил его. Но он тоже не уметь передавать реальный исходный IP. Он умеет только вырвать реальный IP из заголовков http трафика. У меня не http трафик.
Какие есть варианты дотащить до конечного сервера реальный IP? Может это делается каким-то другим софтом? Или хитрые правила писать надо?
Порт 443 тут как пример. Там ещё и ftp и webdav, ssh, rdp... А весь смысл VPS - получить реальный белый IP, так как провайдер не даёт.

Comments

[Alexey Dmitriev]

Что это "система безопасности сервера"?

[Серёга]

Это что-то типа файрволла. Отслеживает активность, в том числе и по IP, трафик, ведёт логи, блокирует по разным признакам, по IP, по юзернейм и т.д.

Answer 1

[shurshur]

Нужно убрать SNAT в POSTROUTING и на приёмнике маршрутизировать ответные пакеты в VPN. Тогда сервер-получатель будет видеть реальные адреса. Но придётся или весь интернет на той стороне завернуть в VPN (сделать дефолтный роут в VPN, что может быть неприемлемо), или упражняться с policy routing.

Объяснения по поводу настройки policy routing см. Сложная маршрутизация на linux роутере. Как правильно готовить policy based routing?

Второй вариант - поставить на VPS nginx и передавать IP в заголовках http. На той стороне доработать/донастроить своё веб-приложение, что оно умело брать IP из заголовка X-Forwarded-For или X-Real-Ip. Но это только для http.

Comments

[Серёга]

Нужно убрать SNAT в POSTROUTING и на приёмнике маршрутизировать ответные пакеты в VPN.

Начал копать тут: https://www.reddit.com/r/selfhosted/comments/qr4tb...
Потом это: https://github.com/mochman/Bypass_CGNAT
В итоге добавил в конфиг wg такое:

PostUp = iptables -t nat -A PREROUTING -p tcp -i ens3 '!' --dport 22 -j DNAT --to-destination 10.9.9.5; 
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j SNAT --to-source 90.100.131.195
PostUp = iptables -t nat -A PREROUTING -p udp -i ens3 '!' --dport 51820 -j DNAT --to-destination 10.9.9.5;

PostDown = iptables -t nat -D PREROUTING -p tcp -i ens3 '!' --dport 22 -j DNAT --to-destination 10.9.9.5; 
PostDown = iptables -t nat -D POSTROUTING -o ens3 -j SNAT --to-source 90.100.131.195 
PostDown = iptables -t nat -D PREROUTING -p udp -i ens3 '!' --dport 51820 -j DNAT --to-destination 10.9.9.5;

Теперь весь трафик (кроме порта 22 и 51820) приходящий на внешний порт VPS перенаправляется в туннель WG и прилетает в Микротик, что, собственно, и требовалось в идеале. Я вижу это запустив в Микротике Torch. Внешние адреса приходят неизменённые.
Но теперь я не могу настроить отправку обратных пакетов. Они только приходят, и обратно не отправляются. Уже разные правила добавлял, ничего не помогло. Как правильно сделать?

[shurshur]

Серёга, вот в этом и заключается задача policy routing.

Можно начать с чтения ссылки в моём ответе. Я там помогал решить подобную проблему.

По сути надо сделать так, чтобы на конечном сервере было две таблицы маршрутизации. В одной (main, таблица по умолчанию) был дефолт такой, какой всегда. В другой (условно назовём её wg) был маршрут default via 10.9.9.1.

И добавить правило: ip rule from 10.9.9.5 lookup wg.

По ссылке я предлагаю для каждого провайдера задавать свою таблицу, чтобы переключениями default в таблице main можно было менять основного провайдера и при этом ничего не делать для сохранения policy routing на обоих провайдров. В случае с VPN имеет смысл задавать только одну таблицу, для VPN, потому что тут не будет переключений дефолта в main.

Пакет будет прилетать из wg с адресом получателя 10.9.9.5. Получатель будет обрабатывать пакет и посылать ответ с тем же адресом. Раньше он шёл по дефолту в таблице main, что было, мягко говоря, немного нехорошо. Теперь же он по списку правил (ip rule) будет находить правило from 10.9.9.5 и проваливаться в таблицу wg. А там default через другой шлюз.

Answer 2

[Drno]

через iptables - никак

Answer 3

[AlexVWill]

Судя по всему, тебе надо либо STUN сервер, либо что-то подобное, потому что по сути ты пытаешься наладить p2p. Как то примерно так: https://voxlink.ru/kb/asterisk-configuration/obzor...
Эта щтука как раз просто говоря предназначена для того, чтобы все устройства за NAT'ом видели свои реальные IP и в зависимости от этого применяли те или иные правила маршрутизации или действия.

Answer 4

[Dmitry]

Два варианта:
1. Вам нужно сделать проброс порта с VPS до конечного сервера без NAT на посредниках
На VPS сделайте маршрут к интрасети сервера. И настройте проброс порта на VPS уже на локальный адрес сервера.
2. Либо, если с VPS не должно быть доступа к интрасети, вы можете поднять обратный веб прокси на VPS и с него проксировать трафик на адрес микрота, на микроте делаете NAT порта в конечный сервер. В таком случае, это уже L7 уровень, IP адрес клиента будет передаваться в рамках протокола HTTP(s)

Рекомендую пойти по второму пути