Kontext
Es gibt 2 Server:
Server1 - eth0 10.129.76.16 eth0.2 192.168.0.103
Server2 - eth0 10.129.79.1 eth0.2 192.168.62.101
Die 192.xxx-Adressen sind mit demselben VLAN (VLAN2) verbunden und können sich gegenseitig sehen. Die 10.xxx-Adressen sind mit anderen VLANs verbunden, die sich gegenseitig nicht sehen können.
auf Anfrage von David Swartz: die Routing-Tabelle auf Server 1 lautet:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
die Routing-Tabelle auf Server 2 lautet:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
Problem:
Wenn ich von Server 1 zu Server 2 pinge, scheinen keine Pakete anzukommen und umgekehrt. Wenn ich die Routen überprüfe (Route -n), sehe ich, dass der Standard-GW auf beiden Servern eth0.2 verwendet. Aber wenn ich Arping verwende, erhalte ich eine Antwort in eine Richtung (von Server 2 zu Server 1), aber keine Antwort umgekehrt.
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
Wie Sie sehen, wird die Adresse 10.xxx anstelle von 192.xxx verwendet. Und wie ich bereits sagte, ist die Adresse 10.xxx vom anderen Server aus nicht erreichbar.
Wenn ich beim ARP die Verwendung von eth0.2 erzwinge, funktioniert es.
Ich habe keine Probleme damit, von einem dieser beiden Server aus andere Server anzupingen.
Ich habe dies in den ARP-Tabellen gesehen:
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
Und
~# arp -n | grep 192.168.62.101
Frage
ganz offensichtlich ... Wie kann ich dafür sorgen, dass diese Server sich wieder gegenseitig erkennen?
Dinge, die ich gebunden habe
lösche die entsprechenden Einträge in der Arptable und versuche, die (unvollständigen) loszuwerden. Aber ich denke, das größte Problem ist, dass eth0 anstelle von eth0.2 für die Pakete von Server 1 zu Server 2 verwendet wird
Aufgrund von David Swartz' Bemerkung zu den Routing-Tabellen habe ich dort eine Route hinzugefügt, die den Host definiert. Ich habe hinzugefügt
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
Und
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
an die entsprechenden Server, aber das hat das Problem nicht gelöst, daher gehe ich davon aus, dass das Problem nicht am Routing liegt.
Meine Vermutung
Ich vermute, das Problem liegt im Folgenden.
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
aber ich kann diesen Eintrag nicht entfernen. (arp -d 192.168.0.103 hat keine Wirkung)
Danke fürs Lesen und noch mehr Danke fürs Antworten!
Antwort1
Hier ist ein Ausschnitt:
ARPP beachtet die lokale Routing-Tabelle nicht:
== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess
Verwenden Sie ICMP zum Testen:
[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem
sind deine VLANs in Ordnung?
[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
Antwort2
Sie haben nicht erwähnt, welchen Kernel Sie verwenden oder welche Version von arping, und es besteht die Möglichkeit eines Fehlers in dem einen oder anderen. Die Tatsache, dass Sie erfolgreich können, arpingwenn Sie die Subschnittstelle angeben, zeigt an, dass Ihr gesamtes Layer-2-Netzwerk korrekt funktioniert.
Versuchen Sie, ip route get 192.168.62.101auf Server1 zu verwenden, um den Kernel direkt zu fragen, wie er Ihren Datenverkehr senden würde. Basierend auf den Routing-Tabellen, die Sie gepostet haben, ist das Senden über eth0.2 eindeutig das richtige Verhalten, und wenn ip route geteine andere Antwort zurückgegeben wird, handelt es sich möglicherweise um einen Kernel-Fehler. Wenn die richtige Antwort zurückgegeben wird, arpingist die Schuld bei eth0.2, aber das scheint unwahrscheinlich.
Der (incomplete)Eintrag muss nicht entfernt werden; es handelt sich um einen Platzhalter, der dem Kernel mitteilt, dass er versucht hat, diese IP per ARP zu senden, so dass eine ARP-Antwort als gültig angesehen werden sollte und nichtein ARP-Poison-Angriff, aber es wurde keine Antwort gegeben. Es läuft eine Zeitüberschreitung ab.