iproute2 и двойной nat
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- member
- Сообщения: 22
- Зарегистрирован: 08 дек 2006, 16:47
- Откуда: Астрахань
- Контактная информация:
iproute2 и двойной nat
Привет всем! Возникла интересная проблема. Пока не нашёл способов с ней биться. Может кто сталкивался с таким и знает решение это проблемы? Итак:
Имеем сервер с 3 сетевыми картами (одна смотрит в локалку, две в интеренет: основной и резервный каналы)
eth0 (192.168.0.150) - локалка
eth1 (a.a.a.a) - основной канал
eth2 (b.b.b.b) - резервный канал
сделанны следующие правила iproute2:
ip route add default via шлюз_основного table 1
ip rule add from a.a.a.a table 1
ip route add default via шлю_резервный table 2
ip rule add from b.b.b.b table astel
ip ro add default a.a.a.a
всё, ответы у нас уходят в теже интерфейсы, откуда и пришёл запрос.
едем дальше. в локальной сети есть сервер 192.168.1.175
на него сделан маппинг с внешних адресов:
$IPTABLES -t nat -A PREROUTING -p tcp -i eth1 -d a.a.a.a --dport 20240 -j DNAT --to-destination 192.168.1.175:2775
$IPTABLES -t nat -A PREROUTING -p tcp -i eth2 -d b.b.b.b --dport 20240 -j DNAT --to-destination 192.168.1.175:2775
НО!!! доступ к этому серваку возможен только с адресов локальной сети, поэтому прежде чем пустить пакет, мы его натим:
$IPTABLES -t nat -I POSTROUTING -o eth0 -d 192.168.1.0/24 -j SNAT --to-source 192.168.0.150
и, соответственно, когда пакет будет идти в интернет, его ещё раз надо отнатить:
$IPTABLES -t nat -I POSTROUTING -o eth1 -s 192.168.0.0/16 -j SNAT --to-source a.a.a.a
$IPTABLES -t nat -I POSTROUTING -o eth2 -s 192.168.0.0/16 -j SNAT --to-source b.b.b.b
А теперь, собственно, проблема...
когда клиенты стучаться на а.а.а.а:20240 - всё ок, так как на этом интерфейсе у меня дефолт гейтвей
а вот когда они стучаться на eth2 b.b.b.b:20240, ответ им уходит через a.a.a.a (eth1)
Замеченно, что такой полярный лисиц происходит именно тогда, когда используется 2-ой натинг. Если, скажем, сделать маппинг на другой адресб при этом внешний адрес не превращать в локальный, то всё ок.
Вот такие грабли. Это баг или фича? И как с ней бороться, кроме как отключить натинг внешних адресов в локальные?
Имеем сервер с 3 сетевыми картами (одна смотрит в локалку, две в интеренет: основной и резервный каналы)
eth0 (192.168.0.150) - локалка
eth1 (a.a.a.a) - основной канал
eth2 (b.b.b.b) - резервный канал
сделанны следующие правила iproute2:
ip route add default via шлюз_основного table 1
ip rule add from a.a.a.a table 1
ip route add default via шлю_резервный table 2
ip rule add from b.b.b.b table astel
ip ro add default a.a.a.a
всё, ответы у нас уходят в теже интерфейсы, откуда и пришёл запрос.
едем дальше. в локальной сети есть сервер 192.168.1.175
на него сделан маппинг с внешних адресов:
$IPTABLES -t nat -A PREROUTING -p tcp -i eth1 -d a.a.a.a --dport 20240 -j DNAT --to-destination 192.168.1.175:2775
$IPTABLES -t nat -A PREROUTING -p tcp -i eth2 -d b.b.b.b --dport 20240 -j DNAT --to-destination 192.168.1.175:2775
НО!!! доступ к этому серваку возможен только с адресов локальной сети, поэтому прежде чем пустить пакет, мы его натим:
$IPTABLES -t nat -I POSTROUTING -o eth0 -d 192.168.1.0/24 -j SNAT --to-source 192.168.0.150
и, соответственно, когда пакет будет идти в интернет, его ещё раз надо отнатить:
$IPTABLES -t nat -I POSTROUTING -o eth1 -s 192.168.0.0/16 -j SNAT --to-source a.a.a.a
$IPTABLES -t nat -I POSTROUTING -o eth2 -s 192.168.0.0/16 -j SNAT --to-source b.b.b.b
А теперь, собственно, проблема...
когда клиенты стучаться на а.а.а.а:20240 - всё ок, так как на этом интерфейсе у меня дефолт гейтвей
а вот когда они стучаться на eth2 b.b.b.b:20240, ответ им уходит через a.a.a.a (eth1)
Замеченно, что такой полярный лисиц происходит именно тогда, когда используется 2-ой натинг. Если, скажем, сделать маппинг на другой адресб при этом внешний адрес не превращать в локальный, то всё ок.
Вот такие грабли. Это баг или фича? И как с ней бороться, кроме как отключить натинг внешних адресов в локальные?
-
- member
- Сообщения: 22
- Зарегистрирован: 08 дек 2006, 16:47
- Откуда: Астрахань
- Контактная информация:
Похоже, что таким извратом никто не страдал?
Частично эту проблему решил скриптом, который при падении основного канала меняет дефолт гейтвей на резервный канал. Но, как понимаете, решение проблемы через одно место. Так как когда основной канал поднимается и шлюз снова меняется на основной, то по резервному уже не достучаться.
Частично эту проблему решил скриптом, который при падении основного канала меняет дефолт гейтвей на резервный канал. Но, как понимаете, решение проблемы через одно место. Так как когда основной канал поднимается и шлюз снова меняется на основной, то по резервному уже не достучаться.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Когда рекомендуют Зебру для резервирования каналов, я всегда тихо улыбаюсь.
Поясняю почему. Зебра - это демон для протоколов динамической маррутизации. RIP, OSPF, BGP.
RIP, OSPF, BGP сами по себе (при наличии одного роутера) ничего резервировать не могут по определению. Нужен роутер на стороне провайдера, а вот это в большинстве случаев проблема. Не пущают провайдеры клиентов к своим роутерам, за исключанием если вы имеете свою автономную систему, зарегистрированную в RIPE.
Единственный способ резервирования для большинства случаев- старый добрый пинг.
По сути вопроса. Вот пища для размышления: http://lists.altlinux.org/pipermail/sys ... 02924.html
Т.е. нужно заставить систему запомнить откуда пришел пакет, а именно через какую сетевуху и туда же ответ послать. Тогда будет счастье.
Я в тонкости связи iproute2 и iptables далеко не лазил, но идея по моему понятная. Выполняется маркировка входящих пакетов, включается режим автозаполнения таблицы маршрутизации.
Судя по всему через некоторое время происходит зачистка кэша маршрутов и таким образом маркированные маршруты убиваются если на них нет трафика. Всегда работает только шлюз по умолчанию.
А вот теперь, чтобы сделать счастье людям, сидящим в офисе и желающим по-елозить по Инету, надо определять какой же канал к провайдеру живой-то. Тут только пинг, т.к. с вероятностью в 99.999% у вас нет автономной системы и BGP поднимать смысла нет никакого.
Пингуем оба канала и переопределяем шлюз по умолчанию на нашем чудо-компе.
По моему все очень даже красиво может получится.
Дока рулит. :D
http://gazette.linux.ru.net/rus/article ... index.html
Поясняю почему. Зебра - это демон для протоколов динамической маррутизации. RIP, OSPF, BGP.
RIP, OSPF, BGP сами по себе (при наличии одного роутера) ничего резервировать не могут по определению. Нужен роутер на стороне провайдера, а вот это в большинстве случаев проблема. Не пущают провайдеры клиентов к своим роутерам, за исключанием если вы имеете свою автономную систему, зарегистрированную в RIPE.
Единственный способ резервирования для большинства случаев- старый добрый пинг.
По сути вопроса. Вот пища для размышления: http://lists.altlinux.org/pipermail/sys ... 02924.html
Т.е. нужно заставить систему запомнить откуда пришел пакет, а именно через какую сетевуху и туда же ответ послать. Тогда будет счастье.
Я в тонкости связи iproute2 и iptables далеко не лазил, но идея по моему понятная. Выполняется маркировка входящих пакетов, включается режим автозаполнения таблицы маршрутизации.
Судя по всему через некоторое время происходит зачистка кэша маршрутов и таким образом маркированные маршруты убиваются если на них нет трафика. Всегда работает только шлюз по умолчанию.
А вот теперь, чтобы сделать счастье людям, сидящим в офисе и желающим по-елозить по Инету, надо определять какой же канал к провайдеру живой-то. Тут только пинг, т.к. с вероятностью в 99.999% у вас нет автономной системы и BGP поднимать смысла нет никакого.
Пингуем оба канала и переопределяем шлюз по умолчанию на нашем чудо-компе.
По моему все очень даже красиво может получится.
Дока рулит. :D
http://gazette.linux.ru.net/rus/article ... index.html
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Собственно можно улыбать, а можно и отправить человека почитать документацию. На опеннете есть несколько статей на похожие темы.and3008 писал(а):Когда рекомендуют Зебру для резервирования каналов, я всегда тихо улыбаюсь.
Поясняю почему. Зебра - это демон для протоколов динамической маррутизации. RIP, OSPF, BGP.
А я что-то сделал не так?
Вот конкретный кусок из моей доки:
http://gazette.linux.ru.net/rus/article ... /x348.html
Там же написано как работает маршрутизация от источника. Только она поможет автору вопроса решить его проблему.
Зебра не поможет ни разу, т.к. ей нужно с провайдерами общаться по какому-либо протоколу динамической марщрутизации, что в абсолютном большинстве случаев невозможно.
Зебра может помочь внутри сети организовать подключение по резервным каналам связи. Естественно это проистекает из необходимости развертывания какого-либо протокола динамической маршрутизации. Но в случае с Интернетом все не так просто...
Вот конкретный кусок из моей доки:
http://gazette.linux.ru.net/rus/article ... /x348.html
Там же написано как работает маршрутизация от источника. Только она поможет автору вопроса решить его проблему.
Зебра не поможет ни разу, т.к. ей нужно с провайдерами общаться по какому-либо протоколу динамической марщрутизации, что в абсолютном большинстве случаев невозможно.
Зебра может помочь внутри сети организовать подключение по резервным каналам связи. Естественно это проистекает из необходимости развертывания какого-либо протокола динамической маршрутизации. Но в случае с Интернетом все не так просто...
-
- member
- Сообщения: 22
- Зарегистрирован: 08 дек 2006, 16:47
- Откуда: Астрахань
- Контактная информация:
Мда, действительно, зебра в моём случае не помогает ни разу...
К этой доке я обращался настраивая два канала. Всё работает ок, пока не начинаешь использовать двойной натинг При нате, насколько я понял, из пакета начисто вытерается инфа о том, откуда он пришёл, поэтому потом все ответы шуруются в дефолтовый гейт. По сцылке выше есть интересные размышления на предмет того, что маркировать пакеты с помощью iptables. Ещё не пробовал, но как вариант - имеет право на жизнь.and3008 писал(а):А я что-то сделал не так?
Вот конкретный кусок из моей доки:
http://gazette.linux.ru.net/rus/article ... /x348.html
Там же написано как работает маршрутизация от источника. Только она поможет автору вопроса решить его проблему.
А каком двойном нате вы говорите? Двойной нат возможен в случае когда известен получатель, а у Вас общий случай. Т.ч. нат можно использовать либо в один интерфейс, либо в другой . Как вариант можно менять default gateway на шлюзе , а трафик пускать через squid например.
Извиняюсь не сразу понял суть. Х.м. нарисовал на листочке. Можно у внутреннего сервера 2 интерфейса поднять и SNAT делать на разные ip ? а обратно делать DNAT по источнику например.
Извиняюсь не сразу понял суть. Х.м. нарисовал на листочке. Можно у внутреннего сервера 2 интерфейса поднять и SNAT делать на разные ip ? а обратно делать DNAT по источнику например.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 20 гостей