Одна из двух систем шлюза («брандмауэра») вышла из строя, поэтому я создал «идентичную» систему на заменяющем оборудовании и обнаружил, что когда я переключал одну из внутренних машин на новый шлюз, эхо-запрос не удался. Переключил обратно, работает. Итак, я попробовал выполнить пинг с IP, избегая DNS, и это сработало. Во время устранения неполадок я обнаружил, что если я пройду через старый шлюз, я могу нормально запустить 'dig', но через новый он не работает:
[root@MyHost sysconfig]# dig @67.100.88.26 google.com mx
; <<>> DiG 8.2 <<>> @67.100.88.26 google.com mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend to server 67.100.88.26: Connection refused
[root@MyHost sysconfig]#
Если я переключу его обратно на другой шлюз, все будет работать отлично. Это говорит о том, что с клиентским ящиком все в порядке, но на самом деле брандмауэр не идентичен, хотя кажется, что это так.
Я добавил логирование отброшенных пакетов, но от внутренней системы вообще ничего нет!
Обратите внимание, что это неявно проблема взаимодействия DNS / iptables. Наблюдение за «исправьте DNS, и вы решите свою проблему» - это лишь переформулирование проблемы с другой точки зрения.
Возникает вопрос: что конкретно в этой конфигурации брандмауэра блокирует правильное функционирование, когда идентичный компьютер, та же ОС и т. Д. Отлично работает с той же конфигурацией iptables и с той же самой тестовой системой (и все, что может быть правильным / неправильным с его resolve.conf).
(Также обратите внимание: я считаю довольно трусливым отклонять этот вопрос без объяснения причин.)
[root@MyHost sysconfig]# ping google.com
ping: unknown host google.com
[root@MyHost sysconfig]# ping 74.125.224.82
PING 74.125.224.82 (74.125.224.82) from 192.168.127.16 : 56(84) bytes of data.
64 bytes from 74.125.224.82: icmp_seq=0 ttl=53 time=46.425 msec
64 bytes from 74.125.224.82: icmp_seq=1 ttl=53 time=45.486 msec
--- 74.125.224.82 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/mdev = 45.486/45.955/46.425/0.516 ms
[root@MyHost sysconfig]#
Новый брандмауэр, старое оборудование на новой установке Fedora Core 14 - две системы шлюза настолько близки к идентичности, насколько я могу их сделать.
NetworkManager (соответственно) выключен.
Конфигурация DNS кажется прекрасной как для брандмауэра, так и для внутренних узлов - здесь НЕ используются службы DNS (BIND и т. Д.), Только общедоступные DNS-серверы. Доступ к службам DNS с обоих шлюзов в порядке.
Директива iptables «-A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT» должна позволить DNS-сообщениям проходить без проблем, как в примере с ping, но с dig, я просто не знаю.
Я добавил "-A INPUT -m limit --limit 3 / min -j LOG --log-prefix" FW-IN-DROP-DEFAULT "--log-tcp-options --log-ip-options", как предложено в попытка ответа, при этом НЕ выполняется регистрация в журнале в результате неудачных вызовов DNS, связанных с эхо-запросом, указанным в примере.
Интересно, стоит ли мне использовать настоящий MASQUERADING вместо SNAT / DNAT.
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.127.0/24 -o eth0 -j SNAT --to-source 76.110.113.22
-A PREROUTING -i eth0 -p tcp --dport 25 -j DNAT --to-destination 192.168.127.50
-A PREROUTING -i eth0 -p tcp --dport 1234 -j DNAT --to-destination 192.168.127.61:99
-A PREROUTING -i eth0 -p tcp --dport 993 -j DNAT --to-destination 192.168.127.50
-A PREROUTING -i eth0 -p tcp --dport 995 -j DNAT --to-destination 192.168.127.50
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 993 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 1194 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 995 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth2 -j ACCEPT
-A FORWARD -o eth2 -j ACCEPT
-A FORWARD -i eth0 -m state --state NEW -m tcp -p tcp -d 192.168.127.50 --dport 25 -j ACCEPT
-A FORWARD -i eth0 -m state --state NEW -m tcp -p tcp -d 192.168.127.61 --dport 99 -j ACCEPT
-A FORWARD -i eth0 -m state --state NEW -m tcp -p tcp -d 192.168.127.50 --dport 993 -j ACCEPT
-A FORWARD -i eth0 -m state --state NEW -m tcp -p tcp -d 192.168.127.50 --dport 995 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
Ваша проблема в том, что DNS не работает.
С точки зрения брандмауэра он не может определить, набрали ли вы:
$ ping google.com
или:
$ ping 2001:4860:800f::63
Исправьте DNS, и вы решите свою проблему.
Чтобы помочь в диагностике, попробуйте добавить несколько правил, например:
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "FW-IN-DROP-DEFAULT " --log-tcp-options --log-ip-options
перед вашими правилами REJECT. Тогда вы узнаете, что его уронили.