Zamiarem było odrzucenie jednej wypchniętej trasy. Po zmianie brakuje innej opcji routingu albo klient ponownie łączy się w pętli. Oba wyniki biorą się z czytania filtra jako reguły podsieci, choć porównuje on tekst. Klient sprawdza, czy wypchnięta opcja zaczyna się od podanych znaków, i na żadnym etapie nie uczestniczy logika adresów.

Co filtr naprawdę porównuje

Każda wypchnięta opcja przychodzi jako wiersz złożony z nazwy i jej argumentów. Filtr porównuje Twoje znaki z początkiem tego wiersza, zanim zostanie przeanalizowany jakikolwiek adres i zanim zostanie zainstalowana jakakolwiek trasa. Dlatego reguła napisana dla nazwy łapie każdą opcję zaczynającą się tymi literami, nie tylko tę, na którą patrzyłeś. Właśnie dlatego filtr może wyglądać poprawnie w izolacji, a mimo to usuwać coś niezwiązanego.

Ciąg, który wygląda jak zakres sieci, nadal jest tylko znakami. Nie wybiera żadnego prefiksu, nie wykonuje arytmetyki na bitach sieci i nie potrafi wyrazić zbioru celów. Gdy taka reguła wydaje się działać, a potem przestaje, wypchnięty tekst zwykle zmienił kształt.

Jedna spacja zmienia zbiór dopasowań

Ta sama nazwa opcji z separatorem końcowym i bez niego wybiera różne wiersze. Bez separatora dopasowanie pozostaje otwarte, a z nim nazwa opcji musi się skończyć dokładnie tam, zanim zaczną się argumenty.

pull-filter ignore "route"
pull-filter ignore "route "

Otwarta forma łapie też opcje, które tylko zaczynają się tymi samymi literami, i tak niezwiązane zachowanie routingu znika razem z trasą, którą chciałeś odrzucić. Skopiuj wypchnięty wiersz z dziennika, zanim napiszesz filtr. Trzymaj niezmienioną kopię profilu obok edytowanej, bo szerokie dopasowanie łatwiej cofnąć z pliku niż z pamięci.

Kolejność i akcja dają różne objawy

Reguły są oceniane po kolei i pierwsze dopasowanie decyduje o wyniku, więc szeroka reguła umieszczona wcześnie czyni każdą późniejszą konkretną regułę nieosiągalną. Akcja też zmienia awarię: zignorowanie dopasowania odrzuca opcję i sesja trwa, a odrzucenie podnosi błąd, który restartuje połączenie. Dlatego wiersz wypychany wielokrotnie razem z akcją odrzucania tworzy cykl ponownego łączenia. Ten cykl łatwo odczytać jako awarię sieci, a wiersz dziennika nazywający dopasowaną opcję rozdziela oba przypadki.

ActionEffect on the sessionHow it gets reported
IgnoreOption dropped, session continuesSomething is missing afterwards
RejectError raised, connection restartsThe VPN keeps dropping

Zapisz, który wiersz pasował i która akcja została wykonana. Odrzucona trasa i pętla restartów wymagają różnych napraw, a notatka powinna powiedzieć, który z nich nastąpił, zamiast zostawiać oba otwarte.

Sprawdź, co zainstalował host

Po ponownym połączeniu przeczytaj zastosowane trasy i przetestuj cel, który chciałeś zachować, oraz ten, który chciałeś usunąć. Odrzucenie wypchniętej trasy nie daje zamiennika, więc zasób może stać się nieosiągalny inną drogą, gdy niechciana trasa zniknęła. Jeśli nazwa jest teraz rozwiązywana gdzie indziej, sprawdź, czy wypchnięta opcja resolvera została złapana przez ten sam szeroki prefiks. Zmiana, która przechodzi test przez Ciebie uruchomiony i nie przechodzi zamierzonego, jest tu normalnym wynikiem.

Zachowaj tę różnicę w zgłoszeniu: trasę, którą usunąłeś, trasę, którą spodziewałeś się zachować, i to, co tabela pokazuje teraz. Następna zmiana będzie oceniana względem tego zapisu.

Nie traktuj tego jako granicy zaufania

Filtr na tekście to wygoda konfiguracji, a nie kontrola wobec serwera, któremu nie ufasz. Same warianty formatowania go pokonują, dlatego podręcznik ogranicza to twierdzenie. Gdy serwer należy do Twojej organizacji, jaśniejsze jest poprawienie polityki wypychania niż gromadzenie lokalnych wyjątków.

Zapisz, dlaczego lokalny filtr w ogóle istnieje, aby następna osoba mogła zdecydować, czy jest jeszcze potrzebny. Filtry gromadzą się długo po zniknięciu przyczyny.

Powiązane artykuły