Überbrückte Standorte brauchen weiterhin eine Entscheidung zum lokalen Internetausgang

Die VLAN-Erweiterung lief sauber: Hosts an beiden Standorten sehen sich gegenseitig, Dateifreigaben funktionieren, Drucker antworten. Dann bemerkt jemand am kleineren Standort, dass jeder Download die Internetleitung des anderen Standorts nutzt, und das Ticket kommt als Bandbreitenbeschwerde an. Die Bridge tat genau das, was von ihr verlangt wurde. Sie trug Frames zwischen zwei Gebäuden und hatte nie eine Meinung dazu, welchen Router diese Frames für das Internet nutzen sollten.

Die Bridge trägt Frames, keine Entscheidungen

Eine Layer-2-Erweiterung lässt zwei Standorte wie eine Broadcast-Domäne aussehen, sodass ARP-Anfragen, DHCP-Broadcasts und Verkehr im selben Subnetz alle den Tunnel passieren. Das ist die gesamte Leistung, die sie erbringt. Nichts in der Bridge prüft eine Zieladresse, vergleicht sie mit dem Uplink eines Standorts oder lenkt Verkehr zum näheren Ausgang. Jeder Client trifft weiterhin seine eigene Entscheidung lokal oder remote anhand der Adresse und Maske, mit der er konfiguriert wurde.

Setzen Sie zwei Router in dieses gemeinsam genutzte Subnetz, und beide werden zu plausiblen Gateways, unabhängig davon, ob einer davon nahe am Client liegt, der ihn nutzt.

Wie ein Client sein Gateway wählt

Die in RFC 1122 beschriebene IPv4-Entscheidung ist einfach. Ein Ziel innerhalb des verbundenen Subnetzes des Clients wird direkt per ARP erreicht, ein Ziel außerhalb geht an das konfigurierte Standard-Gateway. Deshalb kann Verkehr im selben Subnetz zwischen den Standorten die Bridge ohne jede Routerbeteiligung passieren, und deshalb hängt der Internetverkehr vollständig von der Gateway-Adresse ab, die der Client erhalten hat. Die beiden Verhalten sind unabhängig, und eine funktionierende Dateifreigabe beweist nur das erste.

Wurde ein Client am kleinen Standort mit dem Router des großen Standorts konfiguriert, passieren seine Internet-Frames zuerst den Tunnel und verlassen ihn dort.

Das Ändern der eigenen Standardroute der VPN-Appliance verschiebt das Gateway dieses Clients nicht, weil der Client die Appliance überhaupt nicht als Router verwendet. Die Appliance braucht außerdem eine separate Route zu ihrem fernen Peer, damit der Tunnel, der diese Frames trägt, bestehen bleibt, und genau das Verwechseln der beiden ist der Weg, auf dem eine Bridge-Erweiterung ihren eigenen Transport lahmlegt.

Lassen Sie DHCP den beabsichtigten Ausgang ausdrücken

Option 3 in einer DHCP-Antwort liefert eine Liste von Routeradressen im Subnetz des Clients in Präferenzreihenfolge, und Clients nehmen normalerweise die erste, die antwortet. Der Mechanismus ist in Ordnung; die Zuständigkeit ist der Punkt, an dem Entwürfe schiefgehen. Halten Sie fest, was ein tatsächlicher Lease an jedem Standort liefert, statt anzunehmen, dass der nächste DHCP-Server das nächste Gateway ausgibt.

Betreiben Sie einen koordinierten Allocator oder zwei, die ausdrücklich für dieselbe Richtlinie konfiguriert sind, und geben Sie der Richtlinie einen Eigentümer. Ein zweiter unabhängiger Allocator am entfernten Standort schafft keine Lokalität, er schafft zwei Autoritäten für dieselbe Broadcast-Domäne.

Weisen Sie eine Gateway-Adresse nicht zwei unabhängig aktiven Routern zu, nur damit die Einstellungen beider Standorte identisch aussehen. Eine gemeinsam genutzte virtuelle Adresse über ein überbrücktes Segment ist ein First-Hop-Redundanzdesign mit eigenen Anforderungen, und eine selbstgebaute Variante erzeugt ARP-Konflikte, die wie sporadischer Paketverlust aussehen. Wenn die Anwendung kein gemeinsames Layer-2-Segment wirklich braucht, sind getrennte geroutete Präfixe mit lokalen Standard-Gateways einfacher zu betreiben und bei einem Vorfall leichter zu erklären.

Testen Sie die vier Dinge getrennt

Bitten Sie um vier Beobachtungen, nicht um eine. Holen Sie sich an jedem Standort einen frischen DHCP-Lease und notieren Sie Router und Maske, die er erhalten hat. Erreichen Sie einen Dienst im selben Subnetz am anderen Standort und bestätigen Sie, dass der Pfad die Bridge ist und kein gerouteter Umweg. Rufen Sie an jedem Standort etwas aus dem öffentlichen Internet ab und bestätigen Sie, welcher Uplink es getragen hat. Ziehen Sie dann den Tunnel ab und schauen Sie, was bricht, denn ein Standort, der bei einem Bridge-Ausfall die gesamte Konnektivität verliert, hing am fernen Gateway, ohne dass es jemandem auffiel.

Diese vier Ergebnisse sagen Ihnen, ob Sie eine Bridge zwischen den Standorten, einen lokalen Ausgang oder einen versehentlichen Backhaul haben, und das Sammeln dauert zehn Minuten.

Das Entwurfsprinzip ist unglamourös: Bridging entscheidet über Erreichbarkeit, DHCP entscheidet über das Gateway, und die Routing-Tabelle der Appliance entscheidet über den eigenen Pfad des Tunnels. Halten Sie die drei in getrennten Gesprächen, denn eine einzelne Änderung, die alle drei reparieren will, zerstört meist zwei.