Ikona klienta mówi połączono, interfejs istnieje, a aplikacja nadal nic nie osiąga. Taka kombinacja jest częsta, ponieważ interfejs wirtualny może pozostać, gdy brakuje jego zdalnego peera, adresów lub tras. ip link to właściwe pierwsze narzędzie, a zarazem najłatwiejsze do nadinterpretacji. Flagi i liczniki opisują jedną warstwę, a warstwy nad nimi zawodzą niezależnie. To także narzędzie, które ludzie cytują, gdy chcą dowieść, że tunel działa, czyli dokładnie to twierdzenie, którego ono samo nie może poprzeć.

Przeczytaj interfejs, zanim przeczytasz ikonę

Zacznij od ip -details link show dev tun0 zgodnie z dokumentacją w podręczniku ip-link, podstawiając interfejs, który naprawdę należy do twojego klienta, zamiast nazwy konwencjonalnej. Flagi, typ, MTU i tożsamość interfejsu to użyteczne obserwacje. Opis stanu interfejsu wirtualnego nie musi zachowywać się jak wskazanie nośnej kabla fizycznego, więc traktuj UP jako stwierdzenie o interfejsie, a nie o tunelu.

Ta różnica wyjaśnia najbardziej mylący przypadek: interfejs, który trwa, gdy zdalna strona łączy się ponownie lub jest nieosiągalna.

Ustawienia trwałości mogą utrzymywać łącze właśnie po to, by ponowne połączenie go nie odbudowywało, co oznacza, że obecność nie jest zdrowiem.

Dodaj liczniki i żądanie, które powinno ich użyć

Użyj obsługiwanego widoku statystyk, ip -s link show dev tun0, i zanotuj liczby pakietów oraz bajtów w obu kierunkach. Następnie wygeneruj nieszkodliwe żądanie, które powinno przejść przez interfejs, i porównaj właściwy kierunek. Żądanie, które poszło bezpośrednią trasą innej aplikacji, nie poruszy tych liczników, i o to chodzi w tym ćwiczeniu.

Jeśli licznik wysyłania się zmienia, a odbioru nie, pakiet wyszedł i nic nie wróciło. To inny problem niż interfejs, który nigdy niczego nie przeniósł. Jeśli oba liczniki się zmieniają, a aplikacja nadal zawodzi, usterka leży powyżej interfejsu, co jest postępem, a nie ślepą uliczką.

Odczytaj dwukrotnie, raz przed i raz po, zamiast ufać jednemu zrzutowi.

Adresy i trasy to osobne kroki

Łącze może istnieć bez prefiksu, konfiguracji resolvera lub trasy potrzebnej aplikacji. Sprawdź adres za pomocą ip address show dev tun0, a następnie sprawdź, którą trasę wybrałby cel, używając ip route get dla rzeczywistego celu. Te trzy obserwacje odpowiadają na trzy różne pytania i tylko ostatnia dotyczy przekazywania.

W przypadku IPsec znaczenie mogą mieć też polityka bezpieczeństwa i stan asociacji, a nie każdy projekt IPsec pojawia się jako prosty interfejs tun. Szukanie urządzenia tun, które nigdy nie miało powstać, to szybki sposób na wyciągnięcie błędnego wniosku.

Zapisz dokładną nazwę, przestrzeń nazw i czas przy każdym zachowanym wyniku, ponieważ ta sama wyglądająca nazwa w innym kontenerze lub przywróconej sesji oznacza zupełnie inny kontekst.

Nie usuwaj tego, czego nie zidentyfikowałeś

Nieznany interfejs nie jest automatycznie przestarzały. Ustal właściciela, zanim cokolwiek usuniesz, i użyj udokumentowanego demontażu klienta lub zarządzanej konfiguracji, gdy usunięcie jest naprawdę zamierzone. Kasowanie działającego tunelu, żeby zobaczyć, co się stanie, to test odpowiadający na pytanie, którego nikt nie zadał.

Jeśli interfejs należy do środowiska kontenerów lub przestrzeni nazw sieci, której nie utworzyłeś, właściciel jest o jedno polecenie dalej i warto go najpierw znaleźć.

Ta ostrożność dotyczy także ip link set down, które wygląda na odwracalne i często takie nie jest.

Co powinna dać ci ta inspekcja

Dobra inspekcja kończy się czterema faktami: nazwą i przestrzenią nazw interfejsu, jego flagami i MTU, deltą liczników z rzeczywistego żądania oraz trasą i adresem, których aplikacja naprawdę potrzebuje. Gdy są zapisane, następny krok jest oczywisty i należy do konkretnej warstwy. Bez nich każda kolejna zmiana jest zgadywaniem z planem wycofania.

Porównaj te cztery fakty z tymi samymi czterema z działającej sesji. Jeśli nazwa i przestrzeń nazw się zgadzają, ale delta liczników wynosi zero, żądanie nigdy nie dotarło do tunelu. Jeśli delta jest zdrowa, a trasa wskazuje gdzie indziej, tunel jest w porządku, a routing nie. Właśnie to porównanie zamienia stos wyników w decyzję.

Zachowaj wynik przy zgłoszeniu, ponieważ późniejsze porównanie jest przydatne tylko wtedy, gdy widzisz, co się zmieniło.

Potem zamknij pętlę, testując aplikację ponownie, bo interfejs nigdy nie był tym, na czym zależało użytkownikowi.

Powiązane artykuły