Ein ny hotspot-klient som heng på «Hentar IP-adresse» er ikkje ein VPN-feil
Tilkopling, ein lokal DHCP-leige og vidare videresending er tre trinn. Eining som heng på å hente ei adresse nådde aldri VPN-en, så slutt å redigere DNS.
Ein telefon koplar seg til hotspoten, blir ståande på «Hentar IP-adresse» og gir til slutt opp. Den naturlege konklusjonen er at VPN-en på telefonen forstyrrar DNS, så folk byrjar å redigere resolvarar og tilføygde reglar. Det er feil trinn. Klienten fekk aldri ei lokal adresse, og utan ei har han korkje gateway, resolver eller noko å videresende, så ingen VPN-innstilling på vertstelefonen kan forklare feilen. Tilkopling, tildeling av lokal adresse og vidare videresending er tre atskilde trinn, og berre det siste involverer tunnelen.
Dei tre trinna, og kva trinn du er i
Tilkopling kjem først: klienten koplar seg til det trådlause nettet til hotspoten. Feil passord, WPA3-avvik eller eit radiokompatibilitetsproblem feilar her, og klienten seier det vanlegvis. Adressetildeling kjem som nummer to: for IPv4 ber klienten om ei leige og får ei adresse pluss lokale gateway-innstillingar, medan IPv6 vanlegvis brukar ruterkunngjeringar i staden for DHCP, slik AOSP-dokumentasjonen om tethering skildrar. Vidare tilgang kjem som tredje: vertstelefonen videresender tillaten trafikk til den oppstraumsvegen han valde, som kanskje eller kanskje ikkje er tunnelen hans.
Ordlyden på klienten fortel deg trinnet. Fast på å hente ei adresse er trinn to, før nokon pakke forlèt mot internett. Tilkopla, med ei adresse, men ingenting lastar er trinn tre, der ruting, namn og tunneldekning alle tel. Å diagnostisere trinn tre medan klienten heng i trinn to er korleis eit femminutts leigeproblem blir ein ettermiddag med DNS-redigeringar.
Myten: ein ruta VPN gjer lokal DHCP til ei ekstern førespurnad
Ein ruta tunnel flyttar IP-pakkar for destinasjonane han vel. Ei DHCP-oppdaging er ei kringkasting på hotspotens eiget segment, og tethering-tenesta på telefonen svarar på henne lokalt, og difor kan klienten få ei adresse medan tunnelen er oppe. Berre eit medvite brua eller reléført design sender den utvekslinga ein annan stad, og det er ei anna ordning med ein annan feilsignatur.
Så «VPN-tenaren svarar ikkje på DHCP» er ikkje ein diagnose, det er ein modellfeil. Den lokale mellommannen er på telefonen. Viss han sluttar å svare, er årsakene lokale: tethering-tenesta, klientgrensa, leigepoolen eller ein klient som aldri fullførte tilkoplinga ordentleg. Ingen av desse bur på den fjerne sida av tunnelen.
Kva ein fungerande eksisterande klient faktisk provar
Viss ein berbar PC som allereie var tilkopla framleis fungerer medan den nye telefonen ikkje gjer det, er hotspoten og oppstraumsvegen stort sett levande. Den samanlikninga er nyttig, og ho er ikkje prov på kva komponent som er skyld i feilen, fordi den fungerande klienten kanskje berre held på ei leige frå før endringa og fornyar henne i stillheit.
To lokale grenser er verd å sjekke medan du er der. Hotspoten tener ein avgrensa leigepool og ei konfigurerbar klientgrense, så ei eining som kopla seg til og sov kan halde på ei adresse medan ei ny ventar. Og ein klient som hugsar ein statisk konfigurasjon frå eit anna nettverk, vil ikkje be om leige i det heile, noko som ser identisk ut utanfrå og blir retta på klienten, ikkje på telefonen.
Hald samanlikninga lokal og reversibel
På ei eining der policyen tillèt det, samanlikn éin ny klienttilkopling med tunnelen inaktiv og deretter aktiv, medan hotspoten og klienten elles blir haldne uendra. Noter versjonane til telefonen og klienten, profilen som vart vald og det nøyaktige trinnet som feila. På ein administrert telefon, be om den godkjende samanlikninga i staden for å slå av handhevinga for å få ein reinare test.
Ein konsistent tunnelavhengig leigefeil er nyttig prov om lokal policy eller ein implementeringsinteraksjon. Det er ikkje ein lisens til å tømme kvar videresendings- og NAT-regel på eininga. Desse reglane vernar urelatert trafikk, og ein brei videresendingsaksept forklarar ikkje kvifor ei lokal DHCP-teneste slutta å svare.
Ikkje dekk over ei manglande leige med ei gjeta statisk adresse heller. Ein medviten statisk konfigurasjon treng det ekte subnettet, gatewayen, tildelingsplanen og ein kollisjonssjekk. Å endre DNS-en til klienten gir ingen av desse, og det lèt den neste eininga sitje att med same feilen.
Kva ei leige ikkje provar
Å få ei adresse provar opptak i det lokale nettverket, ikkje vern av tunnelen til telefonen. Når klienten har ei leige, vurder nedstraumsvegen for seg sjølv: går trafikken til klienten faktisk gjennom telefonen, blir oppslag løyste der du ventar, og samsvarar den eksterne adressa med utgangen du hadde til hensikt? Det er trinn-tre-spørsmål, og dei fortener sin eigen test i staden for å bli brettekant inn i tilkoplinga.
Arbeid trinna i rekkefølgje, og feilen sluttar å flytte seg. Ein klient som heng på å hente ei adresse er eit lokalt tethering-spørsmål; ein klient med adresse og utan sider er eit spørsmål om videresending eller namn; ein klient med sider og feil utgang er eit spørsmål om tunneldekning. Å halde dei frå kvarandre er det meste av feilsøkinga.