04.02.08, Anton Kvashin <[EMAIL PROTECTED]> написал(а): > > Денис Черносов пишет: > > В некоторых ситуациях fqdn (а еще лучше маска!!!) просто необходимо. > > Потому что одно имя может иметь несколько ip или просто меняться гораздо > > реже, чем ip. > > Внести блок адресов организации/конторы/провайдера. Сделать выборку > интересующих вас, правда покрытие может быть шире.
У нас есть головная компания. А у неё есть сервера, к которым мы должны без проблем подключаться. Они нам дают настройки в виде fqdn:port Но сами сервера сначала были в России у одного хостера, потом у другого, сейчас находятся в Америке (причем несколько штук и в разных штатах). И всё это может относительно динамично меняться и, разумеется, безо всякого предупреждения. При статичности fqdn. Если директор не может посмотреть финансовую отчетность, потому что изменились настройки firewall, нервничать буду я и вполне по поводу. Пока выход только в открытии порта из всей локальной сети. Трафик - не http|ftp или какой-то другой из общеизвестных. Точно шифрованный, но подробности мне тоже недоступны. Как он будет переживать прозрачное проксирование - затрудняюсь сказать. Настраивать прокси руками тоже не везде получится - есть несколько самописных примитивных программулин, в которых этих настроек точно нет. Если я на работающей сетке, поднятых интерфейсах и bind добавляю правило, например на win.mail.ru:110, то оно отрабатывается нормально и особых тормозов я не замечал (сетка маленькая и это вообще не сильно критично а для оптимизации запросы на конкретный нужный порт можно вынести в отдельную цепочку, где и проводить проверки). Проблемы (вполне объяснимые) создают попытки использовать правила такого вида в iptables-save. С той же самой почтой, например, можно разрешить пользователям пользоваться, только почтой с яндекса, mail.ru и google (исходящие на порты smtp, pop3, imap), а остальное закрыть в целях борьбы с вирусами-спамерами. Но на один mail.yandex.ru может приходиться несколько ip, которые могут измениться в любой момент. После какого-то критического порога подобных правил, следить за актуальностью ip руками будет слишком обременительно. И, как ни следи, а смену адреса всё равно прозеваешь и получишь простой. > Суть проблемы в том, что iptables стартует ДО поднятия интерфейсов и ДО > > старта bind. > > Сначала инициализируется сетевая подсистема (подъем интерфейсов), потом > сетевые сервисы. У вас не так? А если возникнет проблема с DNS? У нас всё так же. :) Если возникнет проблема с DNS, то интернета, считай, что нет вообще. > Т.е. разрешение имен в этот момент не работает. Если такое > > правило стоит в /etc/sysconfig/iptables, то iptables при перезагрузке > > просто отваливается. Можно добавить часть правил iptables в скрипт, > > который стартует ПОСЛЕ bind, но..: > > 1) Как сделать так, чтобы корректно отрабатывалось поднятие/опускание > > интерфейсов? > > Падение линка? Если нет сети, что вы хотите от фильтра? Если есть другие > линки, то они должны быть в правилах. Не падение линка, а ifdown, ifup (у меня сейчас на сервере периодически повисает внешний интерфейс. Проблема скорее всего в мат. плате, уже готовится другой сервер ему на замену, но пока суть да дело... Не перезагружать же из-за этого весь сервер.). Если часть правил добавляется ПОСЛЕ поднятия интерфейса и ПОСЛЕ запуска bind, то нужно распознать ситуацию, когда bind уже работает и сразу же после поднятия интерфейса добавлять именные правила. Но при этом проследить, чтобы они не добавлялись дважды. Правда, проблема снимается, если нужные адреса находятся в /etc/hosts (тогда можно и в /etc/sysconfig/iptables или в /etc/net/). Кстати, а как добавлять несколько ip для одного имени в /etc/hosts? Просто тупо повторять строчки, меняя только ip? А от этого точно проблем не будет? > 2) Как сделать так, чтобы корректно отрабатывалось > > поднятие/опускание/падение bind? > > Заполнить руками/скриптом /etc/hosts. Избавится от имен в цепочках. Сейчас в цепочках имен нет. И руками можно добавить куда угодно, только смысла в этом немного. Скрипт - дело хорошее. Его наверное нужно будет запускать по расписанию, но я пока даже не знаю, какими утилитами дергать эту инфу и какие проверки нужно в него добавлять (как-то не рассматривал такой подход). Так что буду рад любым наброскам... > Нигде не наталкивался на предложения по этому поводу. Неужели правильнее > > будет это всё повесить на Squid? Или есть третий вариант? > > А что вы хотите, опишите задачу. см. выше -- > Anton Kvashin > _______________________________________________ > Sysadmins mailing list > [email protected] > https://lists.altlinux.org/mailman/listinfo/sysadmins >
_______________________________________________ Sysadmins mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/sysadmins
