Почему изменяется порт udp пакета после маскарада?

Question

[Arsolitt]

Два сервака имеют белые адреса, связал их через GRE туннель. Один сервер является шлюзом, который форвардит диапазон портов через туннель на второй сервер. На втором сервере приложения слушают и tcp и udp. На втором серваке маркирую пакеты, которые эти приложения выплёвывают и отправляю обратно в туннель. TCP трафик ходит как нужно, а вот с UDP какой-то прикол.

На сервере-шлюзе в tcpdump видно следующее:
Входящий tcp пакет пришёл на 100.100.100.100:31000 ушёл в туннель на 10.10.10.2:31000, вернулся из туннеля имея источник 10.10.10.2:31000, получает маскарад, становится 100.100.100.100:31000 и улетает клиенту, всё хорошо.

Udp пакет в свою очередь приходит на 100.100.100.100:31000, получает форвард в туннель на 10.10.10.2:31000, а возвращается из туннеля с источником 200.200.200.200:31000, получает маскарад и становится 100.100.100.100:рандомный_порт, соответственно клиент не получает в ответ ничего, потому что не ждёт рандомный порт.

Ниже накидал +- схему, все правила для tcp и udp одинаковые.

Подскажите, куда жмать, чтобы всё работало?? А лучше объясните, почему так происходит: изменяется sport после маскарада, и из туннеля возвращается пакет с saddr другого интерфейса. Полагаю, что-то с conntrack связанное, но я не знаю, как гуглить даже

Comments

[Антон Южный]

Имеются ли у вас еще правила iptables после "озвученных" по очередности? Может они применяются...

[ValdikSS]

Вы по какой-то причине намеренно такую сложную конфигурацию делаете, с NAT и маркировкой пакетов (а не соединений)?

Самый простой и правильный способ туннелирования так, как вы хотите:
1. На сервере слева оставляем только PREROUTING-часть (без POSTROUTING masquerade), в существующие PREROUTING-правила добавляем daddr 100.100.100.100
2. На сервере справа убераем всё текущее, добавляем только:

ip route add default dev gate-finl table 101
ip rule add from 10.10.10.2 table 101

Либо, вместо пункта 2, добавляем default-маршрут через gate-finl с метрикой выше, чем у основного, в таблицу маршрутизации по умолчанию, и bind'им программу, работающую с пакетами с этого интерфейса, на этот интерфейс (SO_BINDTODEVICE, bind на IP-адрес недостаточно). Всё.

[Arsolitt]

ValdikSS, конечно, причина очень проста, я нихрена не понимаю o_O

А разве без маскарада в построутинге не будет такого, что пакет пришедший из туннеля пакет полетит клиенту имея сурс адрес 10.10.10.2? Я не проверял в текущей конфиге, просто где-то уже использовал и тут добавил

Забиндить софтину на интерфейс не вариант, а вот способ с маршрутизацией мне нравится, спасибо. Но вопрос остаётся открытым, будут ли udp пакеты бегать правильно?

Я пока на костыль поставил, сделал маскарад на udp трафик, который в туннель летит, и всё работает, но второй сервак естественно видит сурс адрес шлюза, а не клиента.

[Arsolitt]

Антон Южный, имеются само собой, но к этой конфиге не имеют отношения. Я конечно шиз, но мешать они там не могут

[ValdikSS]

Arsolitt,

А разве без маскарада в построутинге не будет такого, что пакет пришедший из туннеля пакет полетит клиенту имея сурс адрес 10.10.10.2?

Да, вы правы. Попробуйте в ваше правило добавить еще проверку на исходящий интерфейс. И вы с oif не ошиблись? У вас на картинке ens1, а в правиле ens3.

[Антон Южный]

Arsolitt, а причем тут конфиг, правила если применяются то применяются на весь сервер...

[Balling]

100.64.0.0/10 это CG-NAT, а не белые IP.

Answer 1

[Владимир Пилипчук]

Udp натится с оговорками. И одна из причин прописана в rfc. И порт обязательно будет меняться. Только конусный нат возможен.
Читайте разницу в трансляциях tcp и udp.