SNAT & DNAT
-
- Маньяк
- Сообщения: 179
- Зарегистрирован: 27 май 2002, 16:04
- Откуда: Moscou
- Контактная информация:
SNAT & DNAT
если в iptables присутствуют "модули" SNAT и DNAT, то они работают сообща надо полагать.
Ведь:
Например DNAT после подмены адреса "метит в таблице отображения портов" этот пакет. Эта информация должна быть доступна SNATу.
Хотя....
--
Задам вопрос по другому:
Делает ли что-нибудь SNAT c обратным пакетом? Если да, то по какому праву, ведь мы записали следующее правило:
iptables -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
говорящие преобразовывать пакет на выходе после принятия решения о маршрутизации
..
Ведь:
Например DNAT после подмены адреса "метит в таблице отображения портов" этот пакет. Эта информация должна быть доступна SNATу.
Хотя....
--
Задам вопрос по другому:
Делает ли что-нибудь SNAT c обратным пакетом? Если да, то по какому праву, ведь мы записали следующее правило:
iptables -t nat -A POSTROUTING -o $INET_IFACE -j SNAT --to-source $INET_IP
говорящие преобразовывать пакет на выходе после принятия решения о маршрутизации
..
Учись или уходи!
TechNoir, несколько не понял.
SNAT никак не завязан на DNAT. Если делается DNAT то надо делать и SNAT/MASQUERADE на общих основаниях. В вышеописаном случае пакет уйдет с того же интерфейса но с другим IP. Если надо именно перебросить пакет на другой интерфейс то это делается иначе.
SNAT никак не завязан на DNAT. Если делается DNAT то надо делать и SNAT/MASQUERADE на общих основаниях. В вышеописаном случае пакет уйдет с того же интерфейса но с другим IP. Если надо именно перебросить пакет на другой интерфейс то это делается иначе.
Опыт растет прямо пропорционально выведенному из строя оборудованию
-
- Маньяк
- Сообщения: 179
- Зарегистрирован: 27 май 2002, 16:04
- Откуда: Moscou
- Контактная информация:
Llama, ты прав, SNAT никак не завязан с DNAT. Это проверено.
Более того!!!
Здесь ты похоже не прав:
DNAT тоже никак не связан с SNAT/MASQUERADE.
Только что проверил.
Убраны были мною только что все правила SNAT, оставлены только DNAT - все чудненько работает.
Это подтверждает мою "версию" о том что эти "модули" самодостаточны.
То есть каждый из них обслуживает и обраный пакет/соединения руководствуясь каждый своей таблицей соответствий.
Более того!!!
Здесь ты похоже не прав:
DNAT тоже никак не связан с SNAT/MASQUERADE.
Только что проверил.
Убраны были мною только что все правила SNAT, оставлены только DNAT - все чудненько работает.
Это подтверждает мою "версию" о том что эти "модули" самодостаточны.
То есть каждый из них обслуживает и обраный пакет/соединения руководствуясь каждый своей таблицей соответствий.
Учись или уходи!
-
- Маньяк
- Сообщения: 179
- Зарегистрирован: 27 май 2002, 16:04
- Откуда: Moscou
- Контактная информация:
Представим:TechNoir писал(а): Убраны были мною только что все правила SNAT, оставлены только DNAT - все чудненько работает.
SNAT:
пакет идет наружу из приватной сети.
соответсвенно проходит через SNAT.
Что происходит с пакетом: меняется его source адрес, меняется его source порт. В таблицу соответствий заносится запись был порт такой -то, стал такой -то. Пакет возвращается, возвращаем source адрес, возвращем "старый" порт. Клиент ничего не заметил, сервер ничего не заметил.
DNAT: Пакет идет от клиента находящего в интернете. Что происходит с пакетом. В нем достаточно подменить только destination адрес.
В обратном пакете DNAT должен вернуть только измененный адрес и ВСЕ!!!
Если вдруг случится так что обратный пакет пройдет через SNAT - ничего работать не будет. Логично?
Учись или уходи!
-
- Неотъемлемая часть форума
- Сообщения: 354
- Зарегистрирован: 22 сен 2004, 13:47
- Откуда: Minsk
- Контактная информация:
Не совсем так... Можно подменять и портTechNoir писал(а):DNAT: Пакет идет от клиента находящего в интернете. Что происходит с пакетом. В нем достаточно подменить только destination адрес.
В обратном пакете DNAT должен вернуть только измененный адрес и ВСЕ!!!
Вот что пишут в man iptables:
Код: Выделить всё
--to-destination ipaddr[-ipaddr][:port-port]
Судя по тому что:Llama писал(а):В обратном пакете должен быть измене source address. Т.е. должен быть сделан фактически SNAT. Насколько я знаю, DNAT _не_ отслеживает соединение, соответсвенно - если пакет приходит из другой ip-сети то работать не будет без SNAT.
Код: Выделить всё
CONFIG_IP_NF_CONNTRACK
This is required to do Masquerading or other kinds of Network Address Translation (except for Fast NAT).
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT --to-destination $HTTP_IP
В соответствии с этим правилом, все пакеты, поступающие на 80-й порт адреса $INET_IP перенаправляются на наш внутренний WEB-сервер. Если теперь обратиться к WEB-серверу из Интернет, то все будет работать прекрасно. Но что же произойдет, если попробовать соединиться с ним из локальной сети? Соединение просто не установится. Давайте посмотрим как маршрутизируются пакеты, идущие из Интернет на наш WEB-сервер. Для простоты изложения примем адрес клиента в Интернет равным $EXT_BOX.
1.Пакет покидает клиентский узел с адресом $EXT_BOX и направляется на $INET_IP
2.Пакет приходит на наш брандмауэр.
3.Брандмауэр, в соответствии с вышеприведенным правилом, подменяет адрес назначения и передает его дальше, в другие цепочки.
4.Пакет передается на $HTTP_IP.
5.Пакет поступает на HTTP сервер и сервер передает ответ через брандмауэр, если в таблице маршрутизации он обозначен как шлюз для $EXT_BOX. Как правило, он назначается шлюзом по-умолчанию для HTTP сервера.
6.Брандмауэр производит обратную подстановку адреса в пакете, теперь все выглядит так, как будто бы пакет был сформирован на брандмауэре.
7.Пакет передается клиенту $EXT_BOX.
А теперь посмотрим, что произойдет, если запрос посылается с узла, расположенного в той же локальной сети. Для простоты изложения примем адрес клиента в локальной сети равным $LAN_BOX.
1.Пакет покидает $LAN_BOX.
2.Поступает на брандмауэр.
3.Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.
4.Пакет покидает брандмауэр и отправляется на HTTP сервер.
5.HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.
6.Пакет поступает на $LAN_BOX. Клиент "путается", поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент "сбрасывает" пакет ответа и продолжает ждать "настоящий" ответ.
Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.
iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT --to-source $LAN_IP
цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.
-
- Маньяк
- Сообщения: 179
- Зарегистрирован: 27 май 2002, 16:04
- Откуда: Moscou
- Контактная информация:
Hermit
Все классно сказано.
--
Важно то что SNAT и DNAT работают над пакетами в обоих направлениях. то бишь как говорится отслеживают соединение.
Отправляя в цепочке POSTROUTING пакеты в SNAT мы как бы даем команду отправлять обратные пакеты в некую абстрактную цепочку PREROUTING некоторой абстрактной таблицы (во блин сказал ) в которой не осуществляется никакой фильтрации.
и что - то похоже но наоборот для DNAT
Все классно сказано.
--
Важно то что SNAT и DNAT работают над пакетами в обоих направлениях. то бишь как говорится отслеживают соединение.
Отправляя в цепочке POSTROUTING пакеты в SNAT мы как бы даем команду отправлять обратные пакеты в некую абстрактную цепочку PREROUTING некоторой абстрактной таблицы (во блин сказал ) в которой не осуществляется никакой фильтрации.
и что - то похоже но наоборот для DNAT
Учись или уходи!