Temporärer Fehler bei der Namensauflösung, wenn versucht wird, Ping oder Telnet auszuführen

Zuallererst sollte ich etwas Hintergrund für die Frage geben. Ich ändere eine API für meine Masterarbeit. Um zu überprüfen, ob mein Code funktioniert, habe ich die Universität drei VMs eingerichtet, auf denen Debian auf unseren Servern ausgeführt wird. Eine VM fungiert als Client, eine hat sowohl einen Apache-Webserver mit einer von mir erstellten Test-Website als auch einen Bind9-DNS-Server. In der Mitte sitzt ein Verkehrsformer. Der Client und der Server verfügen über 3 Schnittstellen, die sich jeweils in einem anderen Subnetz mit einer eigenen Routing-Tabelle befinden (was im Wesentlichen besagt, dass die Standardroute für alles, was von dieser Schnittstelle kommt, der nächste Hop im Netzwerk ist, der eine Schnittstelle auf dem Shaper ist). Der Shaper verfügt über eine IP-Weiterleitungsfunktion, dh es ist im Grunde ein "dummer Router", und ich kann ohne Probleme von jeder Schnittstelle des Clients an jede Schnittstelle des Servers pingen. und ich habe ein paar tcpdumps gemacht, um zu überprüfen, ob die Pakete tatsächlich dem Pfad folgen, den ich anfangs angenommen habe. Alles funktionierte gut, bis die Universität ein Problem auf ihrem Server hatte und sie alle VMs neu starten musste (die laut IT-Abteilung der Uni alle auf demselben Server laufen und sich auf einem Hypervisor befinden, an den alle virtuellen Schnittstellen angeschlossen sind ). Jetzt kann meine API den Namen meiner Test-Website nicht mehr auflösen, und ich weiß, dass der Code funktioniert, denn wenn ich versuche, ihn auf meinem Laptop auszuführen, kann dies eine Auflösung sein, sagen wir google.com und stellen eine Verbindung dazu her. Also habe ich versucht, ein paar andere Tests durchzuführen und das habe ich entdeckt. alle auf demselben Server auf einem Hypervisor, mit dem alle virtuellen Schnittstellen verbunden sind). Jetzt kann meine API den Namen meiner Test-Website nicht mehr auflösen, und ich weiß, dass der Code funktioniert, denn wenn ich versuche, ihn auf meinem Laptop auszuführen, kann dies eine Auflösung sein, sagen wir google.com und stellen eine Verbindung dazu her. Also habe ich versucht, ein paar andere Tests durchzuführen und das habe ich entdeckt. alle auf demselben Server auf einem Hypervisor, mit dem alle virtuellen Schnittstellen verbunden sind). Jetzt kann meine API den Namen meiner Test-Website nicht mehr auflösen, und ich weiß, dass der Code funktioniert, denn wenn ich versuche, ihn auf meinem Laptop auszuführen, kann dies eine Auflösung sein, sagen wir google.com und stellen eine Verbindung dazu her. Also habe ich versucht, ein paar andere Tests durchzuführen und das habe ich entdeckt.

resolv.conf auf dem Client liest sich so

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 

Welches ist richtig, da sich mein DNS-Server auf 10.2.1.2 befindet (als mein Webserver)

Wenn ich versuche, das DNS vom Client aus anzupingen, und eine der Schnittstellen angibt, die mit dem Hypervisor der VM verbunden sind (die einem Namensschema von 10.1.x.1 folgen), funktioniert es.

:# 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 

Dasselbe gilt für dig. Ich kann den Hostnamen meiner Website (mit dem Namen happytester.com) auflösen und dabei immer noch eine der Schnittstellen des Clients angeben, der mit dem Hypervisor verbunden ist.

:# 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 

Wenn ich die Schnittstelle, die 10.1.1.1 auf dem Client entspricht, tcpdumpe, kann ich die DNS-Abfrage und -antwort sehen, die durchläuft.

:# 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) 

Nun zur Frage selbst, warum um alles in der Welt, wenn alles funktioniert, wie ich es bereits erklärt habe, funktioniert das nicht?

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

Und tcpdump bleibt nur stumm, sodass die DNS-Abfragen nicht einmal gesendet werden. Dies betrifft fast alles, was nicht gesucht wird, einschließlich Telnet und vor allem meine API.

BEARBEITEN:

So sehen meine Routingtabelle und mein Interface auf dem Client aus

:# 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 

Und hier sind die Schnittstellen:

# 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

Hier ist die dig-Ausgabe ohne eine angegebene Schnittstelle und tcpdump für alle Schnittstellen.

:# 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 

Ich hoffe jemand kann helfen.