En ny hotspot-klient som henger på «Henter IP-adresse» er ikke en VPN-feil

En telefon kobler seg til hotspoten, blir stående på «Henter IP-adresse» og gir til slutt opp. Den naturlige konklusjonen er at telefonens VPN forstyrrer DNS, så folk begynner å redigere resolvere og tilføyde regler. Det er feil trinn. Klienten fikk aldri en lokal adresse, og uten en har den verken gateway, resolver eller noe å videresende, så ingen VPN-innstilling på vertstelefonen kan forklare feilen. Tilkobling, tildeling av lokal adresse og videre videresending er tre atskilte trinn, og bare det siste involverer tunnelen.

De tre trinnene, og hvilket du er i

Tilkobling kommer først: klienten kobler seg til hotspotens trådløse nettverk. Feil passord, WPA3-avvik eller et radiokompatibilitetsproblem feiler her, og klienten sier det vanligvis. Adressetildeling kommer som nummer to: for IPv4 ber klienten om en lease og får en adresse pluss lokale gateway-innstillinger, mens IPv6 vanligvis bruker ruterkunngjøringer i stedet for DHCP, slik AOSPs dokumentasjon om tethering beskriver. Videre tilgang kommer som tredje: vertstelefonen videresender tillatt trafikk til den oppstrømsveien den valgte, som kanskje eller kanskje ikke er tunnelen dens.

Ordlyden på klienten forteller deg trinnet. Fast på å hente en adresse er trinn to, før noen pakke forlater mot internett. Tilkoblet, med en adresse, men ingenting lastes er trinn tre, der ruting, navn og tunneldekning alle betyr noe. Å diagnostisere trinn tre mens klienten henger i trinn to er hvordan et femminutters lease-problem blir en ettermiddag med DNS-redigeringer.

Myten: en rutet VPN gjør lokal DHCP til en ekstern forespørsel

En rutet tunnel flytter IP-pakker for destinasjonene den velger. En DHCP-oppdagelse er en kringkasting på hotspotens eget segment, og tethering-tjenesten på telefonen svarer på den lokalt, og derfor kan klienten få en adresse mens tunnelen er oppe. Bare et bevisst brokoblet eller reléført design sender den utvekslingen et annet sted, og det er en annen ordning med en annen feilsignatur.

Så «VPN-serveren svarer ikke på DHCP» er ikke en diagnose, det er en modellfeil. Den lokale mellommannen er på telefonen. Hvis den slutter å svare, er årsakene lokale: tethering-tjenesten, klientgrensen, lease-poolen eller en klient som aldri fullførte tilkoblingen ordentlig. Ingen av disse bor på den fjerne siden av tunnelen.

Hva en fungerende eksisterende klient faktisk beviser

Hvis en bærbar PC som allerede var tilkoblet fortsatt fungerer mens den nye telefonen ikke gjør det, er hotspoten og oppstrømsveien stort sett i live. Den sammenligningen er nyttig, og den er ikke bevis for hvilken komponent som er skyld i feilen, fordi den fungerende klienten kanskje bare holder en lease fra før endringen og fornyer den i stillhet.

To lokale grenser er verdt å sjekke mens du er der. Hotspoten betjener en begrenset lease-pool og en konfigurerbar klientgrense, så en enhet som koblet seg til og sov, kan holde en adresse mens en ny venter. Og en klient som husker en statisk konfigurasjon fra et annet nettverk, vil ikke be om lease i det hele tatt, noe som ser identisk ut utenfra og rettes på klienten, ikke på telefonen.

Hold sammenligningen lokal og reversibel

På en enhet der policyen tillater det, sammenlign én ny klienttilkobling med tunnelen inaktiv og deretter aktiv, mens hotspoten og klienten ellers holdes uendret. Noter versjonene til telefonen og klienten, profilen som ble valgt og det nøyaktige trinnet som feilet. På en administrert telefon, be om den godkjente sammenligningen i stedet for å deaktivere håndhevingen for å få en renere test.

En konsistent tunnelavhengig lease-feil er nyttig bevis om lokal policy eller en implementeringsinteraksjon. Det er ikke en lisens til å tømme hver videresendings- og NAT-regel på enheten. Disse reglene beskytter urelatert trafikk, og en bred videresendingsaksept forklarer ikke hvorfor en lokal DHCP-tjeneste sluttet å svare.

Ikke dekk over en manglende lease med en gjettet statisk adresse heller. En bevisst statisk konfigurasjon trenger det ekte subnettet, gatewayen, tildelingsplanen og en kollisjonssjekk. Å endre klientens DNS gir ingen av disse, og det etterlater den neste enheten med samme feil.

Hva en lease ikke beviser

Å få en adresse beviser opptak i det lokale nettverket, ikke beskyttelse av telefonens tunnel. Når klienten har en lease, vurder nedstrømsveien for seg selv: går klientens trafikk faktisk gjennom telefonen, løses oppslag der du forventer, og samsvarer den eksterne adressen med utgangen du hadde til hensikt? Det er trinn-tre-spørsmål, og de fortjener sin egen test i stedet for å bli foldet inn i tilkoblingen.

Arbeid trinnene i rekkefølge, og feilen slutter å flytte seg. En klient som henger på å hente en adresse er et lokalt tethering-spørsmål; en klient med adresse og ingen sider er et spørsmål om videresending eller navn; en klient med sider og feil utgang er et spørsmål om tunneldekning. Å holde dem fra hverandre er det meste av feilsøkingen.