Dlaczego VPN może wyglądać na połączony, gdy nic nie działa

Twój klient zgłasza połączony, choć interfejs jest podniesiony, a przeglądarka kończy oczekiwanie, i żadne z tych trzech stwierdzeń nie jest fałszywe. Połączony opisuje warstwę, która nie ma nic wspólnego ze stroną, o którą prosiłeś. Ustalenie, która warstwa zgłasza, wymaga jednego nowego żądania i jednego spojrzenia na licznik, który dowiódłby, że ruch się przesunął. Restart wyrzuca ten dowód i odtwarza warunki, które próbowałeś obserwować.

Trzy różne rzeczy nazywane połączonym

Najniżej połączony może znaczyć, że proces klienta działa i trzyma gniazdo w stronę partnera. Powyżej może znaczyć, że istnieje interfejs z adresem, który trwałe urządzenie lub procedura odzyskiwania mogą utworzyć bez żywej sesji za nim. Na poziomie sterowania może znaczyć, że wynegocjowano asocjację, co nic nie mówi o tym, czy przeszedł pod nią choć jeden pakiet. Każda z nich przeżywa awarie, których inne nie przeżywają, a klient zwykle pokazuje najsilniejszą, do jakiej może się przyznać.

Zielona ikona i martwy tunel są więc zgodne, a nie sprzeczne; informują o różnych obiektach. To cały powód, dla którego ta awaria wciąż jest błędnie diagnozowana jako błąd klienta.

Wyślij jedno nieszkodliwe żądanie do miejsca, którego naprawdę potrzebujesz, zanim dotkniesz demona, i utrzymuj wymagany blok ruchu bezpośredniego na miejscu, gdy pracujesz. Restart zaciera kolejność zdarzeń, a potem odtwarza je wystarczająco blisko, by ukryć przyczynę, dlatego ten sam bilet wraca tydzień później bez niczego nowego. Jedno żądanie, jeden odczyt licznika i wyzwalacz, który wywołał awarię, to minimalny dowód.

Który licznik dowodzi, że pakiety się przesunęły

W IPsec asocjacja IKE i asocjacja CHILD to osobne obiekty, a tylko child niesie liczniki, które odpowiadają na to pytanie. Wypisz child, obserwuj, czy pakiety rosną w obu kierunkach, i porównaj to z tym, co próbuje zrobić aplikacja. Zainstalowana asocjacja na zerze to inne ustalenie niż rosnąca, podczas gdy aplikacja wciąż zawodzi; pierwsze znaczy, że ruch nie jest wybierany, drugie, że się porusza, a usterka jest dalej. Odczytaj liczniki dwa razy, w odstępie kilku sekund, bo jedna próbka nie pokaże trendu.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Zerowe liczniki wskazują na wybór: trasowanie, politykę, przestrzeń nazw, z której wyszedł pakiet, albo interfejs, do którego klient nigdy się nie przywiązał. Rosnące liczniki wskazują z dala od tunelu, więc kontynuuj przekazywaniem na dalekim końcu, rozwiązywaniem nazw, drogą powrotną i usługą docelową, w tej kolejności. Protokół bez osobnego obiektu child ujawnia ten sam dowód własnymi terminami, więc używaj tego, co zgłasza o stanie partnera i liczbie pakietów, zamiast pożyczać słownik IPsec. Kształt odczytu jest ważniejszy niż narzędzie, które go wytworzyło.

Gdzie mieści się usterka po przesunięciu liczników

Brama odpowiadająca na własnym adresie zarządzania dowodzi, że brama działa, a nie że coś za nią obsługuje twoje żądanie, więc testuj daleką stronę, a nie pudełko pośrodku. Rozwiązywanie nazw najlepiej ukrywa awarie, bo resolver nieosiągalny przez tunel kończy oczekiwanie dokładnie jak martwe połączenie. Dwa zapytania rozdzielają te przypadki, a oba są tanie. Najpierw zapytaj resolver, który narzuca tunel, potem zapytaj publiczny resolver o tę samą nazwę.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Nazwa, która rozwiązuje się przez publiczny resolver, ale nie przez resolver tunelu, oznacza, że ścieżka DNS jest zerwana, natomiast nazwa, która rozwiązuje się przez oba i wciąż kończy oczekiwanie w przeglądarce, wskazuje na drogę powrotną lub usługę. Jeśli ping po adresie się udaje, a aplikacja nadal odmawia, sieć dostarczyła żądanie, a usługa je odrzuciła, co jest znacznie późniejszym etapem.

Zapisz wyzwalacz, potem zmień jedną rzecz

Zapisz, co poprzedziło awarię: okres bezczynności, zmianę sieci, odnowienie klucza, wznowiony laptop albo przywrócony system. Te dają różne mechanizmy, a zwykle tylko przywrócony system naprawia się sam, co jest właśnie tym przypadkiem, który niczego cię nie uczy. Restart usuwa kolejność zdarzeń, a potem odtwarza warunki wystarczająco bliskie, by ukryć przyczynę. Zapisz wyzwalacz, dopóki da się go jeszcze odtworzyć.

Potem wprowadź jedną uzasadnioną poprawkę i powtórz pierwotne żądanie razem z wyzwalaczem, który wywołał awarię. Bezczynność to najłatwiejszy do odtworzenia wyzwalacz, więc jest najszybszym potwierdzeniem, że poprawka dotyczyła mechanizmu, a nie objawu.

To, co chcesz zgłosić, to dowód, że ruch, który zamierzałeś wysłać, dotarł do usługi, do której zamierzałeś dotrzeć. Ikona, która zielenieje, strona z pamięci podręcznej, która się ładuje, i licznik, który się porusza, dowodzą łącznie mniej niż jedno ukończone żądanie do zamierzonego celu. Trzymaj razem żądanie, odczyt licznika i wyzwalacz, żeby następna osoba mogła odróżnić poprawkę od przypadku.