Tips & tricks — Динамический IP (DHCP) и IPtables [РЕШЕНО]
Некоторое время назад я, в своем личном блоге, задавался вопросом о том, как "налету" внести изменение в правила IPtables в случае смены IP адреса провайдером. Благодаря совету юзера albibek вопрос незамедлительно был решен. Желающих узнать подробности прошу под cut.
Суть проблемы я описал в своем посте, доступном по приведенной выше ссылке, но, дабы не прерывать свое повествование приведу выдержку из него:
Сетевая карта, которая "смотрит" в интернет конфигурируется с помощью DHCP и время от времени меняет свой IP адрес и "никому не говорит" и правила IPtables не подправляет...
Внимание вопрос: а происходит ли какое либо событие при смене IP у сетевого интерфейса? Если да, то как на это событие отреагировать и запустить скрипт, который поправит правила IPtables. Заранее спасибо.
Казалось бы, в чем проблема? Используй действие MASQUERADE, Luke, скажут многие, ведь именно для этого оно и редназнчено. Но, цитирую:
Маскировка (MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия - производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.
Конец цитаты.
А систему почем зря нагружать не хочется... Да и опыт решения подобных проблем есть желание получить.
И тут в голову приходит еще одно решение: спустись пониже, используй не IP, а имя сетевого интерфейса для построения правил. И опять появляется но... Цитирую:
...пусть на брандмауэре запущен HTTP сервер. Если мы приходим на главную страничку, содержащую статическую ссылку обратно на этот же сервер, который работает под динамическим адресом, то мы можем "огрести" немало проблем. Хост, который проходит через NAT, запросит через DNS IP адрес HTTP сервера, после чего попробует получить доступ к этому IP. Если брандмауэр производит фильтрацию по интерфейсу и IP адресу, то хост не сможет получить ответ, поскольку цепочка INPUT отфильтрует такой запрос. Это так же справедливо и для некоторых случаев когда мы имеем статический IP адрес, но тогда это можно обойти, используя правила, которые проверяют пакеты, приходящие с LAN интерфейса на наш INET_IP и выполнять ACCEPT для них.
После всего вышесказанного, не такой уж плохой может показаться мысль о создании сценария, который бы обрабатывал динамический IP.
Конец цитаты.
Как же быть? Нужно, как-то, при инициализации сетевого интерфейса, "вычислять" IP который выдал провайдер и использовать его для построения правил, тем самым создать иллюзию статичности IP. Выглядеть сценарий, выполняющий приведенные выше действия, должен примерно так:
Все будет работать пока не закончится аренда IP. Как только это произойдет локальная сеть лишится выхода в интернет...
И вот тут-то нам и поможет совет albibek-а. Он нам намекнул, что некоторые DHCP клиенты умеют выполнять скрипты после того, как получат настройки от провайдера. Например DHCP3-client имеет два набора скриптов-хуков - dhclient-enter-hooks.d и dhclient-exit-hooks.d. Первый выполняется когда уже получен ответ от сервера провайдера, но еще не сконфигурирован интерфейс, а второй - после конфигурирования интерфейса. Естественно, запускать скрипт, который внесет изменения в правила IPtables нужно из dhclient-exit-hooks.d и выглядеть это будет примерно так:
Вот теперь сеть будет работать без накладок и сбоев, а мы будем довольны полученным опытом.
PS
Подробнее о возможности выполнения скриптов DHCP-клиентом можно почитать в man dhclient-script. Это даст много пищи для размышлений, например о "синхронизация времени" после подключения к сети, как например это сделал автор данной заметки.
PPS
И еще, перед тем, как выполнить скрипт из, например, /etc/dhcp3/dhclient-exit-hooks.d/, dhclient-script создает ряд переменных окружения, в которых будет содержаться информация полученная от провайдера. Они могут прийтись очень кстати.
Суть проблемы я описал в своем посте, доступном по приведенной выше ссылке, но, дабы не прерывать свое повествование приведу выдержку из него:
Сетевая карта, которая "смотрит" в интернет конфигурируется с помощью DHCP и время от времени меняет свой IP адрес и "никому не говорит" и правила IPtables не подправляет...
Внимание вопрос: а происходит ли какое либо событие при смене IP у сетевого интерфейса? Если да, то как на это событие отреагировать и запустить скрипт, который поправит правила IPtables. Заранее спасибо.
Казалось бы, в чем проблема? Используй действие MASQUERADE, Luke, скажут многие, ведь именно для этого оно и редназнчено. Но, цитирую:
Маскировка (MASQUERADE) применяется в тех же целях, что и SNAT, но в отличие от последней, MASQUERADE дает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия - производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для SNAT IP адрес указывается непосредственно. Однако, благодаря такому отличию, MASQUERADE может работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через PPP, SLIP или DHCP.
А систему почем зря нагружать не хочется... Да и опыт решения подобных проблем есть желание получить.
И тут в голову приходит еще одно решение: спустись пониже, используй не IP, а имя сетевого интерфейса для построения правил. И опять появляется но... Цитирую:
...пусть на брандмауэре запущен HTTP сервер. Если мы приходим на главную страничку, содержащую статическую ссылку обратно на этот же сервер, который работает под динамическим адресом, то мы можем "огрести" немало проблем. Хост, который проходит через NAT, запросит через DNS IP адрес HTTP сервера, после чего попробует получить доступ к этому IP. Если брандмауэр производит фильтрацию по интерфейсу и IP адресу, то хост не сможет получить ответ, поскольку цепочка INPUT отфильтрует такой запрос. Это так же справедливо и для некоторых случаев когда мы имеем статический IP адрес, но тогда это можно обойти, используя правила, которые проверяют пакеты, приходящие с LAN интерфейса на наш INET_IP и выполнять ACCEPT для них.
После всего вышесказанного, не такой уж плохой может показаться мысль о создании сценария, который бы обрабатывал динамический IP.
Как же быть? Нужно, как-то, при инициализации сетевого интерфейса, "вычислять" IP который выдал провайдер и использовать его для построения правил, тем самым создать иллюзию статичности IP. Выглядеть сценарий, выполняющий приведенные выше действия, должен примерно так:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
Все будет работать пока не закончится аренда IP. Как только это произойдет локальная сеть лишится выхода в интернет...
И вот тут-то нам и поможет совет albibek-а. Он нам намекнул, что некоторые DHCP клиенты умеют выполнять скрипты после того, как получат настройки от провайдера. Например DHCP3-client имеет два набора скриптов-хуков - dhclient-enter-hooks.d и dhclient-exit-hooks.d. Первый выполняется когда уже получен ответ от сервера провайдера, но еще не сконфигурирован интерфейс, а второй - после конфигурирования интерфейса. Естественно, запускать скрипт, который внесет изменения в правила IPtables нужно из dhclient-exit-hooks.d и выглядеть это будет примерно так:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Вот теперь сеть будет работать без накладок и сбоев, а мы будем довольны полученным опытом.
PS
Подробнее о возможности выполнения скриптов DHCP-клиентом можно почитать в man dhclient-script. Это даст много пищи для размышлений, например о "синхронизация времени" после подключения к сети, как например это сделал автор данной заметки.
PPS
И еще, перед тем, как выполнить скрипт из, например, /etc/dhcp3/dhclient-exit-hooks.d/, dhclient-script создает ряд переменных окружения, в которых будет содержаться информация полученная от провайдера. Они могут прийтись очень кстати.