Как известно в iptables (у меня на данный момент 1.4.4) в критериях --source и --destination кроме ip-адресов можно использовать имена.
При выполнении правил iptables они разрешаются в ip-шники (что кстати, удобно если за одним дпс-именем стоят несколько ip-адресов)
Я использую в своих правилах несколько имен хостов из локальной сети и заметил, что при определенных условиях при выполнении скрипта iptables имена эти не разрешаются.
Причем если сразу попробовать их разрешить через dig или nslookup, то резольвинг проходить успешно.
Есть еще один нюанс... на данной машине установлен кеширующий bind9 и в его конфиге указано что зона для локальной сети находиться на другом сервере (win dc)
named.conf:
zone "firma.local" {
type forward;
forwarders { 192.168.1.1; 192.168.1.2; };
};
а в /etc/resolf.conf первой строчкой идет "nameserver 127.0.0.1"
то есть при вопросе iptables у 127.0.0.1: кто такой workstation.firma.local?
всегда должны возвращаться данные от 192.168.1.1; 192.168.1.2;, ну или из кеша самого 127.0.0.1
Почему при массовом выполнении правил iptables иногда этого не происходит и как это побороть
1) использовать имена в фаерволах - дурной тон и потенциальные грабли
2) при перестроении фаревола скорей всего закрывается доступ с днс на форвардеров
>1) использовать имена в фаерволах - дурной тон и потенциальные грабли
>2) при перестроении фаревола скорей всего закрывается доступ с днс на форвардеров
>непохоже... группа правил в которых фигурируют имена выполняется после правил INPUT/OUTPUT,
плюс к этому раз на раз не приходиться
если предварительно сделать для всех "неудачных" умен nslookup, то правила проходят нормально
>>1) использовать имена в фаерволах - дурной тон и потенциальные грабли
>>2) при перестроении фаревола скорей всего закрывается доступ с днс на форвардеров
>>
>
>непохоже... группа правил в которых фигурируют имена выполняется после правил INPUT/OUTPUT,
>плюс к этому раз на раз не приходиться
>если предварительно сделать для всех "неудачных" умен nslookup, то правила проходят нормально
>по всей видимости это вопрос скорее к bind-у
вот что показывает tcpdump
root@host:~# tcpdump -vv -nn -i any port 53
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
15:47:26.457997 IP (tos 0x0, ttl 64, id 50382, offset 0, flags [DF], proto UDP (17), length 65)
127.0.0.1.60821 > 127.0.0.1.53: [bad udp cksum 8a50!] 6189+ A? WRK.FIRMA.LOCAL (37)
15:47:26.459642 IP (tos 0x0, ttl 64, id 6871, offset 0, flags [none], proto UDP (17), length 65)
127.0.0.1.53 > 127.0.0.1.60821: [bad udp cksum 7d0!] 6189 ServFail q: A? WRK.FIRMA.LOCAL 0/0/0 (37)
15:47:26.459730 IP (tos 0x0, ttl 64, id 50382, offset 0, flags [DF], proto UDP (17), length 65)
127.0.0.1.47788 > 127.0.0.1.53: [bad udp cksum 7383!] 6189+ A? WRK.FIRMA.LOCAL (37)
15:47:26.461104 IP (tos 0x0, ttl 64, id 6872, offset 0, flags [none], proto UDP (17), length 65)
127.0.0.1.53 > 127.0.0.1.47788: [bad udp cksum f102!] 6189 ServFail q: A? WRK.FIRMA.LOCAL 0/0/0 (37)
15:47:26.462103 IP (tos 0x0, ttl 64, id 50382, offset 0, flags [DF], proto UDP (17), length 65)
127.0.0.1.47653 > 127.0.0.1.53: [bad udp cksum 51b!] 33058+ A? WRK.FIRMA.LOCAL (37)
15:47:26.463726 IP (tos 0x0, ttl 64, id 6873, offset 0, flags [none], proto UDP (17), length 65)
127.0.0.1.53 > 127.0.0.1.47653: [bad udp cksum 829a!] 33058 ServFail q: A? WRK.FIRMA.LOCAL 0/0/0 (37)
15:47:26.463792 IP (tos 0x0, ttl 64, id 50382, offset 0, flags [DF], proto UDP (17), length 65)
127.0.0.1.59710 > 127.0.0.1.53: [bad udp cksum ebeb!] 33058+ A? WRK.FIRMA.LOCAL (37)
15:47:26.465357 IP (tos 0x0, ttl 64, id 6874, offset 0, flags [none], proto UDP (17), length 65)
127.0.0.1.53 > 127.0.0.1.59710: [bad udp cksum 696b!] 33058 ServFail q: A? WRK.FIRMA.LOCAL 0/0/0 (37)
причем если у 127.0.0.1 спросить про другой хост из FIRMA.LAN
то ответ получаешь нормальноА вот выхлоп tcpdump-а после удачного nslookup wrk.firma.local
(tos 0x0, ttl 64, id 7043, offset 0, flags [none], proto UDP (17), length 65) 127.0.0.1.48660 > 127.0.0.1.53: [bad udp cksum 999c!] 64414+ A? WS-FRSD-170.frsd.ru. (37)
(tos 0x0, ttl 64, id 5377, offset 0, flags [none], proto UDP (17), length 76) 192.168.1.254.44230 > 192.168.1.1.53: [bad udp cksum 7e83!] 35691+ [1au] A? WRK.FIRMA.LOCAL. ar: . OPT UDPsize=4096 OK (48)
(tos 0x0, ttl 128, id 21141, offset 0, flags [none], proto UDP (17), length 92) 192.168.1.1.53 > 192.168.1.254.44230: 35691* q: A? WRK.FIRMA.LOCAL. 1/0/1 WRK.FIRMA.LOCAL.[|domain]
(tos 0x0, ttl 64, id 7044, offset 0, flags [none], proto UDP (17), length 81) 127.0.0.1.53 > 127.0.0.1.48660: 64414 q: A? WRK.FIRMA.LOCAL. 1/0/0 WRK.FIRMA.LOCAL. (53)похоже что если спрашивает iptables то bind не переспрашивает о wrk.firma.local у 192.168.1.1
а если спросить через nslookup, то спрашивает
Я бы даже не стал экспериментов проводить. Даже боюсь представить что будет под нагрузкой. Не делайте так.
Если уж очень хочется, создавайте под каждый сайт цепочки, в которых скрипт раз в час будет резолвить адреса этого домена и заполнять цепочку. Собственно у нас так и реализовано, закрытие сайтов террористической направленности.
>Я бы даже не стал экспериментов проводить. Даже боюсь представить что будет
>под нагрузкой. Не делайте так.
>Если уж очень хочется, создавайте под каждый сайт цепочки, в которых скрипт
>раз в час будет резолвить адреса этого домена и заполнять цепочку.
>Собственно у нас так и реализовано, закрытие сайтов террористической направленности.по причинам блуждающих пользователей я и так скрипт этот дергаю часто
если по какой-то причине имя не разрешилось правило просто не определяется
(синтаксическая ошибка)
сами по себе имена не проблема, при назначении правил они резольвятся, а далее все уже отрабатывает по адресам (сами действия над пакетами)как вариант можно сначало через dig резольвить в переменную, потом проверять не пустая ли она и только потом определять правило
но тогда появляется проблема с именами за которыми больше одного адресаплюс к этому хочеться разобраться почему это работает именно так
в тех же правилах с резольвингом внешних ресурсов проблем нет
а если зону сделать не forwarders, а slave?
и почему bad udp cksum
>а если зону сделать не forwarders, а slave?
>и почему bad udp cksumвот я сам не понимаю почему bad udp cksum
обратите внимание, что при удачном запросе тоже самоечто касается forwarders vs. slave
попробовать можно, но согласитесь в данных условиях forwarders более прозрачно
(источник и предполагаемый slave находятся в одной сети и т.д., плюс к этому если ляжет виндовый днс, то у меня будут заботы кроме пары станций внутри сети, которые не смогут обратиться к внешнему почтовому серверу, все самое важное все равно по ip)
>вот я сам не понимаю почему bad udp cksum
>обратите внимание, что при удачном запросе тоже самоеа вы уверену что через lo нужен checksum ?
>>вот я сам не понимаю почему bad udp cksum
>>обратите внимание, что при удачном запросе тоже самое
>
>а вы уверену что через lo нужен checksum ?без понятия...
>[оверквотинг удален]
>
>вот я сам не понимаю почему bad udp cksum
>обратите внимание, что при удачном запросе тоже самое
>
>что касается forwarders vs. slave
>попробовать можно, но согласитесь в данных условиях forwarders более прозрачно
>(источник и предполагаемый slave находятся в одной сети и т.д., плюс к
>этому если ляжет виндовый днс, то у меня будут заботы кроме
>пары станций внутри сети, которые не смогут обратиться к внешнему почтовому
>серверу, все самое важное все равно по ip)При форвардинге запроса тоже пауза возникает, из-за этого может таймаут отрабатывать...
Если у вас правила часто перегружаются, если правила с именами критичны, то ИМХО нужно делат slave.
>Я бы даже не стал экспериментов проводить. Даже боюсь представить что будет
>под нагрузкой. Не делайте так.
>Если уж очень хочется, создавайте под каждый сайт цепочки, в которых скрипт
>раз в час будет резолвить адреса этого домена и заполнять цепочку.
>Собственно у нас так и реализовано, закрытие сайтов террористической направленности.Непойму чего вы боитесь? - имя в адрес разрешается всего только раз - при загрузке.
Понятное дело что частые перезагрузы такие правила будут плохо переносить, но бывает возникает необходимость в таком, например дать доступ на хост который получает адрес по dhcp