Ny hotspot-klient, der hænger på at hente IP, er ikke en VPN-fejl

En telefon forbinder til hotspot'en, står på »Henter IP-adresse« og giver til sidst op. Den naturlige konklusion er, at telefonens VPN forstyrrer DNS, så folk begynder at redigere resolvere og tilføjede regler. Det er den forkerte fase. Klienten fik aldrig en lokal adresse, og uden en har den hverken gateway, resolver eller noget at videresende, så ingen VPN-indstilling på værts telefonen kan forklare fejlen. Tilslutning, tildeling af lokal adresse og videresendelse er tre adskilte faser, og kun den sidste involverer tunnelen.

De tre faser, og hvilken du er i

Tilslutning kommer først: klienten forbinder til hotspot'ens trådløse netværk. Forkert adgangskode, WPA3-uoverensstemmelse eller et radiokompatibilitetsproblem fejler her, og klienten siger det normalt. Adressetildeling kommer som nummer to: for IPv4 anmoder klienten om en lease og får en adresse plus lokale gateway-indstillinger, mens IPv6 normalt bruger routerannoncering i stedet for DHCP, som AOSP's tethering-dokumentation beskriver. Videre adgang kommer som tredje: værts telefonen videresender tilladt trafik til den opstrømsrute, den valgte, som måske eller måske ikke er dens tunnel.

Ordlyden på klienten fortæller dig fasen. Fast på at hente en adresse er fase to, før nogen pakke forlader mod internettet. Forbundet, med en adresse, men intet indlæses er fase tre, hvor routing, navne og tunnel-dækning alle betyder noget. At diagnosticere fase tre, mens klienten hænger i fase to, er hvordan et fem minutters lease-problem bliver en eftermiddag med DNS-redigeringer.

Myten: en routet VPN gør lokal DHCP til en fjernanmodning

En routet tunnel flytter IP-pakker for de destinationer, den vælger. En DHCP-opdagelse er en broadcast på hotspot'ens eget segment, og tethering-tjenesten på telefonen svarer på den lokalt, og derfor kan klienten få en adresse, mens tunnelen er oppe. Kun et bevidst bro- eller relay-design sender den udveksling et andet sted hen, og det er en anden opsætning med en anden fejlsignatur.

Så »VPN-serveren svarer ikke på DHCP« er ikke en diagnose, det er en modelfejl. Den lokale mægler er på telefonen. Hvis den holder op med at svare, er årsagerne lokale: tethering-tjenesten, klientgrænsen, lease-puljen eller en klient, der aldrig fuldførte tilslutningen ordentligt. Intet af det bor på den fjerne side af tunnelen.

Hvad en fungerende eksisterende klient faktisk beviser

Hvis en bærbar computer, der allerede var forbundet, stadig virker, mens den nye telefon ikke gør, er hotspot'en og opstrømsruten stort set i live. Den sammenligning er nyttig, og den er ikke bevis for, hvilken komponent der er skyld i fejlen, fordi den fungerende klient måske blot holder en lease fra før ændringen og fornyer den i stilhed.

To lokale grænser er værd at kontrollere, mens du er der. Hotspot'en leverer en begrænset lease-pulje og en konfigurerbar klientgrænse, så en enhed, der tilsluttede og sov, kan holde en adresse, mens en ny venter. Og en klient, der husker en statisk konfiguration fra et andet netværk, vil slet ikke anmode om en lease, hvilket ser identisk ud udefra og rettes på klienten, ikke på telefonen.

Hold sammenligningen lokal og reversibel

På en enhed, hvor politikken tillader det, sammenlign én ny klienttilslutning med tunnelen inaktiv og derefter aktiv, mens hotspot og klient ellers holdes uændrede. Notér telefonens og klientens versioner, den valgte profil og den præcise fase, der fejlede. På en administreret telefon, anmod om den godkendte sammenligning i stedet for at deaktivere håndhævelsen for at få en renere test.

En konsekvent tunnelafhængig lease-fejl er nyttigt bevis om lokal politik eller en implementeringsinteraktion. Det er ikke en licens til at skylle hver videresendelses- og NAT-regel på enheden. De regler beskytter urelateret trafik, og en bred videresendelsesaccept forklarer ikke, hvorfor en lokal DHCP-tjeneste holdt op med at svare.

Dæk heller ikke en manglende lease til med en gættet statisk adresse. En bevidst statisk konfiguration kræver det rigtige subnet, gatewayen, tildelingsplanen og en kollisionskontrol. Ændring af klientens DNS giver ingen af dem, og den efterlader den næste enhed med samme fejl.

Hvad en lease ikke beviser

At få en adresse beviser adgang til det lokale netværk, ikke beskyttelse af telefonens tunnel. Når klienten har en lease, evaluer den nedstrøms rute separat: går klientens trafik faktisk gennem telefonen, opløses opslag der, hvor du forventer, og matcher den eksterne adresse den udgang, du havde til hensigt? Det er fase-tre-spørgsmål, og de fortjener deres egen test i stedet for at blive foldet ind i tilslutningen.

Arbejd faserne i rækkefølge, og fejlen holder op med at flytte sig. En klient fast på at hente en adresse er et lokalt tethering-spørgsmål; en klient med en adresse og ingen sider er et videresendelses- eller navnespørgsmål; en klient med sider og den forkerte udgang er et tunnel-dækningsspørgsmål. At holde dem adskilt er det meste af fejlfindingen.