VPN połączony, ale jedna usługa zawodzi: wyizoluj etap

„Połączono” to najmniej informacyjny fakt w zgłoszeniu VPN. Zapisuje, że dwie strony zakończyły handshake, i nic o zapytanej nazwie, interfejsie, przez który pakiet wyszedł, jego rozmiarze ani o tym, czy strona odległa go przyjęła. Dlatego jedna usługa może zawodzić, podczas gdy każda inna aplikacja na tym samym laptopie działa. Przejdź etapy po kolei, a pierwszy, który zawiedzie, nazwie usterkę.

Zacznij od nazwy, nie od tunelu

Rozwiąż, zanim zaczniesz trasować, bo zła odpowiedź czyni każdy późniejszy test bezsensownym. Zapytaj o nazwę przez resolver systemowy i porównaj tę odpowiedź z adresem, którego aplikacja rzeczywiście użyła. Prywatna nazwa, która wraca jako adres publiczny, oznacza, że zapytanie poszło do resolvera, który nie ma nic do odpowiadania. Nazwa, której nie da się rozwiązać, to ta sama kategoria, tylko głośniej.

resolvectl query host.internal
getent hosts host.internal

Przeglądarki z własnym ustawieniem bezpiecznego DNS zawodzą tutaj, podczas gdy reszta systemu działa. Dlatego skarga dotycząca tylko przeglądarki należy najpierw do tego etapu, zanim ktokolwiek dotknie trasy. Porównaj oba polecenia, a nie jedno, bo getent idzie ścieżką NSS, a zapytanie do resolvera nie.

Zapytaj jądro, którą ścieżkę wybrało

Tablica routingu to kolejność preferencji, a ścieżka wybrana przez jądro nie zawsze jest tą z diagramu. Zapytaj je bezpośrednio o dane miejsce docelowe. Odpowiedź wskazuje interfejs, następny skok i adres źródłowy, który zostanie użyty. Pakiet może wyjść przez tunel z adresem źródłowym, który strona odległa odrzuca, a bardziej szczegółowy wpis w tablicy fizycznej może wysłać go przez interfejs Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Czytaj pola dev, via i src w tej kolejności, bo każde usuwa inne podejrzenie. Ten etap odpowiada też za stan zainstalowany przez klienta, bo reguły zapory i trasy mogą pozostać po nieprawidłowym wyjściu. Dlatego „brak internetu bez tunelu” i „brak internetu, jeśli klient nie działa” to jedna rodzina awarii, nie dwie.

Sprawdź rozmiar pakietu

Mała odpowiedź, która wraca, gdy duży transfer się zatrzymuje, wskazuje najpierw na MTU ścieżki. Jedna sonda z ustawionym bitem do-not-fragment, wysłana z wnętrza tunelu, oddziela ten etap od pozostałych. Zwiększaj ładunek, aż sonda zawiedzie, i masz liczbę, która ma znaczenie.

ping -M do -s 1400 10.20.30.40

Małe sondy przechodzą, gdy listowanie katalogu lub wysyłanie pliku wisi — to sygnatura tego etapu. Skarga brzmi jak dane logowania albo reguła zapory, a nie jest ani jednym, ani drugim.

Liczba jest właściwością ścieżki, nie klienta, więc wartość działająca na połączeniu biurowym może zawieść na łączu mobilnym. Zachowaj polecenie sondy przy zgłoszeniu, bo następna osoba potrzebuje tego samego pomiaru. Jeśli przechodzi mniejszy ładunek, rozwiązaniem jest clamp lub niższe MTU tunelu, a nie nowy szyfr.

Sprawdź stronę odległą

Sprawdź cel po jego adresie, a potem zobacz, co tam nasłuchuje. Odmowa połączenia i połączenie, które nigdy nie odpowiada, to różne ustalenia. Pierwsze mówi, że coś działa i nie obsługuje tego portu, a drugie, że nic nie wróciło. Żadne z nich nie jest domyślnie problemem klienta.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nic osiągalnego przez tunel nie może być usługą nasłuchującą tylko na 127.0.0.1, bo nasłuchujący nigdy nie widzi pakietu. Gdy zapora zdalnego hosta pozwala na podsieć biurową i odrzuca pulę tunelu, wynik wygląda jak awaria klienta i nią nie jest. Pulpit zdalny lub udostępnianie plików, które się psują, gdy ruch webowy przetrwa, zwykle kończy tutaj, jakkolwiek użytkownik to sformułuje.

Przypisz skargę do jednego etapu

Większość zgłoszeń sprowadza się do jednego z pięciu kształtów, a każdy kształt nazywa etap. Jedna witryna działająca tylko przez tunel to odpowiedź nazwy albo polityka związana z adresem źródłowym. Aktualizacje zawodzące bez tunelu, gdy przeglądanie działa, to problem nazwy lub trasy dla tego klienta.

To, że wszystko staje przy starcie klienta dostawcy, jest stanem zainstalowanym, czyli kwestią trasy i zapory. Jedna usługa nieosiągalna, gdy reszta jest w porządku, to strona odległa. Transfery zatrzymujące się po kilku sekundach to rozmiar pakietu. Dopasuj kształt, zanim uruchomisz polecenia, bo decyduje on, jakie dowody zbierać najpierw.

Zapisz etap, który wywołał pierwszą awarię, wraz z wyjściem polecenia. Zgłoszenie, które mówi, że adres źródłowy był błędny, z załączoną linią trasy, jest warte działania, a takie, które donosi o zepsutym VPN, nie.