Warum ein Full-Tunnel-VPN Ihre gerouteten lokalen VLANs verdeckt

Der Schalter „allow local network“ in einem VPN-Client klingt, als decke er alles im Gebäude ab. In der Praxis fügt er meist nur ein paar Ausnahmen für private Adressen zur Standardroute des Tunnels hinzu und hört dort auf. Ihr Storage-VLAN bleibt nur erreichbar, wenn eine Route für genau dieses Präfix die Ankunft des Tunnels übersteht, und bei vielen Clients tut sie das nicht.

Das ist eine Routing-Frage und keine VPN-Einstellung, was eine gute Nachricht ist: Es gibt eine konkrete Antwort.

Was allow-local-network tatsächlich abdeckt

Clients setzen diese Option unterschiedlich um. Manche fügen Routen für das Subnetz hinzu, an dem die Maschine hängt, manche fügen die RFC-1918-Bereiche hinzu, und einige schließen nur das Standard-Gateway aus. Keiner von ihnen weiß, dass Ihr Bürorouter auch ein Storage-VLAN, ein Lab-Segment oder ein Drucker-Subnetz bedient, denn diese Präfixe liegen nicht auf der Leitung, die der Client sieht. Lesen Sie die Dokumentation des Clients für das genaue Verhalten, statt anzunehmen, das Etikett beschreibe Ihre Topologie.

Am wichtigsten ist der Unterschied bei einem Full-Tunnel-Design, bei dem der Client die Standardroute bewusst ersetzt, damit der gesamte Verkehr durch das VPN läuft. Das ist der ganze Sinn des Designs, und genau das lässt die lokalen gerouteten Netze verschwinden. Sie waren nie durch eine eigene Route abgedeckt; sie fuhren auf der Standardroute mit, die gerade ersetzt wurde. Ein Client kann nicht routen, was er nicht kennt, und er lernt nur Präfixe, die an seine eigene Schnittstelle gebunden sind. Alles andere muss jemand beschreiben, der die Topologie kennt.

Verbundene Routen enden am ersten Router

Eine Workstation auf 192.168.10.20/24 mit Gateway 192.168.10.1 bekommt automatisch eine verbundene Route für 192.168.10.0/24. Das Storage-VLAN auf 192.168.20.0/24 ist ein anderes Präfix, nur über dieses Gateway erreichbar, und die Workstation hat dafür keine Route außer der Standardroute. Bevor der Tunnel hochkommt, schickt die gewöhnliche Standardroute den Storage-Verkehr zufällig an 192.168.10.1, und alles funktioniert.

Wenn das VPN eine Full-Tunnel-Standardroute installiert, folgen Pakete für 192.168.20.1 der neuen Standardroute in den Tunnel. Das entfernte Gateway hat keine Ahnung, wo dieses Präfix liegt, also verwirft es sie oder leitet sie an eine nutzlose Stelle weiter. Am Storage-VLAN war nichts falsch konfiguriert; sein Weg war geliehen, und das Darlehen wurde zurückgerufen.

Die Versuchung ist, zu einer breiten Ausnahme wie einem /1-Routenpaar oder einer zweiten Standardroute zu greifen. Widerstehen Sie dem. Je enger die Ausnahme, desto leichter lässt sie sich erklären, prüfen und entfernen, wenn sich das Netz ändert.

Legen Sie die Ausnahme in die Tabelle, die gewinnt

Innerhalb einer Routing-Tabelle schlägt ein /24 ein /0 oder ein /1 durch die längste Präfixübereinstimmung, eine gezielte Route zum Storage-VLAN über das lokale Gateway genügt also, sofern die Tabelle überhaupt herangezogen wird. Unter Linux ist die übliche Form kurz:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Policy-Routing macht diese Garantie komplizierter. Eine frühere Regel kann Verkehr in eine Tabelle schicken, deren eigene Standardroute in den Tunnel zeigt, und die Haupttabelle mit Ihrem /24 wird dann nie erreicht. Prüfen Sie die Regeln, bevor Sie die Route für maßgeblich halten, denn ein korrekt aussehender Eintrag in der falschen Tabelle erklärt einen Fehler, der wie eine kaputte Route aussieht.

Machen Sie den Eintrag dann dauerhaft, über den vom Client unterstützten Mechanismus oder den Netzwerkmanager, dem die Schnittstelle gehört. Eine in die Eingabeaufforderung getippte Route verschwindet beim nächsten Wiederverbinden, und eine an ein einziges Wi-Fi-Gateway gebundene Route ist nicht auf das nächste Netz übertragbar, das der Laptop besucht.

Namen und Policy folgen keinen Routen

Die Route zu reparieren bringt Pakete zurück, keine Namen. Wenn lokale Geräte über einen aufgedrängten Resolver aufgelöst werden, der nichts über sie weiß, schlägt das Mounten weiterhin fehl, obwohl die Adresse erreichbar ist. Lokale Namen brauchen eine lokale oder geteilte DNS-Regelung, und das ist eine Entscheidung getrennt von der Routenausnahme.

Die Policy ist wieder etwas anderes. Der Filter für lokalen Zugriff eines VPN-Clients kann Verkehr in private Bereiche bewusst verbieten, und eine Route hebelt diese Regel nicht aus. In einem nicht vertrauenswürdigen Netz ist eine private Adresse zudem kein Beweis, dass das Ziel Ihr Storage-Server ist, also sollte die Ausnahme so gezielt sein wie die Route selbst.

Ein Vertrag, den Sie übergeben können

Das fertige Design sollte wie eine kurze Liste lesen: Allgemeiner Internetverkehr folgt dem Tunnel, und diese benannten lokalen Präfixe behalten ihren Weg über den lokalen Router. Schreiben Sie die Präfixe, den nächsten Hop und das zugehörige DNS-Suffix auf, und halten Sie die Liste so kurz, dass jemand sie prüfen kann, ohne eine Routing-Tabelle zu lesen.

Achten Sie auf Überschneidungen zwischen lokalen und entfernten Bereichen. Ein Storage-VLAN, das ein Präfix mit etwas hinter dem VPN teilt, wird zu der Route aufgelöst, die spezifischer ist, und das resultierende Verhalten ist auf eine Weise verwirrend, die unregelmäßig wirkt. Eine Seite neu zu nummerieren ist meist billiger, als die Mehrdeutigkeit ewig zu debuggen.

Testen Sie den Vertrag zweimal: einmal mit aktivem Tunnel und einmal mit abgeschaltetem. Wenn der lokale Pfad nur in einem dieser Zustände funktioniert, ist die Ausnahme noch kein Vertrag.