En ny hotspot-klient som fastnar på «Hämtar IP-adress» är inte ett VPN-fel

En telefon ansluter till hotspoten, står på «Hämtar IP-adress» och ger till slut upp. Den naturliga slutsatsen är att telefonens VPN stör DNS, så folk börjar redigera resolvers och tillagda regler. Det är fel steg. Klienten fick aldrig en lokal adress, och utan en har den varken gateway, resolver eller något att vidarebefordra, så ingen VPN-inställning på värdtelefonen kan förklara felet. Anslutning, tilldelning av lokal adress och vidarebefordran är tre separata steg, och bara det sista involverar tunneln.

De tre stegen, och vilket du är i

Först kommer anslutningen: klienten ansluter till hotspotens trådlösa nätverk. Fel lösenord, WPA3-avvikelse eller ett radiokompatibilitetsproblem misslyckas här, och klienten säger oftast det. Sedan kommer adresstilldelningen: för IPv4 begär klienten ett lån och får en adress plus lokala gateway-inställningar, medan IPv6 vanligtvis använder routerannonser i stället för DHCP, vilket AOSP:s dokumentation om tethering beskriver. Tredje kommer vidare åtkomst: värdtelefonen vidarebefordrar tillåten trafik till den uppströmsväg den valde, som kanske eller kanske inte är dess tunnel.

Formuleringen på klienten berättar steget. Att fastna på att hämta en adress är steg två, innan något paket lämnar för internet. Ansluten, med en adress, men inget laddas är steg tre, där routning, namn och tunneltäckning alla spelar roll. Att diagnostisera steg tre medan klienten fastnat i steg två är hur ett femminuters låneproblem blir en eftermiddag av DNS-redigeringar.

Myten: en routad VPN gör lokal DHCP till en fjärrförfrågan

En routad tunnel flyttar IP-paket för de destinationer den väljer. En DHCP-upptäckt är en utsändning på hotspotens eget segment, och tethering-tjänsten på telefonen svarar lokalt, och därför kan klienten få en adress medan tunneln är uppe. Bara en medvetet bryggad eller vidarebefordrad design skickar det utbytet någon annanstans, och det är en annan uppsättning med en annan felsignatur.

Så «VPN-servern svarar inte på DHCP» är inte en diagnos, det är ett modellfel. Den lokala förmedlaren finns på telefonen. Om den slutar svara är orsakerna lokala: tethering-tjänsten, klientgränsen, lånepoolen eller en klient som aldrig slutförde anslutningen ordentligt. Inget av detta bor på tunnelns bortre sida.

Vad en fungerande befintlig klient faktiskt bevisar

Om en bärbar dator som redan var ansluten fortfarande fungerar medan den nya telefonen inte gör det, är hotspoten och uppströmsvägen i stort sett levande. Den jämförelsen är användbar och den är inte bevis för vilken komponent som är skyldig, eftersom den fungerande klienten kanske bara håller ett lån från före ändringen och förnyar det tyst.

Två lokala gränser är värda att kontrollera medan du är där. Hotspoten betjänar en ändlig lånepool och en konfigurerbar klientgräns, så en enhet som anslöt och somnade kan hålla en adress medan en ny väntar. Och en klient som minns en statisk konfiguration från ett annat nätverk kommer inte att begära något lån alls, vilket ser identiskt ut utifrån och åtgärdas på klienten, inte på telefonen.

Håll jämförelsen lokal och reversibel

På en enhet där policyn tillåter det, jämför en ny klientanslutning med tunneln inaktiv och sedan aktiv, medan hotspoten och klienten i övrigt hålls oförändrade. Anteckna versionerna för telefonen och klienten, den valda profilen och det exakta steg som misslyckades. På en hanterad telefon, begär den godkända jämförelsen i stället för att stänga av efterlevnaden för ett renare test.

Ett konsekvent tunnelberoende lånefel är användbart bevis om lokal policy eller en implementeringsinteraktion. Det är ingen licens att tömma varje vidarebefordrings- och NAT-regel på enheten. De reglerna skyddar orelaterad trafik, och ett brett vidarebefordringsgodkännande förklarar inte varför en lokal DHCP-tjänst slutade svara.

Täck inte över ett saknat lån med en gissad statisk adress heller. En medveten statisk konfiguration kräver det riktiga subnätet, gatewayen, tilldelningsplanen och en kollisionskontroll. Att ändra klientens DNS ger inget av detta, och det lämnar nästa enhet med samma fel.

Vad ett lån inte bevisar

Att få en adress bevisar inträde i det lokala nätverket, inte skydd av telefonens tunnel. När klienten har ett lån, utvärdera nedströmsvägen för sig: går klientens trafik verkligen via telefonen, löses uppslag där du förväntar dig, och stämmer den yttre adressen med den utgång du avsåg? Det är steg-tre-frågor och de förtjänar ett eget test i stället för att vikas in i anslutningen.

Arbeta igenom stegen i ordning och felet slutar flytta sig. En klient som fastnar på att hämta en adress är en lokal tethering-fråga; en klient med adress och utan sidor är en vidarebefordrings- eller namfråga; en klient med sidor och fel utgång är en tunneltäckningsfråga. Att hålla dem åtskilda är det mesta av felsökningen.