Как работает линуксовый нат (маскарадинг) не в случае tcp и udp?

Для gre(pptp) есть специальный модуль дабы клиенты за nat'ом могли подключаться.

Для icmp echo nat использует echo id в качестве доп. ключа.

c udplite проблем особых нет - порты используются как доп. ключ.

L2TPv3 - generic nat, в gre для pptp есть костыли, а все остальное - generic nat со всеми вытекающими ограничениями.

L2TPv3 - generic nat, в gre для pptp есть костыли, а все остальное - generic nat со всеми вытекающими ограничениями.

Можно про костыли подробнее и что такое generic nat?

gre/pptp-пакет имеет в себе некий id-шник который позволяет различать несколько pptp-туннелей к одному серверу + к этому хелпер, который парсит tcp-шное управляющее соединение.

generic nat (L3) это тупая замена одного из адресов пакета. В этом случае из внутренней сети на внешний адрес можно установить только одно работающее соединение.

Ну а если, скажем, generic nat будут использовать два клиента за натом к разным серверам с одним протоколом? И generic nat доступен по-дефолту для клиентов за натом или надо его настраивать?

к разным - проблем нет.

специально настраивать не нужно.

Прежде всего нужно определить термины. Соединение как сущность присутствует в tcp, и возможно некоторых других надстройках над ip. То есть есть чёткая последовательность инициализации соединения, передачи данных и завершения соединения (по таймауту или спец. пакетом). Т.к. TCP используется как основной для передачи данных по интернету, для него хелперов не нужно (по факту они есть, но идут как стандартный механизм работы NAT).

Теперь, что такое helper - это модуль ядра/функции ОС описывающие/реализующее понимание «соединение» ОСью для конкретного протокола (для gre, ftp, sip...). Но для этих вещей иногда нужно «влазить» в более глубокие слои протоколов, чтоб вычленить оттуда доп. параметры (порты сопутствующих соединений, айдишники и т.п. иногда даже иметь реализацию proxy для протокола). Ну а дальше по мотиву TCP поддерживать состояние соединения.

Для UDP в linux отдельная история, там используется хитрая схема идентификации соединения (src-ip, src-port, dst-ip, dst-port) и т.к. нельзя определить начало и конец этого соединения был введён параметр таймаута (который, кстати можно настроить через sysctl), который сбрасывается каждый раз, когда проходят пакеты с теми же параметрами IP-PORT. Ведь по UDP обычно передаются медиа-данные, которые передаются относительно постоянно, а когда прекращается обмен, по таймауту запись из NAT таблицы удаляется. Могу в этом месте ошибаться, т.к. вполне вероятно, что такой механизм используется как default для всех IP протоколов при отсутствии helper.

Про таймауты для псевдосоединений, udp и tcp я знаю. Меня интересует NAT для IP-проколов, отличных от них. Выше уже писали, что используются хелперы для ряда протоколов, эксплуатирующие их особенности. Но также писали про generic NAT, который будет работать для любого IP-протокола. Очень хотелось бы подробнее именно про это узнать.

generic NAT в линухе можно поднять но с изъё*ом, раньше команда ip позволяла без проблем сделать stateless NAT на один или группу айпишников. Могу ошибаться в терминологии, но там по видам full-cone и что-то ещё подобное. Аналогичные возможности имеет и фаервол (iptables), но с возможностью подключения хелпер-модулей, но ключевое слово с возможностью, то есть их можно и не подгружать и получится тот же stateless NAT. В общем, насколько я понял, то вот родной тупой подмены уже нет, т.к. я пытался её потестить на голом openwrt, не удалось этого сделать ни под каким соусом. Вполне допускаю, что для этого openwrt и не подходит, а на обычном x86 сервере всё работает.

В любом случае, раньше NAT можно было делать средствами iptables и средствами ip, и это были разные методы трансляции адресов. Собственно говоря, stateless NAT лучше всего работает при трансляции один-к-одному, что теряет все преимущества NAT, т.к. всё-равно на каждый серый айпишник приходится выделять реальник. Потому и перешли на statefull метод через iptables с хелперами.