Een nieuwe hotspot-client die blijft hangen op «IP-adres ophalen» is geen VPN-storing

Een telefoon maakt verbinding met de hotspot, blijft staan op «IP-adres ophalen» en geeft uiteindelijk op. De voor de hand liggende conclusie is dat de VPN van de telefoon DNS verstoort, dus mensen gaan resolvers en toegevoegde regels bewerken. Dat is de verkeerde fase. De client heeft nooit een lokaal adres gekregen, en zonder een heeft hij geen gateway, geen resolver en niets om door te sturen, dus geen enkele VPN-instelling op de hosttelefoon kan de fout verklaren. Associatie, toewijzing van een lokaal adres en doorsturen zijn drie afzonderlijke fasen, en alleen de laatste betreft de tunnel.

De drie fasen, en in welke je zit

Eerst komt de associatie: de client maakt verbinding met het draadloze netwerk van de hotspot. Een verkeerd wachtwoord, een WPA3-verschil of een radiocompatibiliteitsprobleem mislukken hier, en de client zegt dat meestal. Tweede is adrestoewijzing: voor IPv4 vraagt de client om een lease en krijgt een adres plus lokale gateway-instellingen, terwijl IPv6 meestal routeraankondigingen gebruikt in plaats van DHCP, zoals de AOSP-documentatie over tethering beschrijft. Derde is toegang naar buiten: de hosttelefoon stuurt toegestaan verkeer door naar het upstreampad dat hij koos, wat wel of niet zijn tunnel kan zijn.

De tekst op de client vertelt je de fase. Vastlopen bij het ophalen van een adres is fase twee, voordat er een pakket naar het internet gaat. Verbonden, met een adres, maar niets laadt is fase drie, waar routing, namen en tunneldekking allemaal tellen. Fase drie diagnosticeren terwijl de client in fase twee vastzit, is hoe een leaseprobleem van vijf minuten een middag DNS-bewerkingen wordt.

De mythe: een gerouteerde VPN maakt van lokale DHCP een externe aanvraag

Een gerouteerde tunnel verplaatst IP-pakketten voor de bestemmingen die hij kiest. Een DHCP-ontdekking is een uitzending op het eigen segment van de hotspot, en de tetheringdienst op de telefoon antwoordt lokaal, daarom kan de client een adres krijgen terwijl de tunnel aan staat. Alleen een bewust gebrugd of doorgestuurd ontwerp stuurt die uitwisseling ergens anders heen, en dat is een andere opstelling met een andere storingssignatuur.

Dus «de VPN-server antwoordt niet op DHCP» is geen diagnose, het is een modelfout. De lokale tussenpersoon zit op de telefoon. Als hij stopt met antwoorden, zijn de redenen lokaal: de tetheringdienst, de clientlimiet, de leasepool of een client die de associatie nooit goed heeft afgerond. Niets daarvan woont aan de verre kant van de tunnel.

Wat een werkende bestaande client werkelijk bewijst

Als een laptop die al verbonden was nog werkt terwijl de nieuwe telefoon dat niet doet, zijn de hotspot en het upstreampad in grote lijnen levend. Die vergelijking is nuttig en ze is geen bewijs van welke component schuldig is, want de werkende client houdt misschien gewoon een lease van voor de wijziging vast en vernieuwt die stilletjes.

Twee lokale grenzen zijn het controleren waard terwijl je er bent. De hotspot bedient een eindige leasepool en een configureerbare clientlimiet, dus een apparaat dat meedeed en sliep kan een adres vasthouden terwijl een nieuwe wacht. En een client die een statische configuratie van een ander netwerk onthoudt, vraagt helemaal geen lease aan, wat van buitenaf identiek lijkt en bij de client wordt opgelost, niet op de telefoon.

Houd de vergelijking lokaal en omkeerbaar

Vergelijk op een apparaat waar het beleid dat toestaat één deelname van een nieuwe client met de tunnel inactief en daarna actief, terwijl hotspot en client verder ongewijzigd blijven. Noteer de versies van telefoon en client, het gekozen profiel en de exacte fase die mislukte. Vraag op een beheerde telefoon de goedgekeurde vergelijking aan in plaats van de handhaving uit te schakelen voor een schonere test.

Een consistent tunnelafhankelijk leasefalen is nuttig bewijs over lokaal beleid of een implementatie-interactie. Het is geen licentie om elke doorstuur- en NAT-regel op het apparaat te wissen. Die regels beschermen ongerelateerd verkeer, en een brede doorstuurtoestemming verklaart niet waarom een lokale DHCP-dienst stopte met antwoorden.

Dek een ontbrekende lease ook niet af met een geraden statisch adres. Een bewuste statische configuratie vereist het echte subnet, de gateway, het toewijzingsplan en een botsingscontrole. Het wijzigen van de DNS van de client levert niets daarvan en laat het volgende apparaat met dezelfde fout achter.

Wat een lease niet bewijst

Een adres krijgen bewijst toelating tot het lokale netwerk, niet bescherming door de tunnel van de telefoon. Zodra de client een lease heeft, beoordeel je het downstreampad op zichzelf: gaat het verkeer van de client echt via de telefoon, worden opzoekingen opgelost waar je het verwacht, en komt het externe adres overeen met de uitgang die je bedoelde? Dat zijn fase-drie-vragen en ze verdienen hun eigen test in plaats van in de deelname te worden gevouwen.

Werk de fasen in volgorde af en de fout stopt met verschuiven. Een client die vastloopt bij het ophalen van een adres is een lokale tetheringvraag; een client met een adres en zonder pagina's is een doorstuur- of naamvraag; een client met pagina's en de verkeerde uitgang is een vraag over tunneldekking. Ze gescheiden houden is het grootste deel van het debuggen.