Im Laufe der vergangenen Dekaden haben wir versucht, das STP weitgehend auszumerzen. Es wurde ersetzt durch hochgradig vermaschte Strukturen, deren Verbindungen alle aktiv sind. Die Wegewahl erfolgt mittels Algorithmen, die aus Sicht der Quelle den optimalen Pfad in Richtung des Ziels bestimmen. Derlei Algorithmen stecken in Routing-Protokollen wie beispielsweise OSPF oder IS-IS.
Beachten Sie meine Wortwahl im vorletzten Satz. Sie soll deutlich machen, dass die Wegewahl pro Richtung erfolgt. Mit anderen Worten: Die Hinrichtung (besser: Hin-Richtung) weiß nichts von der Rück-Richtung. Das Routing kann grundsätzlich asymmetrisch sein. Das macht nichts, denn die Kommunikationspartner merken nichts davon – meistens jedenfalls.
Das ändert sich, wenn Pakete derselben Richtung auf unterschiedlichen Wegen das Ziel erreichen. Es sind dann unterschiedliche Netzkomponenten involviert, die unterschiedlich stark ausgelastet sein können. In solchen Fällen können Pakete auf einem der Wege verzögert werden. Überholvorgänge sind die Folge. Viele Protokolle, insbesondere das TCP, kommen damit klar, solange die Verzögerung nicht zu groß wird. Ich habe jedoch auch schon gesehen, dass derlei Überholvorgänge zu zahlreichen Paketwiederholungen geführt haben, weil Pakete so spät eintrafen, dass der Empfänger nicht mehr mit ihnen gerechnet hatte.
Schwierig wird es, wenn es irgendwo zwischen Quelle und Ziel Komponenten gibt, die erwarten, alle Pakete beider Richtungen zu sehen. Die verbreitetste Spezies solcher Komponenten ist die Firewall. Gab es sie bisher meist an den Grenzen der Netze (am Perimeter), so rücken Firewalls inzwischen mehr und mehr in das Zentrum unserer Netze.
Neulich erst hatte ich das Vergnügen, eine Firewall zwischen Data Center und LAN Core einbauen zu dürfen. Die gesamte Kommunikation zwischen Servern und Clients wie auch Kommunikation zwischen unterschiedlichen Netzen im Data Center sollte damit gefiltert werden. Das Problem des asymmetrischen Routing wird dabei typischerweise mit Hilfe von zwischengeschalteten Layer-2-Netzen umgangen. Alle Knoten eines Firewall Clusters sind beidseitig mit Layer-2 Switches verbunden. Die (virtuellen) IP-Adressen des Clusters werden mittels statischer Routen erreicht.
Und dennoch, nach dem Umbau funktionierte – wie sollte es anders sein – eine Anwendung nicht mehr. Und zwar ausgerechnet die Kartenleser der Zeiterfassung. Natürlich waren alle Filterregeln korrekt. Server und Kartenleser konnten von der Firewall erreicht werden, etc. Allerdings fanden sich im Firewall Log immer wieder Hinweise über verworfene Pakete, wegen „Spoofing“.
Es brauchte eine Weile, bis wir die Ursache dafür gefunden hatten: Wir erfuhren, dass die IP-Adresse des Servers umgestellt werden sollte. Man hatte dem Server eine zweite Netzwerkkarte verpasst und diese in ein anderes Subnetz des Data Center geschaltet. Der „Trick“ bestand also darin, den Server während der Umstellungsphase über zwei IP-Adressen erreichbar zu halten.
Alle Anfragen von den Kartenlesern an den Server wurden von der Firewall korrekt in das entsprechende Subnetz geroutet. Die Antworten des Servers jedoch erreichten die Firewall immer über ein und dasselbe Subnetz, nämlich dasjenige, welches auf dem Server als Default Gateway eingetragen war. Wenn die Firewall also ein Paket bemerkt, dessen Absenderadresse (laut Routing-Tabelle) eigentlich in ein anderes Subnetz gehört, bewertet sie es als „IP Address Spoofing“ und verwirft das Paket.
Fazit
Asymmetrisches Routing ist eine tolle Sache. Firewalls sind es auch. Die Kombination von beidem bereitet zuweilen Kopfzerbrechen. Behalten Sie das im Hinterkopf!
Teile diesen Eintrag