Nowy klient hotspota utknięty na pobieraniu IP to nie awaria VPN

Telefon dołącza do hotspota, stoi na „Pobieranie adresu IP” i w końcu się poddaje. Naturalny wniosek jest taki, że VPN telefonu zakłóca DNS, więc ludzie zaczynają edytować resolvery i dodane reguły. To niewłaściwy etap. Klient nigdy nie otrzymał adresu lokalnego, a bez niego nie ma bramy, resolvera ani niczego do przekazania, więc żadne ustawienie VPN na telefonie gospodarza nie wyjaśnia awarii. Skojarzenie, przydział adresu lokalnego i dalsze przekazywanie to trzy odrębne etapy, a tylko ostatni dotyczy tunelu.

Trzy etapy i w którym jesteś

Najpierw jest skojarzenie: klient dołącza do sieci bezprzewodowej hotspota. Błędne hasło, niezgodność WPA3 lub problem ze zgodnością radiową kończą się tutaj, a klient zwykle to komunikuje. Drugi jest przydział adresu: w IPv4 klient prosi o leasing i otrzymuje adres oraz lokalne ustawienia bramy, natomiast IPv6 zwykle używa ogłoszeń routera zamiast DHCP, jak opisuje dokumentacja AOSP dotycząca tetheringu. Trzeci jest dostęp na zewnątrz: telefon gospodarza przekazuje dozwolony ruch do wybranej przez siebie ścieżki nadrzędnej, która może, ale nie musi być jego tunelem.

Komunikat na kliencie mówi, na którym etapie jesteś. Utknięcie na pobieraniu adresu to drugi etap, zanim jakikolwiek pakiet wyjdzie do internetu. Połączony, z adresem, ale nic się nie ładuje to trzeci etap, w którym liczą się routing, nazwy i zasięg tunelu. Diagnozowanie trzeciego etapu, gdy klient utknął na drugim, to sposób, w jaki pięciominutowy problem z leasingiem staje się popołudniem edycji DNS.

Mit: routowany VPN zamienia lokalny DHCP w żądanie zdalne

Routowany tunel przenosi pakiety IP dla wybranych przez siebie celów. Odkrywanie DHCP to rozgłoszenie w segmencie samego hotspota, a usługa tetheringu na telefonie odpowiada lokalnie, dlatego klient może dostać adres, gdy tunel jest włączony. Tylko celowo pomostowy lub przekazywany projekt wysyła tę wymianę gdzie indziej, a to inny układ z inną sygnaturą awarii.

Zatem „serwer VPN nie odpowiada na DHCP” to nie diagnoza, lecz błąd modelu. Lokalny pośrednik jest na telefonie. Jeśli przestaje odpowiadać, przyczyny są lokalne: usługa tetheringu, limit klientów, pula leasingu lub klient, który nigdy nie ukończył skojarzenia poprawnie. Żadna z nich nie mieszka po odległej stronie tunelu.

Co naprawdę dowodzi działający dotychczasowy klient

Jeśli laptop, który był już podłączony, nadal działa, a nowy telefon nie, hotspot i ścieżka nadrzędna są ogólnie żywe. To porównanie jest użyteczne i nie jest dowodem, który komponent zawinił, bo działający klient może po prostu trzymać leasing sprzed zmiany i po cichu go odnawiać.

Warto sprawdzić dwa lokalne ograniczenia, póki tam jesteś. Hotspot obsługuje skończoną pulę leasingu i konfigurowalny limit klientów, więc urządzenie, które dołączyło i usnęło, może trzymać adres, podczas gdy nowe czeka. A klient, który pamięta konfigurację statyczną z innej sieci, w ogóle nie poprosi o leasing, co z zewnątrz wygląda identycznie i naprawia się po stronie klienta, nie telefonu.

Utrzymuj porównanie lokalne i odwracalne

Na urządzeniu, na którym polityka na to pozwala, porównaj jedno dołączenie nowego klienta z tunelem nieaktywnym, a potem aktywnym, utrzymując hotspot i klienta bez zmian. Zanotuj wersje telefonu i klienta, wybrany profil i dokładny etap, który zawiódł. Na zarządzanym telefonie poproś o zatwierdzone porównanie zamiast wyłączać egzekwowanie, by uzyskać czystszy test.

Spójna awaria leasingu zależna od tunelu jest użytecznym dowodem dotyczącym polityki lokalnej lub interakcji implementacji. To nie jest licencja na wyczyszczenie każdej reguły przekazywania i NAT na urządzeniu. Te reguły chronią niezwiązany ruch, a szeroka akceptacja przekazywania nie wyjaśnia, dlaczego lokalna usługa DHCP przestała odpowiadać.

Nie zakrywaj też brakującego leasingu zgadywanym adresem statycznym. Celowa konfiguracja statyczna wymaga prawdziwej podsieci, bramy, planu alokacji i sprawdzenia kolizji. Zmiana DNS klienta nie daje żadnego z nich i zostawia następne urządzenie z tą samą awarią.

Czego leasing nie dowodzi

Otrzymanie adresu dowodzi przyjęcia do sieci lokalnej, a nie ochrony przez tunel telefonu. Gdy klient ma leasing, oceń ścieżkę w dół osobno: czy ruch klienta rzeczywiście przechodzi przez telefon, czy zapytania rozwiązują się tam, gdzie oczekujesz, i czy adres zewnętrzny zgadza się z zamierzonym wyjściem? To pytania trzeciego etapu i zasługują na własny test, zamiast być składane w dołączenie.

Przechodź etapy po kolei, a awaria przestaje się przenosić. Klient utknięty na pobieraniu adresu to lokalne pytanie o tethering; klient z adresem i bez stron to pytanie o przekazywanie lub nazwy; klient ze stronami i złym wyjściem to pytanie o zasięg tunelu. Trzymanie ich osobno to większość debugowania.