VPN-Client löscht Ihre hinzugefügte Route? Verwenden Sie eine Policy-Tabelle
Der Client setzt die Routen, die er besitzt, immer wieder durch, sodass ein manuell hinzugefügter Eintrag in Sekunden verschwindet. Legen Sie die Ausnahme in eine Policy-Tabelle mit einer Regelpriorität, die gewinnt.
Ein /24 für einen Labor-Drucker verschwindet zwischen zwei Aufrufen von ip route show, und das Client-Log sagt nur, dass sich das Netzwerk geändert habe. An dem Befehl, dem Präfix oder Ihren Rechten war nichts falsch. Ein Unternehmensclient, dem das Routingmodell des Hosts gehört, setzt dieses Modell bei jeder fremden Änderung erneut durch, sodass der von Ihnen hinzugefügte Eintrag als Eindringling entfernt wird. Dagegen in derselben Tabelle zu kämpfen, ist eine aussichtslose Position. Die Lösung besteht darin, den Wettstreit um diese Tabelle ganz aufzugeben und die Ausnahme dorthin zu legen, wo der Monitor nie nachsieht.
Der Monitor erklärt die fehlende Route
Zeigen Sie es, bevor Sie irgendetwas umbauen: Lesen Sie die Tabelle, fügen Sie das Präfix hinzu, warten Sie ein paar Sekunden, lesen Sie erneut. Fehlt der Eintrag und haben Sie nichts zu seiner Entfernung eingegeben, wacht ein Agent. Finden Sie den Prozess, dem dieses Verhalten gehört, und lesen Sie sein Journal um den Moment, in dem die Route verschwindet, denn derselbe Dienst verwaltet meist auch den Tunnel, die Paketfilter und die Resolver-Konfiguration. Ihn zu töten, damit Ihre Route bleibt, ist ein Tausch, den Sie beim nächsten Wiederverbinden bereuen werden.
ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route showPräfix und Schnittstelle oben sind Platzhalter. Einen Schnittstellennamen aus einem funktionierenden Beispiel auf einer anderen Maschine zu kopieren, ist der häufigste Grund, warum diese Demonstration überhaupt nichts liefert.
Eine zweite Tabelle ist für den Monitor unsichtbar
Der Agent baut nur die Tabelle neu auf, die ihm gehört. Geben Sie der Ausnahme eine eigene Tabelle plus eine Regel, die passende Ziele dorthin schickt, und die Haupttabelle ändert sich nie, sodass es für den Agenten nichts zu korrigieren gibt. Das ist die ganze Idee: ein Namensraum von Routen, den jemand anders pflegt, und einer, den nur Sie anfassen.
Der Preis ist Wartung. Zwei Objekte können auseinanderdriften, und die Position der Regel in der Liste zählt genauso viel wie die Route in der Tabelle, die sie auswählt.
Bauen Sie die Ausnahme und lassen Sie sie gewinnen
Erstellen Sie die Tabelle, installieren Sie die Route und fügen Sie eine Regel hinzu, die für dieses Ziel die Tabelle auswählt. Die Priorität entscheidet, ob Ihre Regel vor oder nach denen geprüft wird, die der Client eingefügt hat, und eine später einsortierte Regel wird nie erreicht, also ist die Nummer Teil des Entwurfs und keine Dekoration. Fragen Sie dann den Kernel, was er tatsächlich tun würde – eine andere Frage als die, was Sie konfiguriert haben.
ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50ip route get löst die Route auf, die der Kernel verwenden würde, einschließlich Gerät und Quelladresse. Die Tabellenkennung wird nicht ausgegeben, also kombinieren Sie es mit ip rule show, wenn Sie bestätigen müssen, welche Tabelle gewonnen hat. Zusammen beantworten sie die einzige wichtige Frage: Verlässt der Verkehr zu dieser Adresse dort, wo Sie es beabsichtigt haben?
Andere Formen derselben Idee
Das Muster verallgemeinert sich, sobald Sie aufhören, in Zielen zu denken. Ein lokales Subnetz kann erreichbar bleiben, während der Tunnel die Standardroute behält. Antworten von einem per LAN angebundenen SSH-Server können über die Schnittstelle hinausgehen, über die sie ankamen, statt im Tunnel zu verschwinden. Und eine schnittstellenbasierte Regel kann alles, was auf einer drahtlosen Schnittstelle ankommt, in den Tunnel schieben, während Verkehr, den der Host selbst erzeugt, auf Ethernet bleibt:
ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10Der letzte Fall passt auf die eingehende Schnittstelle statt auf das Ziel, was ein anderer Regeltyp und ein anderes Denkmodell ist. Weitergeleiteter Verkehr braucht außerdem aktiviertes net.ipv4.ip_forward, und die Gegenseite muss den Quellbereich zurückrouten oder übersetzen; eine Regel auf einer Maschine erzeugt nie die andere Hälfte des Pfads.
Behandeln Sie die Regel als Wegwerfware
Regeln und Tabellenrouten leben im Speicher. Nach einem Wiederverbinden kann das Tunnelgerät umbenannt werden, die zugewiesene Adresse kann sich verschieben, und eine Regel mit dem alten Wert passt stillschweigend nicht mehr. Wenden Sie die gesamte Änderung aus einem einzigen Skript an, das sie besitzt, und prüfen Sie dann ip rule show, den aktuellen Gerätenamen und ein frisches ip route get gegen ein echtes Ziel, bevor Sie der Ausnahme trauen.
Zwei Grenzen überleben jede Sorgfalt. Der Client kontrolliert weiterhin seine eigenen Filterregeln und die Resolver-Konfiguration, und eine Routing-Ausnahme hebt keines von beidem auf. Löscht der Client auch Ihre Policy-Regel, sind die unterstützten Wege seine eigene Split-Tunnel-Policy oder ein Client, der Sie Routen verwalten lässt, etwa OpenConnect; ein Hersteller-Binary zu patchen, um seinen Monitor stummzustellen, ist eine Wartungsverpflichtung mit angehängter Integritätsprüfung.
Schreiben Sie Tabellennummer, Priorität und Ziel in eine Notiz neben das Skript. Sonst findet die nächste Person eine Regel, die den Tunnel überstimmt, und hat keine Möglichkeit zu wissen, warum.