В IPTables работает маскарад только на новых соединениях (SYN пакетов)?
BitTorrent Sync не является свободным программным обеспечением.
Условия авторской лицензии не позволяют сделать его пакетом FreeBSD, запрещая кому-либо, кроме самой BitTorrent Incorporated, (повторное) распространение программы. (Порт BSD не содержит самого программного обеспечения; пакет содержит).
Вы не будете разбирать, декомпилировать, перепроектировать или иным образом пытаться обнаружить исходный код Программного обеспечения, полностью или частично, за исключением случаев, явно разрешенных законом, или распространять его.
Документ FreshPorts предупреждает, что это относится к некоторым портам.
Дальнейшее чтение
- "Что такое пакет?". Определения для безнадежно ленивых. FreshPorts.
- Лицензионное соглашение с конечным пользователем - Sync (Pro и API). BitTorrent Incorporated. 2015-09-08.
- Лицензионное соглашение с конечным пользователем - Sync (Free). BitTorrent Incorporated. 2015-02-06.
- "Порты с ограничениями на распространение или юридическими проблемами". FreeBSD Porter's Handbook. Проект документации FreeBSD. 2014-08-08.
Идентификатор соединения TCP определяется набором из четырех вещей:
- IP-адрес конечной точки A
- IP-адрес конечной точки B
- номер порта конечной точки A
- номер порта конечной точки B
Стандарт протокола TCP говорит, что если какой-либо из этих четырех элементов изменяется,пакет не должен рассматриваться как часть одного и того же соединения. В результате нет смысла начинать применять правило NAT к пакету SYN/ACK, если исходный SYN также не был NAT. Вы должны либо применить один и тот же тип сопоставления NAT для всего соединения от начала до конца, либо вообще не использовать NAT; любая попытка добавить или изменить сопоставление NAT в середине соединения -приведет к сбою TCP-соединения. Это фундаментальный факт протокола TCP, и код Linux iptables/netfilter разработан с учетом этого.
В вашем случае 2 )SYN/ACK предшествует SYN из 10.b/16. Этот SYN имеет источник 10.b/16, поэтому он не соответствует правилу MASQUERADE и маршрутизируется с адресами, сохраненными как -. Затем, , если SYN/ACK из 10.a/16 обратно в 10.b/16 будет переведен , отправитель исходного SYN больше не распознает его как ответ на свой собственный SYN, так как комбинация IP-адреса источника + IP-адреса назначения + исходный порт + порт назначения будет отличаться от того, что ожидается для действительного ответа.
По сути, драйвер протокола TCP в системе, которая инициировала соединение в 10.b/16, будет думать :«Эх. 10.a.connection.destinationне отвечает. И 10.b.NAT.systemбеспокоит меня явно ложными SYN/ACK :Я пытаюсь соединиться с 10.a.connection.destination, а не с ним. Если у меня будет время, я отправлю один или два RST 10.b.NAT.system; надеюсь, он осознает свою ошибку и перестанет меня беспокоить».
Это происходит потому, что когда пакет идет в противоположном направлении, его источник 10.b/24, а пункт назначения 10.a/24, что означает, что он не будет обрабатываться вашим правилом. Вы должны добавить два правила, чтобы MASQUERADE происходил:
-t nat -A POSTROUTING -s 10.a.0.0/16 -d 10.b.0.0/16 -j MASQUERADE
-t nat -A POSTROUTING -s 10.b.0.0/16 -d 10.a.0.0/16 -j MASQUERADE
MASQUERADE — это просто SNAT (исходный NAT )с источником исходящего интерфейса (см. man iptables-extensions.
Попытка подключения (начальный SYN )подвергается NAT, а затем соединение отслеживается в ядре ("conntrack" ), и все пакеты в этом соединении проходят NAT в соответствующем направлении.
Так что да, исходящие ответы SYN/ACK на входящие SYN не будут преобразованы SNAT в NAT. Если вы хотите использовать NAT для входящих SYN, вам нужен DNAT, а не SNAT. Это также будет транслировать ответы SYN/ACK.