Sieć tylko z IPv6 psuje VPN, zanim tunel wystartuje

Laptop łączy się z Wi-Fi konferencji, które rozdaje tylko IPv6, klient VPN kręci się i zawodzi, a ten sam profil działał godzinę wcześniej w hotelu. W danych logowania nic się nie zmieniło. Zmieniło się to, że klient musi teraz dotrzeć do celu IPv4 przez sieć przenoszącą tylko IPv6, a nie każdy klient wie, jak to zrobić.

Przejdź te same pięć kroków, które przechodzą pakiety.

Krok 1: obserwuj wyszukiwanie nazwy

Jeśli profil używa nazwy hosta, pierwsze pytanie brzmi, co zwraca resolver. dig AAAA vpn.example.com w sieci tylko z IPv6 zwraca prawdziwy rekord AAAA, rekord syntezowany z DNS64 albo nic. Odpowiedź syntezowana koduje cel IPv4 w prefiksie tłumaczenia i dopiero wtedy klient bez celu IPv6 może do niego dotrzeć. Profil z zaszytym adresem IPv4 nigdy tu nie dociera, bo nie ma nazwy do syntezowania.

Ta jedna różnica wyjaśnia większość raportów „działa tam, zawodzi tutaj”, a do zobaczenia jej wystarczy jedno polecenie.

Krok 2: zobacz, którą rodzinę wybrał klient

Obserwuj gniazdo, a nie pasek postępu. Klient, który otwiera gniazdo IPv4 do adresu IPv4 na łączu tylko z IPv6, nie ma gdzie go wysłać, a awaria objawia się przekroczeniem czasu, a nie błędem nazwy. ss -tanp podczas łączenia klienta pokazuje adres zdalny i rodzinę, którą próbował. Porównaj to z ip -6 route, aby potwierdzić, że domyślna trasa to prawdziwy następny skok IPv6.

Rodzina adresów w tabeli gniazd jest faktem. Pasek postępu jest podsumowaniem napisanym przez kogoś innego.

Krok 3: oddziel tłumaczenie od tunelu

NAT64 i DNS64 to sposób, w jaki sieć dostępowa dociera do celów IPv4, i nie robią nic dla tunelu po jego podniesieniu. Tunel ustanowiony przez tłumaczoną ścieżkę nadal negocjuje własne adresowanie wewnętrzne, a wewnętrzne pokrycie IPv4 lub IPv6 to odrębna kwestia polityki. Jeśli klient się połączy i potem do niczego nie dotrze, jesteś już za tłumaczeniem i w routingu, co jest innym śledztwem z innymi dowodami.

Awaria tłumaczenia wygląda jak brak połączenia. Awaria wewnętrznego pokrycia wygląda jak połączenie bez dotarcia do niczego.

Krok 4: przetestuj ten sam profil w innej sieci

Zabierz ten sam profil, wersję klienta i dane logowania do sieci z podwójnym stosem i powtórz. Jeśli tam działa, a zawodzi na ścieżce tylko z IPv6, zmienną jest sieć dostępowa, a nie profil. Zapisz w zgłoszeniu wersję klienta i stan sieci, bo ostatecznym rozwiązaniem jest aktualizacja klienta albo inny cel.

Raport, że VPN jest zepsuty, nie jest wykonalny. Raport, że zawodzi tylko przy dostępie tylko z IPv6, jest raportem błędu.

Krok 5: napraw ścieżkę, nie ustawienia bezpieczeństwa

Wszystkie kuszące naprawy pogarszają sytuację. Wyłączenie IPv6 usuwa jedyną ścieżkę, którą oferuje sieć. Wskazanie klientowi publicznego resolvera psuje syntezę DNS64, bo ta synteza musi pochodzić z resolvera za tłumaczem. Wyłączenie weryfikacji certyfikatu daje połączenie z czymś, czego nie można zidentyfikować. Żadna z nich nie jest naprawą, a dwie są regresjami bezpieczeństwa, które przeżyją incydent.

Prawdziwe opcje to klient obsługujący model tłumaczenia sieci albo cel z osiągalnym adresem IPv6. Poproś o jedno z nich.