Проброс порта средствами iptables

Что-то вы не в ту сторону едете товариЩ! :) Все же просто, скажем так, первая доверенная машина подключается к серверу 1.1.1.1 и имеет внешний адрес 2.2.2.2 то есть на сервере разрешено хождение от 2.2.2.2 есть некая третья машина с адресом 3.3.3.3, которой не разрешено ходить на 1.1.1.1

Тогда все просто. С помощью NAT транслируйте пакеты от 3.3.3.3 через сервер 2.2.2.2 тогда сервер 1.1.1.1 будет думать что пакет пришел от 2.2.2.2 и все ок.

А вы порт пробрасываете зачем-то!

-A POSTROUTING -j MASQUERADE

Маскарадим все подряд, а потом удивляемся, что что-то не работает.

-A POSTROUTING -j MASQUERADE

Кстати, всё хочу на этот счёт SNAT/MASQ после DNAT --to-destination LOCAL_IP:port спросить. Инет полон «советов» без SNAT/MASQ, после чего в комментариях налетают «исправлятели», которые указывают, что «забыли» SNAT/MASQ. В ответ получают «спасибо». Всё это вызывает сплошное недоумение, ведь действительно если попробовать без SNAT/MASQ оно реально работает. Может это такой conntrack стал умный? Или что это вообще? Ничего уже не понимаю...

Кстати, всё хочу на этот счёт SNAT/MASQ после DNAT --to-destination LOCAL_IP:port спросить

Двойной NAT (SNAT+DNAT) нужен в очень ограниченном числе случаев.

Одно из условий работоспособности NAT - это симметричный роутинг, т.е. когда пакеты в обе стороны проходят через роутер выполняющий NAT.

Двойной нат приходится использовать когда делается редирект на адрес в той же сети. т.к. если не сделать SNAT, то ответ пойдет напрямую клиенту со всеми вытекающими последствиями.

Подскажите, как именно сделать то, что вы описали.

Одно из условий работоспособности NAT - это симметричный роутинг, т.е. когда пакеты в обе стороны проходят через роутер выполняющий NAT.

Спасибо. Торможу. Но, наверное, до сих пор. С SNAT теперь стало понятно: применяем тогда, когда пакеты после изменения destination без изменения source пойдут не через NAT.

Но с MASQUERADE же по другому. Он срабатывает только тогда, когда пакеты a) таки пройдут через NAT и б) только если во внешнем интерфейсе окажутся адреса внутренних, там и сработает маскарад по замене на внешний адрес. Но вопрос так у меня и остался: когда именно будет не работать без MASQ?

У вас опальная машина должна соединяться с LDAP по его настоящему адресу или можно временно назначить адрес и прокинутый порт на компе, которому сейчас разрешено?

SNAT и DNAT работают в разных цепочка и независимо друг от друга.

Функционально MASQUERADE == SNAT в условиях статических интерфейсов. Просто MASQUERADE использует SNAT с адресом исходящего интерфейса.

MASQUERADE нужен если у тебя маршрут наружу идет через разные интерфейсы или интенфейсы с динамическим адресом.

Хороший пример использования MASQUERADE для случая, когда есть несколько интерфейсов локальных и несколько внешних.

-t nat -A POSTROUTING -m set --match-set my_network src -m set ! --match-set my_network dst -j MASQUERADE

Функционально MASQUERADE == SNAT

Это теоретически. Практически для примера port-forward результат разный: при SNAT меняется src и сервис не может узнать адрес клиента, для него все соединения приходят от редиректора. При MASQ — с адресами всё нормально, но заменить на SNAT вне зависимости от наличия статики невозможно, так как невозможно угадать ни src ни dst port, они же у обратных пакетов оба динамические: один nat-овский, другой > 1024 у tcp ответный. Потому у этой задачи УЖАСНАЯ вечная путаница в ответах в Инете насчёт --dst(src)-port, ну полный ужас...

Должна соединяться хоть как-то, можно через адрес и порт разрешённого компа.

гм, если ты заглянешь в исходники ядра, то поймешь на сколько ты ошибаешься.

Посмотри файл net/netfilter/xt_nat.c и net/ipv4/netfilter/nf_nat_masquerade_ipv4.c - разница в 10 строк кода.

MASQUERADE и SNAT нужен для разных случаев.

Если что-то совсем непонятно с iptables, то есть TRACE. Там видно что происходит с адресами при прохождении пакета. Распечатай себе картинку - она объясняет некоторые странности реализации nat.

гм, если ты заглянешь в исходники ядра, то поймешь на сколько ты ошибаешься.

Да понятно, что оно почти не отличается. Дело в том, что если мы ставим SNAT, то мы либо получим NAT 1:1 либо нужно указать порт. А вот если мы ставим MASQ, то ни порт ни адрес с нас не требуют, даже интерфейс можно не указывать, что конечно, не хорошо.

Короче, вы тоже попались на ту проблему и не хотите вникать: почему при port-forward лучше всего юзать MASQ, хоть у нас и static. Хоть статью пиши. Наверное напишу. :(

Тогда у опальной уберите все PRE/POST, она тогда ничего не знает о трансляциях. А у компа, уберите ваши маскарады и сделайте SNAT. Вот тут же обсудили ваш случай, когда комп не шлюз по умолчанию для другого и далее по тексту.

iptables -t nat -A PREROUTING -d 10.10.1.59 -p tcp --dport 3129 -j DNAT --to-destination 33.33.33.33:636
iptables -t nat -A POSTROUTING -d 33.33.33.33 -p tcp --dport 636 -j SNAT --to-source 10.10.1.59

Почему-то не работает. Может, подскажете, как будет выглядеть правило для второго варианта, когда опальная машина стучится на внешний сервер, а перенаправление идёт через разрешённую? Самое обидное, что пару месяцев назад я открыл мануал и настроил всё как надо, а сейчас что-то не работает. За лапшу в правилах прошу прощения, просто уже идёт не первый час, все стандартные решения, которые выглядят логично с точки зрения официального мануала я перепробовал, потом в панике начал пихать всё подряд туда.

Если очень срочно и в панике, то проще всего через программный redir. Можете взять мой ftp://ftp.simtreas.ru/pub/my/redir-2.2-vodz.tgz и запустите типа так (на компе с доступом, это аналог вашего port-forward):

./redir --lport=3129 --laddr=10.10.1.59 --cport=636 --caddr=33.33.33.33 --syslog

Короче, вы тоже попались на ту проблему и не хотите вникать: почему при port-forward лучше всего юзать MASQ, хоть у нас и static. Хоть статью пиши. Наверное напишу. :(

гм. нету проблемы.

Есть 2 противоположных варианта

MASQ - если нам нужно, чтобы адрес SNAT выбирался на основе маршрута, а указать можно только диапазон портов.

SNAT - если нам нужно, чтобы адрес SNAT не зависил от маршрута и при этом мы можем указать и диапазон адресов и диапазон портов.

Фраза «лучше всего юзать» тоже абстрактная. Лучше написать 2 правила SNAT или одно MASQ ?

Когда будешь писать статью не забудь, что роутер с одной сетевой в локалке и второй сетевой в инет это распространенный, но не единственный вариант.

Зачем этот велосипед, если в xinetd эта возможность есть более 10 лет.

Зачем этот велосипед, если в xinetd эта возможность есть более 10 лет.

Наверное потому, что у меня оно ещё больше, мною лично подправлено пару плюх и полностью удовлетворило, ну и в слаке xinetd в комплект не входит.

Когда будешь писать статью не забудь, что роутер с одной сетевой в локалке и второй сетевой в инет это распространенный, но не единственный вариант.

Похоже вы не понимаете. Нет там никакого второго интефейса у ТСа, потому и POSTROUTING-а никакого нет. Есть OUTPUT, но на него SNAT/MASQ не повесишь. Но почему-то в Инете можно встретить радостное сообщение, что таки да, SNAT не работает, а вот MASQ — помог. Почему и теперь мне стало не понятно. Похоже таки придётся опять ебтаблесить... Времени пока с этим НГ нет, но вот-вот появится :)

Почему-то не работает.

Развернул лабораторию на 4 виртуалки с tcpdump-ом. Работает и так и если во второй поменять -d 33.33.33.33 на -s IP_опальной, что лучше. Не смущайте, а то уже в этой беготне чего только не напридумывал...

А мне вот не понятно, почему вам не понятно :) Разница между masq и snat емнип еще в iptables tutorial была достаточно доходчиво описана.

Но почему-то в Инете можно встретить радостное сообщение, что таки да, SNAT не работает, а вот MASQ — помог.

Про статику: Чаще всего в таких сообщениях ошибка в самом правиле snat, но так как не до конца от ТС понятно в чем конкретно ошибка, поэтому рекомендуют «для начала» попробовать masq. После чего обычно ТС сливается с радостным постом «спасибо все заработало».
Я сам грешен даю такие рекомендации, и не припомню что бы потом кто-то из ТС стал выяснять почему не работало с snat.

С динамикой, надеюсь понятно почему удобнее masq.

Лично для себя рассматриваю два плюса snat.
1. Строгость правила, меньше шансов ошибки.
2. Необходимо для случаев множества ip на одном интерфейсе.

Лично для себя рассматриваю два плюса snat.

Самого главного не написали: SNAT надо чтобы не ломать голову, как обеспечить прохождение обратных пакетов, сформированных DNAT-ом. Если это условие выполнено, то SNAT/MASQ не нужно вообще, а в советах «делай как я» это проговаривается только в каких-нибудь NAT-HOW_TO, а не в обычных.

Необходимо для случаев множества ip на одном интерфейсе.

Это правильно, но если ну очень специфическое надо. Ведь никакой трудности в простейшем случае тут у MASQ нет: указываете -o out_inf и оно само меняет src у этих пакетов на адрес у исходящего интерфейса, по которому и пойдут пакеты извне текущего тазика. SNAT тут надо только если вам зачем-то надо src не текущего исходящего интерфейса. Отсюда следствие, что без -o out_inf для множественных интерфейсов MASQ наоборот — милое дело.

Ведь никакой трудности в простейшем случае тут у MASQ нет: указываете -o out_inf и оно само меняет src у этих пакетов на адрес у исходящего интерфейса, по которому и пойдут пакеты извне текущего тазика.

Я написал "множество ip на одном интерфейсе". Например у меня на интерфейсе 5 ip хочу что бы выходил с ip номер три, для этого случая masq не подойдет он берет первый по списку.

Я написал «множество ip на одном интерфейсе».

А, я в голове держал текущий топик, а вы про вообще... Ну да, на свете бывает много всяких гитик.

Когда будешь писать статью не забудь, что роутер с одной сетевой в локалке и второй сетевой в инет это распространенный, но не единственный вариант.

Таки написал: Переключатель резервный/запасной канал на прозрачном мосте, не забирающий публичный IP