VPN się łączy, ale urządzenia LAN są nieosiągalne: co sprawdzić

Ruch wchodzi do tunelu, brama odpowiada na własnym adresie, a nic za nią nie odpowiada. Ten wzorzec jest częsty i nie jest sprzecznością: odpowiedź z bramy dowodzi, że tunel się zakończył, i nie dowodzi niczego o tym, co dzieje się z pakietem zaadresowanym poza nią. Oba testy wykorzystują różne ścieżki kodu na tej samej maszynie.

Od teraz testuj coś po drugiej stronie bramy. Własny adres bramy będzie nadal odpowiadał, niezależnie od tego, jak zepsute jest przekazywanie.

Brama odpowiada z własnego stosu

Pakiet zaadresowany do bramy jest dostarczany do jej lokalnej ścieżki wejściowej, gdzie jądro decyduje, czy przyjmie go gniazdo nasłuchujące. Pakiet zaadresowany do hosta za bramą jest natomiast dostarczany do ścieżki przekazywania, gdzie obowiązuje inny zestaw kontroli. Przekazywanie można całkowicie wyłączyć albo jądro może je włączyć, a następnie reguła filtra, która nigdy nie wspomina o tunelu, może je odrzucić. Nic z tego nie wpływa na własną odpowiedź bramy, dlatego objaw tak niezawodnie myli.

Strony administracyjne osiągane przez tunel również należą do pierwszej kategorii. Są dowodem na temat tunelu, a nie sieci za nim.

Śledź przepływ do pierwszej granicy, która go odrzuca

Zacznij od klienta i potwierdź trasę oraz adres źródłowy, którego użyje przepływ. Następnie obserwuj bramę pod kątem przybycia dokładnie tego przepływu, a potem tego samego przepływu wychodzącego w stronę LAN. Jeśli nigdy nie przybywa, problem leży po stronie klienta albo w dozwolonych prefiksach tunelu. Jeśli przybywa i nigdy nie wychodzi, problem leży w przekazywaniu albo w filtrze ścieżki naprzód, a przechwycenie już powiedziało, w którym z nich.

Uruchamianie tego samego testu z bramy ukrywa interesującą połowę, ponieważ pakiet pochodzący z bramy ma inne źródło i inne wymagania powrotu. Na każdym kroku używaj przepływu klienta z jego własnym adresem źródłowym. Przechwycenie wykonane na niewłaściwym interfejsie daje pewne siebie bzdury.

Trasy powrotne i zapory hosta zawodzą osobno

Gdy pakiet dotrze do hosta, muszą spełnić się jeszcze trzy rzeczy. Usługa musi nasłuchiwać na adresie, na który pakiet został wysłany, zapora hosta musi go zaakceptować, oraz odpowiedź musi mieć trasę powrotną w stronę puli klientów. To ostatnie często zawodzi, bo domyślna trasa hosta wskazuje na router, który nigdy nie słyszał o zakresie tunelu. Wynikiem jest połączenie, które nawiązuje się z punktu widzenia hosta i po cichu umiera w drugą stronę.

Przetestuj ścieżkę powrotną celowo, wysyłając od klienta i obserwując powrót. Przechwycenie jednokierunkowe rozstrzyga w sekundach to, czego nie rozstrzygnie godzina spekulacji.

Potwierdź każdy przeskok adresem źródłowym klienta

Wykonaj kontrole po kolei i zachowaj każde wyjście, ponieważ wartość tkwi w porównaniu, a nie w jednej linii. Polecenia poniżej ustalają adres źródłowy, pokazują wybraną trasę i przechwytują obie strony przekazywania. Zastąp swojego hosta LAN i interfejs tunelu własnymi.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

Zapytanie o trasę pokazuje, czy klient w ogóle wysłałby ten pakiet do tunelu, a ping pokazuje, czy coś wróciło z hosta. Porównanie obu przechwyceń oddziela przybycie od wyjścia, ponieważ ramka na interfejsie tunelu bez odpowiednika na interfejsie LAN jest decyzją o przekazywaniu, a nie awarią usługi. Gdy oba przechwycenia pokazują żądanie, a tylko jedno pokazuje odpowiedź, pozostałym podejrzanym jest trasa powrotna.

Zapisz, który adres odpowiedział i które przekazane miejsce docelowe zawiodło. To zdanie czyni raport użytecznym zamiast twierdzenia, że serwer jest nieosiągalny.