LINUX.ORG.RU
Форум — Admin  

iptables MASQUERADE — вопрос.

 


1

2 
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

При пробрасывании пакетов из локальной сети, подменяет исходящий адрес пакета на адрес самого шлюза. Для удалённого хоста всё выглядит так, как будто сам шлюз отправил этот пакет.

Но ведь удалённый хост будет отвечать на адрес шлюза, то есть шлюз должен как-то понять что ответ от данного IP на данный port следует пробросить обратно именно на тот хост из локалки, который всё это начал. То есть, должно срабатывать что-то из цепочки PREROUTING, ведь ответный пакет от удалённого узла с точки зрения нашего шлюза будет входящим.

Но во всех мануалах сказано, что достаточно добавить описанное выше правило в POSTROUTING и netfilter автоматически начнёт пробрасывать и ответные пакеты на локальный хост.

Но эта «автоматическость» путает. Непонятно, куда ещё дополнительно добавилось какое правило (в PREROUTING?), чтобы входящий ответный пакет от удалённого хоста был проброшен именно на тот локальный хост, который послал из локалки запрос удалённому хосту?

Что произошло буквально, какие правила куда ещё добавились при исполнении вышеприведённого правила?

Перемещено leave из development

Входящие пакеты не попадают в PREROUTING. Они уже пришли, их не надо маршрутизировать. Более того, в PREROUTING попадает обычно только первый пакет из всего TCP соединения, потом уже работает route cache. MASQUERADE, а так же SNAT и DNAT, добавляют запись в conntrack, который как раз и помнит как адреса переписывать.

const86 ★★★★★
()

Но эта «автоматическость» путает. Непонятно, куда ещё дополнительно добавилось какое правило

Никакие правила никуда не добавлялись. Гугли как работает connection tracking в ядре и не пори чушь.

Грубо говоря, если у тебя есть правило

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

или(для древних систем):

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

То ответные пакеты будут проходить по этому правилу. А как они уже будут натиться - этим заведует conntrack, точнее - соответствующие ему NAT-модули.

Но ведь удалённый хост будет отвечать на адрес шлюза, то есть шлюз должен как-то понять что ответ от данного IP на данный port следует пробросить обратно именно на тот хост из локалки, который всё это начал

И он это прекрасно поймет, заглянув в таблицу conntrack-а, где хранятся адреса и номера портов как до, так и после NAT-а

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от const86

Наверное точнее сказать не пакеты «уже пришли», а пакеты соотнесены с установленными соединениями системой conntrack?

kiverattes ★☆
() автор топика
Ответ на: комментарий от Pinkbyte

Спасибо. Но наверное корректнее сказать не «ответные пакеты будут проходить по этому правилу», а что ответные пакеты будут перехвачены conntrack, то есть TCP-стеком ещё до iptables? Ну то есть это правило тут уже ни при чём...

kiverattes ★☆
() автор топика
Ответ на: комментарий от kiverattes

будут перехвачены conntrack, то есть TCP-стеком

conntrack есть для всех IP-пакетов, даже для ICMP и UDP(иначе нормального NAT-а для этих протоколов бы не было). Да, да, механизм состояний для UDP протокола :-)

Для хитрых протоколов, передающих адрес внутри пакетов есть специальные nat-модули(например FTP, SIP), которые меняют содержимое пакетов соответствующим образом

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от kiverattes

Да, там всё страшно :-) Там ещё есть политики xfrm (это когда речь заходит от ipsec), они тоже модифицируют пакеты.

А, если вам интерестно про NAT, то есть команда ″conntrack -L″, она выведет какие есть записи в таблице и как приходящие пакеты будут модифицированные (отНАТчены обратно).

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin