iptables: DNAT&SNAT

Разница в нагрузке между SNAT и MASQUERADE минимальна. Возможно, это и имело значение раньше, когда машины были значительно слабее, но сейчас уже разницы нет.

Более того, SNAT нужен для конкретных сервисов, а в режиме динамического NAT на адрес интерфейса для всего подряд, то есть MASQUERADE, SNAT ничем не будет отличаться.

Тут больше одного варианта, если чисто ради интереса смотрите tcpdump и поймете что действительно «делает» MASQ и сравните с тем что написали вы с правилом SNAT.
Насчет нагрузки вам все правильно написали выше.

В каких случаях правильнее snat? Мне нужно перенаправлять rtsp поток. Хочется сделать это правильно и с оптимальной нагрузкой.

А вы действительно всё сделали, например как в этой статье: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-alg...

Rtsp-поток использует 554 порт. Если я делаю через MASQUERADE, то поток идет. Через snat не идет. Посмотрел статью, по-моему не совсем то, что нужно.Даже если абстрагироваться от rtsp. допустим я просто хочу на web-сервер попасть. Т.е. ПК1 с web-сервером подключается к vpn-серверу(ПК2). Я хочу с ПК3 подключится к ПК2 и попасть на страничку ПК1. Ситуация с iptables будет аналогичная. MASQUERADE работает, SNAT- нет.

Ситуация с iptables будет аналогичная. MASQUERADE работает, SNAT- нет.

Ну вы же понимаете, что раз у всех работает, значить вы что-то не так делаете? В конце концов, раз документация не помогает, ну попробуйте методом тыка: поставьте анализатор пакетов и сравните в чём разница.

Да, я понимаю, что я что-то не так делаю.:) Поэтому я здесь. Думал, может явно ошибка в синтаксисе, например. Буду пробовать анализатор пакетов.

Я поразбирался! Выяснилось что правило snat внутри одной подсети работает. Не работает между подсетями только. Я сделал вывод, что forwarding нужно включить дополнительно. Сделал так:

iptables -A FORWARD -i ppp1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp1 -j ACCEPT

Проверка работает ли FORWARD делается элементарно, убирается любой запрет на FORWARD, в том числе и в политике («iptables -P FORWARD -j ACCEPT») :) Собственно так любая задача на практике решается - временно убираются все защиты, добиваются работоспособности, а потом включается и проверяется.

В первом сообщении у вас eth1, а теперь eth0. И кстати, default у вас в каком ethX? Ведь masquerade собственно и выбирает автоматически адрес до удаленной стороны на основе маршрута.

У меня eth0 - подсеть 192.168.0.Х, eth1 - ...1.X. Оба выходят в интернет, но через маршрутизаторы. И на этом же сервере сервер pptp. Я проверяю с ПК, который в подсети 0.Х. Т.е. ломлюсь на eth0. Сервер должен перенаправить меня в ppp1 и ответ вернуть в eth0. В дальнейшем планирую удаленные подключения совершать через eth1. Поэтому изначально указывал в правилах eth1. именно этот интерфейс - default. Про masquerade я понял, что его задача автоматическое определение адреса указанного интерфейса для цепочки POSTROUTING. Актуально с динамическими адресами. Отсюда и бОльшая нагрузка на проц, чем при использовании SNAT когда мы явно указываем адрес. А так суть действия одна получается. Теперь по поводу forwarding. Если взять исходными данными, что таблицы iptables очищены и кроме двух правил PROROUTE и POSTROUT нет. Никаких фильтров и дропов. У меня нет значит никаких запретов на forwarding?

Оба выходят в интернет, но через маршрутизаторы. И на этом же сервере сервер pptp. Я проверяю с ПК, который в подсети 0.Х. Т.е. ломлюсь на eth0. Сервер должен перенаправить меня в ppp1 и ответ вернуть в eth0.

Не совсем понятно, зачем вам для локалки и VPN вообще NAT. Собственно VPN для того и служит, чтобы локальные адреса маршрутизировались, а не натились. Если сервер pptp не маршрут по умолчанию для локалки, то чтобы никуда не натить, можно выбирать адреса для ppp в самой сети эзернета, с опцией proxyarp.

У меня нет значит никаких запретов на forwarding?

Если, конечно, не потеряли единичку в /proc/sys/net/ipv4/ip_forward

В /proc/sys/net/ipv4/ip_forward как и положено единичка. Про proxyarp почитаю. Но основной нюанс в том, что мне нужно перенаправлять конкретные порты, а не весь траффик. В какую сторону еще копнуть, чтобы заставить идти пакеты через snat между eth и ppp?

ЗАРАБОТАЛО! Поменял в строке

iptables -t nat -A POSTROUTING -o ppp1 -j SNAT --to-source "ip_eth0" на "ip_pptp_server" (10.10.3.1)

Ну собственно это и делает masquerade как раньше сказано — выбирает адрес с которого будет идти по маршрутизации. Чтобы не было лишних адресов, локальный адрес у point-to-point интерфейсов должен быть равен локальному адресу eth.

NAT, конечно, открывает порты, но использовать его в режиме файрвола не очень правильное решение. Сегодня вам один порт надо, завтра - пять с пингом...

Поправка на ветер!=) С разных машин одновременно попробовал подключиться. На второй коннект был недолго, теперь его нет. Видимо что-то все-таки не так.

Если nat не очень правильное решение (мне нужно пробрасывать несколько портов на одно ppp подключение). А таких подключений тоже несколько. Что почитать? Спасибо за помощь.

Если вы делаете DMZ, то просто редиректите порты, а ppp пусть знает о всех адресах в вашей сети, тогда SNAT/MASQ не потребуется. Если это удалённый хост локалки, то вообще не надо извращаться, обеспечьте маршрутизацию и управляйте доступом межсетевым экраном без всякого NAT.

DMZ точно не вариант. Я правильно понял, что можно маршрутизацию построить через iptables, но не в таблице nat?

можно маршрутизацию построить через iptables, но не в таблице nat?

Это что-то странное вы сказали. Маршрутизация - отдельная подсистема стека: выбор направления выходного интерфейса. iptables влияет на маршрутизацию именно nat-ом, это никак не «строить», это модификация для изменения направления при PREROUTING и адреса для возможности маршрутизации удалённой стороной при POSTROUTING.