FortiClient-Volltunnel: nur das Büro-Subnetz routen

Der Tunnel kommt hoch, das Symbol wird grün, und das lokale Netz verschwindet: Drucker, das NAS und der Büro-Router antworten alle nicht mehr. FortiClient tut, was das Profil verlangt hat. Das Gateway hat eine Standardroute geschoben, der Client hat sie installiert, und jedes Paket hat jetzt einen Weg in den Tunnel. Die Reparatur ist eine Änderung der Routentabelle mit einer DNS-Änderung dahinter, und die Reihenfolge dieser Änderungen entscheidet, ob die Maschine besser oder schlechter aus der Sache herauskommt.

Was der Client installiert hat und warum das LAN verschwand

Lesen Sie zuerst die Tabelle statt die Client-Oberfläche. Unter macOS gibt netstat -rn die ganze Tabelle aus, und route -n get default nennt Interface und Metrik, die gerade gewinnen; unter Linux ist das Paar ip route show und ip route get 8.8.8.8. Beide beantworten eine Frage: Welcher Eintrag trägt ein Paket, das auf nichts Spezifischeres passt.

Der Name des Tunnelgeräts ist nicht fest. Ein IKEv2-Profil unter macOS zeigt meist utun mit einer Nummer, der SSL VPN-Client zeigt ppp0, und OpenVPN zeigt tun0. Zwei Standardrouten können auch gleichzeitig mit unterschiedlichen Metriken vorhanden sein, und der Client-Eintrag übernimmt vielleicht erst nach einer Neuverbindung und nicht in dem Moment, in dem er erscheint. Deshalb können zwei Tabellenauszüge im Abstand von fünf Minuten unterschiedliche Geschichten erzählen.

Warum die Tunnel-Standardroute zuerst weg muss

Der Kernel wählt das längste passende Präfix, und wenn mehrere Routen gleich spezifisch sind, wählt er die mit der niedrigsten Metrik. Ein Client, der 0.0.0.0/0 mit einer besseren Metrik installiert, gewinnt daher jedes Ziel, ohne die ursprüngliche Standardroute zu löschen, und deshalb steht die physische Route noch in der Tabelle und erklärt noch den Ausfall. Erst die Tunnel-Standardroute zu entfernen stellt das frühere Verhalten wieder her. Erst danach tut eine Präfixroute durch den Tunnel, was ihr Autor beabsichtigt hat.

Präfixe vor diesem Schritt hinzuzufügen ist der Fehler, der eine halb funktionierende Maschine erzeugt. Der Verkehr für das neue Präfix folgt dem Tunnel, und alles Nichtgelistete folgt ebenfalls der Tunnel-Standardroute, sodass nichts kaputt aussieht, bis jemand einen Dienst öffnet, den niemand hinzugefügt hat. Löschen, wiederherstellen, dann hinzufügen, und der Zwischenzustand bleibt vorhersagbar.

Die Reihenfolge unter macOS und unter Linux

Unter macOS löscht die Reihenfolge die Tunnel-Standardroute, stellt die physische Standardroute wieder her und schickt ein Büro-Präfix zurück in den Tunnel. Ersetzen Sie die beispielhaften Interface-Namen hier durch die aus Ihrer eigenen Tabelle.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

Unter Linux nutzt dieselbe Reihenfolge ein anderes Werkzeug, mit dem LAN-Gateway für die Standardroute und dem Tunnelgerät für das Büro-Präfix. Der alte Befehl route akzeptiert noch die alte Syntax, aber ip route ist die Form, die zur aktuellen Dokumentation passt.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Wenn die Route einen nächsten Hop statt eines Geräts braucht, nehmen Sie den Peer aus der Client-Ausgabe. Raten erzeugt einen von zwei Fehlern, und sie bedeuten Verschiedenes: Ein falsches Gateway liefert sofort network unreachable, während ein falsches Tunnelziel einen Timeout liefert. Lesen Sie, welchen Sie bekommen haben, bevor Sie den Befehl erneut ändern.

Präfixe, der Resolver und die DMZ, die dunkel bleibt

Ein Präfix deckt die Arbeit selten ab. Anwendungsserver, Management-Netze, die DMZ und die DNS-Server selbst können jeweils in einem anderen Bereich liegen, listen Sie also jeden Bereich auf, den Sie benennen können, bevor Sie anfangen, und testen Sie neben jedem Ping eine Namensauflösung. Ein Ziel, das mitten im Test entdeckt wird, ist das, das im Änderungsnachweis vergessen wird. Eine Route, die per Adresse antwortet, aber per Name scheitert, ist meist ein Resolver-Problem im Routing-Kostüm.

Der Resolver ist eine eigene Entscheidung. Wenn das Profil interne DNS-Server geschoben hat, kann das Wegnehmen der Standardroute diese Adressen für öffentliche Namen unerreichbar machen oder nur durch den Tunnel erreichbar lassen, und beide Zustände erzeugen verwirrende Teilergebnisse. Routen Sie die Resolver-Adressen durch den Tunnel, oder konfigurieren Sie die Auflösung pro Domäne, sodass öffentliche Abfragen den lokalen Resolver nutzen.

Der Linux-SSL-Client hat einen feldspezifischen Fehler, den man kennen sollte: Der Tunnel verbindet, das Büro-LAN antwortet, und ein DMZ-Bereich bleibt dunkel. Das fehlende Stück ist eine Route für diesen Bereich über das Tunnel-Gateway, und das Gateway unterscheidet sich zwischen Maschinen, also ist eine fest kodierte Adresse der Weg, auf dem das nächste Notebook bricht. Leiten Sie sie aus dem Client-Zustand ab und halten Sie den Befehl selbstdokumentierend:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Lesen Sie die beiden Werte, bevor Sie ihn ausführen. peer ist das ferne Ende eines Punkt-zu-Punkt-Tunnels, und das ist die Adresse, die die DMZ-Route braucht; bei einem gerouteten Tunnel ist das Äquivalent das Interface oder das Gateway, das der Client meldet. Erscheint keins von beiden, ist der Client nicht in dem Modus, den Sie angenommen haben.

Nach der nächsten Verbindung und wann man das lokal sein lassen sollte

FortiClient verbindet sich nach einem Ruhezustand oder einem Netzwerkwechsel neu und installiert wieder, was das Profil vorgibt. Manuelle Routen überleben daher nur bis zur nächsten Verbindung, und das ist genau das Intervall, in dem ein einzelner erfolgreicher Test wie eine Lösung aussehen kann. Eine Route, die über Nacht verschwindet, ist erwartetes Verhalten, kein neuer Fehler.

Es gibt zwei dauerhafte Antworten. Ein Skript, das die Korrektur nach jeder Verbindung erneut ausführt, ist ein Workaround, der seinen Autor überleben kann, während ein Split-Tunnel-Profil vom Gateway-Administrator die eigentliche Lösung ist, weil der Client dann nur die Bereiche installiert, die die Arbeit braucht. Bitten Sie um das zweite und nutzen Sie das erste nur, solange Sie warten. Prüfen Sie außerdem die Richtlinie, der Sie zugestimmt haben, bevor Sie einen Volltunnel lokal aufteilen, denn das entfernte Netz verlässt sich möglicherweise darauf, den gesamten Verkehr zu sehen.

Die Checkliste ist kurz: Tabelle lesen, Tunnel-Standardroute löschen, LAN-Standardroute wiederherstellen, jedes Präfix hinzufügen, Auflösung separat reparieren und erwarten, dass die Routen bei der Neuverbindung zurückkehren.