Es ist mal wieder… öhm… Montag? Ok, dann halt mal Montags. Ein Problem aus der Kategorie seltene Wunder. Kann man auch mal Montags machen. Zwei Rechner, zwei Netze, mitten drin die Firewall. Ping von einem Rechner auf den anderen geht, ein Netzlaufwerk verbinden geht allerdings nicht. Klingt nach Firewall. Oder doch nicht?
Erstmal etwas mehr Überblick verschaffen, somit hier ein paar weitere Informationen rund um das Netzwerk im Allgemeinen:
- Die beiden betroffenen Netze sind 10.0.1.0/24 und 10.0.2.0/24. Allerdings teilen sich diese beiden Netzwerke die gleiche Switch-Umgebung, es gibt keine VLANs.
- Die Firewall hat in beiden Netzen eine eigene IP und dient als Default Gateway zwischen diesen Netzen. Da diese auf dem gleichen Switch laufen verwenden diese auf der Firewall für beide Netze auch nur einen Netzwerkanschluss.
- Auf der Firewall gibt es folgende Regel: Erlaube alles von den obigen Netzwerken sofern es wieder in diese Netzwerke geht. Diese Regel steht ganz oben, somit alles gut.
- Auf den beiden Rechnern gibt es keinerlei Firewall oder sonstige Software die Netzwerkverbindungen blockieren täte.
Somit, oh Wunder: Die Firewall schreibt nichts auf. Klar, die Regel erlaubt doch eigentlich alles. Ping geht, das Verbinden auf ein Netzlaufwerk scheitert mit einem Timeout. Also grundlegend muss die Konnektivität ja da sein. Sonst würde der ping ebenfalls scheitern.
Was nun? Irgendwas ist seltsam, also weiter geht die Suche. Im nächsten Schritt habe ich auf der Firewall einen tcpdump (https://www.tcpdump.org/) gestartet um den durchlaufenden Netzwerkverkehr auszuwerten. Vielleicht finden sich hier weitere Hinweise. Und in der Tat, die Aufzeichnung war sehr interessant. Am Beispiel ping und Netzlaufwerk wurden folgende Pakete aufgezeichnet: der echo reply sowie beim Versuch des Zugriffs auf das Netzlaufwerk das SYN-ACK Paket. Mehr nicht.
Es fehlen also der echo request und das erste SYN Paket vom TCP 3-Wege-Handshake. Wer jetzt noch keinen Verdacht auf die Ursache hegt kann weiter suchen: Die Firewall sieht die Antwort auf den ping, jedoch keine Frage. Ebenso sieht es die Antwort auf den Versuch die Verbindung eines Netzlaufwerkes herzustellen. Aber nur die erste Antwort und sonst nichts. tcpdump lügt nicht – da nicht angezeigt kam der echo request also nie an der Firewall vorbei. Dennoch funktionierte der ping. Somit muss die Frage wohl direkt an das Ziel gesendet worden sein. Und siehe da, ein arp -a zeigte neben Adressen aus dem eigenen Netz auch Adressen aus dem anderen Netz an. Das ist jetzt allerdings seltsam und sollte so nicht sein.
Ergibt aber zusammengefasst Sinn: Rechner 1 sieht in der arp Tabelle beide Netze und stellt deswegen die Frage an Rechner 2 direkt. Dieser sieht in der arp Tabelle allerdings zur sein eigenes Netz und geht, so wie er soll, über die Firewall. Das ist also der Grund warum die Firewall beim tcpdump nur die Antworten sieht. Fehlt noch die Ursache für dieses Verhalten. Auch das ist rasch gefunden: Wenn Rechner 1 beide Netze direkt anspricht, dann sind diese auch direkt für ihn erreichbar. Und die Aussage welche Netze erreichbar sind trifft die Netzmaske bei einer IP.
Und genau hier war der Fehler versteckt: Rechner 2 hatte wie dokumentiert die Maske 255.255.255.0, also /24. Rechner 1 allerdings hatte einen Tippfehler drin und als Maske /23 was der 255.255.254.0 entspricht. Korrigiert und schon läuft alles so wie es soll. Die Welt kann schön sein. Nochmals spicken wie die Netzmaske funktioniert? Dass kannst Du hier tun: https://de.wikipedia.org/wiki/Netzmaske.
Was wurde es als Weltverbesserung gepriesen als die PC-Architektur von 32 nach 64 Bit gewechselt hat. Ganze 32 Bit mehr. Hier hat bereits ein einziges Bit bei der Maske mehr gereicht um für ordentlich Wirbel zu sorgen.