Dlaczego usunięta trasa VPN wraca po ponownym połączeniu

Trasa, którą usunąłeś ręcznie, wraca po następnym ponownym połączeniu, a tabela wygląda dokładnie tak jak wcześniej. To nie błąd routingu: coś odtwarza wpis z konfiguracji lub z akcji cyklu życia połączenia. Większość runbooków zatrzymuje się na aktywnej tabeli, dlatego usunięcie wydaje się działać przez minutę, a potem zawodzi. Zidentyfikuj właściciela, zmień go i udowodnij to przy ponownym połączeniu.

Kto zainstalował trasę

Zacznij od listy kandydatów, a nie od poprawki. Profil VPN może nieść własne trasy, serwer może je pushować przy połączeniu, profil menedżera sieci może je deklarować, jednostka rozruchowa lub skrypt może je dodawać, a implementacje IPsec instalują trasy dla negocjowanych selektorów ruchu. Reguły routingu politycznego mogą też całkowicie przekierować ruch do innej tabeli.

Czas rozdziela je szybciej niż archeologia konfiguracji. Wpis, który pojawia się w momencie podniesienia interfejsu, należy do klienta; ten, który przychodzi sekundę później, zwykle pochodzi z pusha serwera; ten, który istnieje przy starcie, należy do zapisanej konfiguracji. Zarejestruj tabelę przed i po połączeniu, rozłączeniu i ponownym uruchomieniu, a wzorzec wskaże właściciela. Trasa, która wraca tylko przy restarcie usługi, wskazuje na jednostkę, a nie na VPN.

Przeczytaj tabelę, zanim ją edytujesz

Patrz na własny widok jądra, a nie na zapisany plik. Kolumna protokołu pokazuje, co zainstalowało każdy wpis:

ip route show
ip route show table all
ip rule show

Pole protokołu, metryka i numer tabeli mówią ci, czy patrzysz na wpis statyczny, wpis utworzony przez jądro, czy coś dodanego przez demona. Lista reguł ma znaczenie, bo wyszukiwanie może całkowicie opuścić główną tabelę, co czyni edycję tam niewidoczną dla aplikacji, którą debugujesz. Czytaj wiersz od lewej do prawej: cel, brama, urządzenie, protokół i metryka.

Następnie zapytaj jądro, której trasy naprawdę by użyło. Adres chroniony jest lepszą sondą niż publiczny:

ip route get 10.20.5.7

Zmień właściciela, nie objaw

Gdy właściciel jest znany, zmiana należy do tego właściciela. Usuń trasę z profilu klienta, popraw pushowaną trasę na serwerze lub edytuj połączenie menedżera sieci, zamiast dodawać konkurencyjną stałą trasę, która wygrywa metryką. Dwie walczące ze sobą reguły tworzą tabelę, której nikt później nie potrafi wyjaśnić.

Zachowaj wykluczenie punktu końcowego. Trasa do hosta, która wysyła własny publiczny adres serwera VPN przez fizyczną bramę, jest tym, co utrzymuje przepływ zewnętrznych pakietów tunelu; usuń ją, a tunel spróbuje nieść sam siebie. W profilu split-tunnel ta sama ostrożność dotyczy lokalnych podsieci, które mają omijać tunel.

Połącz się ponownie i zweryfikuj obie ścieżki

Połącz się ponownie, a następnie sprawdź oba cele w jednym przebiegu. Adres chroniony i wykluczony punkt końcowy odpowiadają na różne pytania:

ip route get 10.20.5.7
ip route get 198.51.100.20

Pierwszy powinien się rozwiązać przez interfejs tunelu, a drugi przez fizyczną bramę. Jeśli oba rozwiązują się przez tunel, brakuje wykluczenia; jeśli żaden, zmiana profilu nie zadziałała i patrzysz na innego właściciela, niż myślałeś.

Zapisz cel trasy, jej właściciela i jak długo powinna żyć. Ta notatka powstrzymuje następną osobę przed powtórzeniem tego samego cyklu usuwania i ponownego łączenia.