VPN mówi połączony, ale nic nie jest trasowane: dwa miejsca do sprawdzenia

Tunel może zgłaszać połączenie, choć nic do niego nie dociera, a te dwa fakty mieszkają w różnych miejscach. Jedno to tablica tras, która wciąż może wysyłać pakiety do urządzenia, którego nikt nie posiada. Drugie to resolver, który wciąż może wymieniać serwer na łączu, którego już nie ma. Zmiana sieci nie uszkodziła profilu, osierociła stan należący do poprzedniego połączenia, a naprawa zależy od tego, na które z dwóch faktycznie patrzysz.

Najpierw zapytaj jądro, jakiego urządzenia by użyło

Lista tras pokazuje, co istnieje; wyszukanie trasy pokazuje, co by się stało. Zapytaj o publiczny adres i odczytaj nazwę urządzenia w odpowiedzi, bo to jedno pole decyduje, czy pakiet trafi gdziekolwiek użytecznie. Gdy odpowiedź wskazuje urządzenie tunelu, jądro przekaże mu pakiety, nawet jeśli za tym interfejsem nie działa już żaden proces klienta. Gdy odpowiedź wskazuje kartę fizyczną, a klient twierdzi, że jest połączony, tunel jest podniesiony i po prostu nie jest wybraną ścieżką.

Drugi przypadek jest zwykły po tym, jak kabel zastąpi sieć bezprzewodową, i przedstawia się jako zepsuty VPN.

ip route show default
ip route get 203.0.113.9

Przeczytaj następnie wpisy domyślne, bo trasa dodana przez poprzednie połączenie bazowe może przetrwać zmianę łącza i stać przed nową. Trasa domyślna przez urządzenie, które jest wyłączone, jest gorsza niż brak trasy domyślnej, bo jądro wciąż ją preferuje. Zwróć uwagę na metrykę przy każdym wpisie, bo ta kolejność wyjaśnia preferencję szybciej niż nazwy interfejsów.

Potem czytaj resolver dla każdego łącza, nie dla pliku

Rozwiązywanie nazw niesie własny stan i własną nieaktualność. Resolver wymieniający serwery DNS dla każdego łącza zachowuje serwery łącza tunelu, które jest wyłączone, ale wciąż zarejestrowane, i każde zapytanie czeka wtedy na serwer, który nie odpowie. Objawem jest sieć, która wydaje się martwa, podczas gdy tablica tras wygląda idealnie.

Sprawdzaj stan dla każdego łącza, a nie plik, bo w wielu dystrybucjach ten plik jest dowiązaniem symbolicznym do resolvera, a jego edycja albo nic nie daje, albo jest szybko nadpisywana. Zobacz, które łącze posiada jakie serwery i jaką domenę wyszukiwania, a potem zapytaj, czy łącze tunelu powinno być w ogóle jeszcze zarejestrowane. Jeśli nie, dezaktywuj połączenie, które je posiada, zamiast edytować ręcznie stan generowany. Nazwa, która się rozwiązuje, podczas gdy wyszukanie trasy wysyła pakiety gdzie indziej, to trzecia i odrębna usterka.

resolvectl status
resolvectl query app.internal.example

Jeśli adresy się rozwiązują, a połączenia zawodzą, resolver jest w porządku, a trasa nie. Jeśli adresy w ogóle się nie rozwiązują, to jest właściwe miejsce, aby zacząć.

Jak nieaktualna trasa przeżywa zmianę

Klient nie jest sam właścicielem sieci. Na hoście z NetworkManagerem profil VPN jest aktywowany na połączeniu bazowym, a ustawienia połączenia pozwalają tej bazie wskazać VPN, który powinien za nią podążać. Gdy baza się zmienia, bo inny profil staje się preferowany, tunel przenosi się na nową bazę albo zostaje bez żadnej.

Profil VPN sam się nie podniesie, więc powiązanie w pary znaczy znacznie więcej niż własna preferencja automatycznego łączenia profilu.

Przeczytaj listę aktywnych i zanotuj, która baza jest podniesiona, zanim dotkniesz tunelu. Jeśli baza jest na liście, a tunelu nie ma, trasy brakuje, a nie jest nieaktualna, i naprawą jest aktywacja. Jeśli aktywacja tunelu zgłasza, że nie ma połączenia źródłowego, baza, z którą był w parze, zniknęła, więc najpierw ją podnieś albo napraw powiązanie, zamiast ponownie próbować tunelu. Ponawianie profilu, którego rodzic jest nieobecny, daje za każdym razem ten sam błąd, co jest użytecznym sygnałem, a nie utrapieniem.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Odróżnij nieaktualny stan od brakującego rodzica

Trzy stany wyjaśniają prawie każde zgłoszenie i każdy wymaga innej naprawy. Trasa domyślna przez urządzenie, które jeszcze istnieje, ale nie niesie już tunelu, to stan nieaktualny, usuwany przez skasowanie wpisu albo zrestartowanie odpowiedzialnego profilu. Urządzenie tunelu, którego proces klienta zniknął, to błąd sprzątania, więc uwagi zasługuje ścieżka rozłączenia, a nie tablica tras. Brak jakiegokolwiek urządzenia tunelu oznacza, że brakuje rodzica lub powiązania i tablica tras nigdy nie była w to zamieszana.

Restart ukrywa, który z trzech miałeś, i właśnie dlatego wydaje się naprawą.

Po naprawie zapytaj jądro o jeden adres publiczny i jeden wewnętrzny, a potem odpytaj nazwę wewnętrzną. Gdy adres działa, a nazwa nie, znalazłeś problem zakresu domeny w resolverze, a nie problem routingu. Zapisz, który stan znalazłeś, bo następna zmiana sieci odtworzy ten, który zostawiłeś w spokoju.