Все DNS-запросы к серверу Bind9 показывают шлюз IP вместо фактического клиента после перехода на Linksys AC5400

В CentOS 7 вместо фактического IP-адреса клиента IP-адрес шлюза теперь отображается в журналах сервера Bind9.

Первичный DNS-сервер - 192.168.10.1, а вторичный. это 192.168.10.2. Шлюз - 192.168.1.1.

Даже запросы от вторичного DNS, который находится в той же подсети, отображаются как от маршрутизатора / шлюза. Запросы на передачу зоны были отправлены с адреса 192.168.10.2, но вместо этого в журнале отображается 192.168.1.1.

IPv6 был отключен на DNS-серверах, но нет возможности отключить его на маршрутизаторе.

31-Mar-2017 02:55:19.482 client 192.168.1.17#4394 (w.sharethis.com): view internal: query: w.sharethis.com IN A + (192.168.10.1)
31-Mar-2017 02:55:19.483 client 192.168.1.17#6929 (w.sharethis.com): view internal: query: w.sharethis.com IN AAAA + (192.168.10.1)
31-Mar-2017 02:55:19.670 client 192.168.1.17#28991 (www.sharethis.com): view internal: query: www.sharethis.com IN A + (192.168.10.1)
31-Mar-2017 02:55:19.671 client 192.168.1.17#23843 (www.sharethis.com): view internal: query: www.sharethis.com IN AAAA + (192.168.10.1)
31-Mar-2017 02:55:29.430 client 66.249.66.237#59407 (www.firmr.esources.com): view external: query: www.firmr.example.com IN A - (192.168.10.1)
31-Mar-2017 02:55:34.596 client 192.168.1.1#63655 (clients4.google.com): view internal: query: clients4.google.com IN A + (192.168.10.1)

Также для передачи зоны. :

31-Mar-2017 02:11:49.215 client 192.168.1.1#44467 (example1.com): view internal: transfer of 'example1.com/IN': AXFR started
31-Mar-2017 02:11:49.215 client 192.168.1.1#44467 (example1.com): view internal: transfer of 'example1.com/IN': AXFR ended
31-Mar-2017 02:12:21.626 client 192.168.1.1#36090 (example1.com): view internal: transfer of 'example1.com/IN': AXFR started
31-Mar-2017 02:12:21.626 client 192.168.1.1#36090 (example1.com): view internal: transfer of 'example1.com/IN': AXFR ended
31-Mar-2017 02:13:03.715 client 192.168.1.1#49586 (example1.com): view internal: transfer of 'example1.com/IN': AXFR started
31-Mar-2017 02:13:03.715 client 192.168.1.1#49586 (example1.com): view internal: transfer of 'example1.com/IN': AXFR ended
31-Mar-2017 02:41:27.469 client 192.168.1.1#50906 (example1.com): view internal: transfer of 'example1.com/IN': AXFR started
31-Mar-2017 02:41:27.470 client 192.168.1.1#50906 (example1.com): view internal: transfer of 'example1.com/IN': AXFR ended
31-Mar-2017 02:41:37.311 client 192.168.1.1#56073 (example2.com): view internal: transfer of 'example2.com/IN': AXFR started
31-Mar-2017 02:41:37.311 client 192.168.1.1#56073 (example2.com): view internal: transfer of 'example2.com/IN': AXFR ended

Traceroute:

traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  0.393 ms  0.395 ms  0.297 ms
 2  ns1.example.com (192.168.10.1)  0.872 ms !X  0.844 ms !X  0.795 ms !X
0
задан 1 April 2017 в 00:18
1 ответ

Самая очевидная проблема у traceroute:

traceroute to 192.168.10.1 (192.168.10.1), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  0.393 ms  0.395 ms  0.297 ms
 2  ns1.example.com (192.168.10.1)  0.872 ms !X  0.844 ms !X  0.795 ms !X

Это просто неправильно. Вы не должны проходить через устройство уровня 3 (маршрутизатор), чтобы достичь другого элемента в той же IP-подсети. Возможно, уровень 2 (переключатель), но он не будет отображаться в трассировке маршрута. Дважды проверьте маску подсети на 192.168.10.2 , чтобы убедиться, что она соответствует требованиям. Может быть, посмотрите 192.168.1.17 (из журналов запросов) в качестве примера - он работает правильно.

В противном случае опубликуйте вывод netstat -rn (или ip route ) из 192.168.10.2 . Также может быть полезно узнать, как настроен ваш vSwitch (VLAN)

0
ответ дан 5 December 2019 в 08:22

Теги

Похожие вопросы