pull-filter vergleicht Text, keine Subnetze: als Präfix lesen
Der Filter vergleicht den Anfang jeder gepushten Option mit Ihrem Text. Ein fehlendes Leerzeichen, eine breite frühere Regel und die falsche Aktion erzeugen verschiedene Fehler.
Die Absicht war, eine gepushte Route zu verwerfen. Nach der Änderung fehlt eine andere Routing-Option, oder der Client verbindet sich in einer Schleife neu. Beide Ergebnisse entstehen daraus, den Filter als Subnetzregel zu lesen, obwohl er Text vergleicht. Der Client prüft, ob eine gepushte Option mit den von Ihnen angegebenen Zeichen beginnt, und an keiner Stelle ist Adresslogik beteiligt.
Was der Filter tatsächlich vergleicht
Jede gepushte Option kommt als Zeile aus einem Namen und seinen Argumenten an. Der Filter vergleicht Ihre Zeichen mit dem Anfang dieser Zeile, bevor eine Adresse ausgewertet und bevor eine Route installiert wird. Eine für einen Namen geschriebene Regel erfasst daher jede Option, die mit diesen Buchstaben beginnt, nicht nur die, die Sie gerade betrachtet haben. Deshalb kann ein Filter isoliert korrekt aussehen und trotzdem etwas Unbeteiligtes entfernen.
Eine Zeichenkette, die wie ein Netzbereich aussieht, bleibt nur Text. Sie wählt kein Präfix, rechnet nicht mit Netzbits und kann keine Menge von Zielen ausdrücken. Wenn eine solche Regel zu funktionieren scheint und später aufhört, hat der gepushte Text meistens seine Form geändert.
Ein Leerzeichen ändert die Treffermenge
Derselbe Optionsname mit und ohne abschließendes Trennzeichen wählt verschiedene Zeilen. Ohne das Trennzeichen bleibt der Treffer offen, mit ihm muss der Optionsname genau dort enden, bevor die Argumente beginnen.
pull-filter ignore "route"
pull-filter ignore "route "Die offene Form erfasst auch Optionen, die nur mit denselben Buchstaben beginnen, und so verschwindet unabhängiges Routingverhalten zusammen mit der Route, die Sie verwerfen wollten. Kopieren Sie die gepushte Zeile aus dem Protokoll, bevor Sie den Filter schreiben. Bewahren Sie eine unveränderte Kopie des Profils neben der bearbeiteten auf, denn eine breite Übereinstimmung lässt sich leichter aus einer Datei als aus dem Gedächtnis zurücknehmen.
Reihenfolge und Aktion erzeugen verschiedene Symptome
Regeln werden der Reihe nach bewertet, und der erste Treffer entscheidet das Ergebnis, sodass eine früh platzierte breite Regel jede spätere spezifische Regel unerreichbar macht. Auch die Aktion verändert den Fehler: Ignorieren verwirft die Option und die Sitzung läuft weiter, während Zurückweisen einen Fehler auslöst, der die Verbindung neu startet. Eine wiederholt gepushte Zeile erzeugt zusammen mit der zurückweisenden Aktion daher einen Wiederverbindungszyklus. Dieser Zyklus wird leicht als Netzwerkfehler gelesen, und die Protokollzeile, die die getroffene Option nennt, trennt beides.
| Action | Effect on the session | How it gets reported |
|---|---|---|
| Ignore | Option dropped, session continues | Something is missing afterwards |
| Reject | Error raised, connection restarts | The VPN keeps dropping |
Notieren Sie, welche Zeile getroffen hat und welche Aktion lief. Eine verworfene Route und eine Neustartschleife brauchen verschiedene Reparaturen, und die Notiz sollte sagen, welche von beiden eingetreten ist, statt beide offen zu lassen.
Prüfen Sie, was der Host installiert hat
Lesen Sie nach dem erneuten Verbinden die angewendeten Routen und testen Sie sowohl das Ziel, das Sie erhalten wollten, als auch das, das Sie entfernen wollten. Das Verwerfen einer gepushten Route liefert keinen Ersatz, daher kann eine Ressource über einen anderen Pfad unerreichbar werden, während die unerwünschte Route verschwunden ist. Löst ein Name jetzt woanders auf, prüfen Sie, ob die gepushte Resolver-Option von demselben breiten Präfix erfasst wurde. Eine Änderung, die den von Ihnen ausgeführten Test besteht und den beabsichtigten nicht, ist hier das normale Ergebnis.
Halten Sie diesen Unterschied im Ticket fest: die entfernte Route, die erwartete Route und was die Tabelle jetzt zeigt. Die nächste Änderung wird an diesem Datensatz gemessen.
Behandeln Sie es nicht als Vertrauensgrenze
Ein Filter über Text ist eine Konfigurationsannehmlichkeit, keine Kontrolle gegen einen Server, dem Sie nicht vertrauen. Schon Formatierungsvarianten besiegen ihn, weshalb das Handbuch diese Behauptung einschränkt. Gehört der Server Ihrer Organisation, ist die Korrektur der Push-Richtlinie klarer als das Ansammeln lokaler Ausnahmen.
Schreiben Sie auf, warum der lokale Filter überhaupt existiert, damit die nächste Person entscheiden kann, ob er noch nötig ist. Filter sammeln sich lange nach dem Verschwinden ihres Grundes an.