Linux EHOSTUNREACH z OpenVPN: który następny skok zawiódł?

EHOSTUNREACH jest decyzją lokalną tak samo często jak awarią zdalną. Jądro może odrzucić pakiet, ponieważ trasa mówi, że cel jest nieosiągalny, ponieważ następny skok Ethernet nigdy nie odpowiedział, albo ponieważ dotarł raport ICMP host-unreachable z dalszej części ścieżki. Każde źródło żyje w innej tabeli lub pamięci podręcznej i każde naprawia się w innym miejscu. Przeczytaj wybraną trasę i stan następnego skoku, zanim dotkniesz szyfrów lub przeinstalujesz tunel.

Wybierz adres i przestrzeń nazw, których klient naprawdę używa

Zacznij od ustalenia celu i przestrzeni nazw sieci, która wywołała błąd. Klient VPN może działać we własnej przestrzeni nazw, a wyszukiwanie z domyślnej przestrzeni nazw korzysta z innej tabeli routingu z innymi regułami polityki.

Wyszukiwanie musi używać tego samego kontekstu źródła, znacznika i tabeli co zawodząca aplikacja, inaczej może odpowiedzieć na pytanie, którego nikt nie zadał. Dla ilustracyjnego peera IPv4 kontrole tylko do odczytu są następujące:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

Wynik z powłoki administracyjnej dowodzi tylko tego, co ta powłoka by zrobiła. Jeśli klient ustawia znacznik zapory lub wiąże się z VRF, powtórz wyszukiwanie z pasującym znacznikiem lub wewnątrz VRF i porównaj wybraną trasę oraz następny skok. Pierwszy adres do potwierdzenia to adres peera w profilu, a nie klaster lub usługa, którą wymienia użytkownik.

Jawna nieosiągalna trasa odrzuca pakiet lokalnie

Trasa typu unreachable to zamierzona lokalna odpowiedź. Mówi jądru, aby odrzuciło pakiet i zwróciło EHOSTUNREACH nadawcy, dlatego błąd pojawia się natychmiast i bez żadnego ruchu opuszczającego maszynę. Ktoś albo jakaś automatyzacja celowo umieścił tę trasę.

Typy tras nie są wymienne. Blackhole odrzuca pakiet bez błędu do nadawcy, prohibit zwraca EACCES, a unreachable zwraca EHOSTUNREACH. Dlatego pomocnik VPN, który podczas ponownego połączenia instaluje trasę tonącą, może wywołać wybuch błędów host-unreachable, które znikają po podniesieniu tunelu, podczas gdy trasa blackhole powodowałaby zamiast tego ciche przekroczenia czasu.

Przeszukaj wszystkie tabele pod kątem typu, zanim obwinisz zdalny koniec. Reguła wybierająca tabelę liczy się tak samo jak trasa w niej, a trasa dodana do tabeli głównej nie pomoże klientowi, którego reguła polityki wysyła jego ruch gdzie indziej.

Martwy sąsiad powoduje ten sam błąd w Ethernet

Gdy wybrana trasa używa bramy on-link, dostarczenie wymaga rozwiązania adresu warstwy łącza. Jądro wysyła żądanie sąsiada ARP lub IPv6, a jeśli nie ma odpowiedzi, pakietu nie można sformatować. Wysyłanie kończy się wtedy błędem EHOSTUNREACH, mimo że sama trasa jest prawidłowa.

Tabela sąsiadów nazywa etap. INCOMPLETE oznacza, że rozwiązywanie trwa, FAILED oznacza, że ostatnia próba nie otrzymała odpowiedzi, a REACHABLE lub STALE oznacza, że jądro ma użyteczny adres. Wpis FAILED dla bramy VPN to lokalny problem dostarczenia, a nie dowód dotyczący drugiej strony tunelu.

Czytaj wpis dla rzeczywistego następnego skoku, a nie dla zdalnego adresu internetowego. Zdalny adres zwykle osiąga się przez router, więc nie będzie miał własnego rekordu ARP; proszenie o niego to błąd kategorii, który wysyła ludzi na poszukiwanie brakującego wpisu, którego nigdy nie powinno być.

Raporty zdalne i asynchroniczne błędy UDP

EHOSTUNREACH może też przyjść z zewnątrz. Router, który nie może przekazać pakietu, może wysłać ICMP host unreachable, a jądro przekazuje ten raport gniazdu, które posiada strumień. W takim przypadku trasa i sąsiad są w porządku, a awaria należy do skoku poza siecią lokalną.

UDP utrudnia przypisanie. Błąd zwrócony przez późniejsze wywołanie send lub receive może dotyczyć wcześniejszego datagramu, więc adres i czas zawodzącego wywołania mogą nie odpowiadać pakietowi, który wywołał raport. Połączone gniazdo UDP otrzymuje błąd raz, a niepołączone gniazdo może go nigdy nie zobaczyć.

Dlatego czas należy do dowodów. Zanotuj, kiedy pojawił się błąd, jakiego adresu peera użyło gniazdo i czy tunel właśnie się ponownie połączył. Wybuch zaraz po zmianie trasy wskazuje na tabelę lokalną; pojedynczy błąd po kilku minutach stabilnego strumienia wskazuje na raport ścieżki.

Oddziel warstwy, zanim zmienisz kryptografię

Trzy pytania klasyfikują błąd. Czy jądro wybrało trasę, która odrzuca cel? Czy wybrało prawidłową trasę, ale nie rozwiązało następnego skoku? A może raport przyszedł spoza sieci lokalnej? Tylko trzeci przypadek może dotyczyć zdalnego końca tunelu, a i wtedy nie dotyczy szyfrowania.

Problemy z uwierzytelnianiem i negocjacjami ujawniają się jako własne błędy po tym, jak transport dotrze do peera. Zmiana szyfru lub przeinstalowanie klienta nie naprawi lokalnej trasy unreachable i niszczy dowody trasy oraz sąsiada potrzebne do ustalenia rzeczywistej przyczyny.

Przed pierwszą zmianą zapisz cel, przestrzeń nazw, wybraną tabelę, następny skok, stan sąsiada i czas błędu. Po poprawce uruchom to samo wyszukiwanie ponownie; trasa, która teraz wskazuje tunel, i wpis sąsiada, który teraz się rozwiązuje, są silniejszym dowodem niż udany ping do niepowiązanego adresu.