Временный сбой в разрешении имен при попытке пропинговать или телнет

Прежде всего, я должен дать некоторые предпосылки для вопроса. Я модифицирую некоторый API для моей магистерской работы, и чтобы проверить, работает ли мой код, в университете я установил три виртуальные машины, на которых запущен Debian на наших серверах. Одна виртуальная машина выступает в качестве клиента, у каждого есть веб-сервер Apache с созданным мной тестовым веб-сайтом и DNS-сервер Bind9. Дорожный трафик сидит посередине. У клиента и сервера есть 3 интерфейса, каждый из которых находится в отдельной подсети со своей собственной таблицей маршрутизации (которая в основном говорит, что маршрут по умолчанию для всего, что выходит из этого интерфейса, является следующим переходом в сети, который является интерфейсом в формирователе). Формирователь имеет возможность IP-пересылки, так что это, по сути, «тупой маршрутизатор», и я могу без проблем пропинговать каждый интерфейс на клиенте и каждый интерфейс на сервере, и я сделал несколько tcpdumps, чтобы проверить, действительно ли пакеты следуют пути, который я выбрал в начале. Все работало нормально, пока в университете не возникла проблема на их сервере, и им не пришлось перезагружать все мои виртуальные машины (которые, согласно ИТ-отделу универа, работают на одном сервере поверх гипервизора, к которому подключены все виртуальные интерфейсы). ). Теперь мой API больше не может разрешить имя моего тестового веб-сайта, и я знаю, что код работает, потому что, если я пытаюсь запустить его на своем ноутбуке, он может разрешить, скажем, google.com и подключиться к нему. Поэтому я попытался сделать несколько других тестов, и это то, что я обнаружил. все на одном сервере поверх гипервизора, к которому подключены все виртуальные интерфейсы). Теперь мой API больше не может разрешить имя моего тестового веб-сайта, и я знаю, что код работает, потому что, если я пытаюсь запустить его на своем ноутбуке, он может разрешить, скажем, google.com и подключиться к нему. Поэтому я попытался сделать несколько других тестов, и это то, что я обнаружил. все на одном сервере поверх гипервизора, к которому подключены все виртуальные интерфейсы). Теперь мой API больше не может разрешить имя моего тестового веб-сайта, и я знаю, что код работает, потому что, если я пытаюсь запустить его на своем ноутбуке, он может разрешить, скажем, google.com и подключиться к нему. Поэтому я попытался сделать несколько других тестов, и это то, что я обнаружил.

resolv.conf на клиенте выглядит так

domain inet.tu-berlin.de. search inet.tu-berlin.de. net.t-labs.tu-berlin.de. #nameserver 1.1.1.1 nameserver 10.2.1.2  options timeout:2 

Что верно, так как мой DNS-сервер находится на 10.2.1.2 (как мой веб-сервер)

Если я попытаюсь пропинговать DNS от клиента, указав один из интерфейсов, подключенных к гипервизору виртуальных машин (которые следуют схеме именования 10.1.x.1), это сработает.

:# ping 10.2.1.2 -I 10.1.1.1 PING 10.2.1.2 (10.2.1.2) from 10.1.1.1 : 56(84) bytes of data. 64 bytes from 10.2.1.2: icmp_seq=1 ttl=63 time=1.98 ms 64 bytes from 10.2.1.2: icmp_seq=2 ttl=63 time=1.42 ms  --- 10.2.1.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.422/1.704/1.986/0.282 ms 

То же самое с dig, я могу разрешить имя хоста моего веб-сайта (называемого happytester.com), все еще указав один из интерфейсов на клиенте, который подключен к гипервизору.

:# dig happytester.com -b 10.1.1.1  ; <<>> DiG 9.10.3-P4-Debian <<>> happytester.com -b 10.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46158 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1  ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;happytester.com. IN A  ;; ANSWER SECTION: happytester.com. 604800 IN A 10.2.2.2 happytester.com. 604800 IN A 10.2.1.2 happytester.com. 604800 IN A 10.2.3.2  ;; AUTHORITY SECTION: happytester.com. 604800 IN NS mmaffei-server.inet.tu-berlin.de.  ;; Query time: 2 msec ;; SERVER: 10.2.1.2#53(10.2.1.2) ;; WHEN: Sat Nov 03 19:18:58 CET 2018 ;; MSG SIZE rcvd: 138 

Если я tcpdump интерфейс, который соответствует 10.1.1.1 на клиенте, я вижу, что DNS-запрос и ответ проходят.

:# tcpdump -i eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:21:23.269486 IP 10.1.1.1.46824 > 10.2.1.2.domain: 56695+ [1au] A? happytester.com. (44) 19:21:23.271841 IP 10.2.1.2.domain > 10.1.1.1.46824: 56695* 3/1/1 A 10.2.2.2, A 10.2.3.2, A 10.2.1.2 (138) 

Теперь о самом вопросе: почему на Земле, если все работает, как я объяснял ранее, это не работает?

:# ping happytester.com -I 10.1.1.1 ping: happytester.com: Temporary failure in name resolution 

А tcpdump просто хранит молчание, поэтому запросы DNS даже не отправляются. Это касается практически всего, что не копается, включая telnet и, что самое важное, мой API.

РЕДАКТИРОВАТЬ:

Вот как моя таблица маршрутизации и интерфейс выглядят на клиенте

:# ip route show default via 130.149.221.222 dev eth0 onlink 10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.1 10.1.2.0/24 dev eth2 proto kernel scope link src 10.1.2.1 10.1.3.0/24 dev eth3 proto kernel scope link src 10.1.3.1 130.149.221.192/27 dev eth0 proto kernel scope link src 130.149.221.215  :# ip route show table client1 default via 10.1.1.2 dev eth1  :# ip route show table client2 default via 10.1.2.2 dev eth2  :# ip route show table client3 default via 10.1.3.2 dev eth3 

А вот и интерфейсы:

# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).  source /etc/network/interfaces.d/*  # The loopback network interface auto lo iface lo inet loopback  auto eth0 iface eth0 inet static address 130.149.221.215/27 gateway 130.149.221.222  iface eth0 inet6 static address 2001:638:809:ff13:130:149:221:215/64 gateway fe80::1  auto eth1 iface eth1 inet static address 10.1.1.1 netmask 255.255.255.0 dns-nameservers 10.2.1.2 post-up ip rule add from 10.1.1.1 lookup client1 post-up ip route add default via 10.1.1.2 dev eth1 table client1  auto eth2 iface eth2 inet static address 10.1.2.1 netmask 255.255.255.0 dns-nameservers 10.2.1.2 post-up ip rule add from 10.1.2.1 lookup client2 post-up ip route add default via 10.1.2.2 dev eth2 table client2  auto eth3 iface eth3 inet static address 10.1.3.1 netmask 255.255.255.0 dns-nameserver 10.2.1.2 post-up ip rule add from 10.1.3.1 lookup client3 post-up ip route add default via 10.1.3.2 dev eth3 table client3 

EDIT2

Вот вывод dig без указанного интерфейса и tcpdump на всех интерфейсах.

:# dig happytester.com  ; <<>> DiG 9.10.3-P4-Debian <<>> happytester.com ;; global options: +cmd ;; connection timed out; no servers could be reached  :# tcpdump -i eth0 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 19:56:02.193104 IP mmaffei-client.inet.tu-berlin.de.41160 > 10.2.1.2.domain: 22115+ [1au] A? happytester.com. (44) 19:56:07.193073 IP mmaffei-client.inet.tu-berlin.de.41160 > 10.2.1.2.domain: 22115+ [1au] A? happytester.com. (44) 19:56:12.193315 IP mmaffei-client.inet.tu-berlin.de.41160 > 10.2.1.2.domain: 22115+ [1au] A? happytester.com. (44) ^C  :# tcpdump -i eth1 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel  :# tcpdump -i eth2 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel  :# tcpdump -i eth3 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes ^C 0 packets captured 0 packets received by filter 0 packets dropped by kernel 

Я надеюсь, что кто-то может помочь.