Nuwe hotspot-kliënt wat op „IP-adres verkry“ vassit, is nie ’n VPN-fout nie

’n Foon sluit by die hotspot aan, bly op „IP-adres verkry“ staan en gee uiteindelik op. Die natuurlike gevolgtrekking is dat die foon se VPN met DNS inmeng, en mense begin dan resolveerders en bygevoegde reëls wysig. Dit is die verkeerde fase. Die kliënt het nooit ’n plaaslike adres ontvang nie, en sonder een het hy geen poort nie, geen resolveerder nie en niks om deur te stuur nie, so geen VPN-instelling op die gasheerfoon kan die mislukking verklaar nie. Assosiasie, plaaslike adrestoewysing en deurstuur is drie afsonderlike fases, en net die laaste een behels die tonnel.

Die drie fases, en in watter een jy is

Assosiasie kom eerste: die kliënt sluit by die hotspot se draadlose netwerk aan. ’n Verkeerde wagwoord, ’n WPA3-wanpassing of ’n radio-versoenbaarheidsprobleem misluk hier, en die kliënt sê dit gewoonlik. Adrestoewysing kom tweede: vir IPv4 vra die kliënt ’n huurkontrak en ontvang ’n adres plus plaaslike poortinstellings, terwyl IPv6 gewoonlik routeraankondigings eerder as DHCP gebruik, soos die AOSP-dokumentasie oor tethering beskryf. Deurtoegang kom derde: die gasheerfoon stuur toegelate verkeer na watter opstroompad hy ook al gekies het, wat sy tonnel kan wees of nie.

Die bewoording op die kliënt vertel jou die fase. Vasgehaak by die verkryging van ’n adres is fase twee, voordat enige pakkie na die internet vertrek. Gekoppel, met ’n adres, maar niks laai nie, is fase drie, waar roetering, name en tonneldekking almal saak maak. Om fase drie te diagnoseer terwyl die kliënt in fase twee vassit, is hoe ’n huurkontrakprobleem van vyf minute ’n middag se DNS-wysigings word.

Die mite: ’n VPN met roetering verander plaaslike DHCP in ’n afgeleë versoek

’n Tonnel met roetering beweeg IP-pakkies vir die bestemmings wat hy kies. ’n DHCP-ontdekking is ’n uitsending op die hotspot se eie segment, en die tethering-diens op die foon antwoord dit plaaslik, daarom kan die kliënt ’n adres kry terwyl die tonnel op is. Net ’n doelbewus oorbrugde of deurgestuurde ontwerp stuur daardie uitruiling elders heen, en dit is ’n ander reëling met ’n ander mislukkingspatroon.

So „die VPN-bediener antwoord nie DHCP nie“ is nie ’n diagnose nie, dit is ’n modelfout. Die plaaslike makelaar is op die foon. As hy ophou antwoord, is die redes plaaslik: die tethering-diens, die kliëntlimiet, die huurkontrakpoel, of ’n kliënt wat nooit assosiasie behoorlik voltooi het nie. Nie een van daardie dinge is aan die afgeleë kant van die tonnel nie.

Wat ’n werkende bestaande kliënt eintlik bewys

As ’n skootrekenaar wat reeds gekoppel was, steeds werk terwyl die nuwe foon nie werk nie, is die hotspot en die opstroompad in die breë lewendig. Daardie vergelyking is nuttig, en dit is nie ’n bewys van watter komponent fout is nie, want die werkende kliënt hou dalk net ’n huurkontrak van voor die verandering en hernu dit stilweg.

Twee plaaslike beperkings is die moeite werd om na te gaan terwyl jy daar is. Die hotspot bedien ’n eindige huurkontrakpoel en ’n verstelbare kliëntlimiet, so ’n toestel wat aangesluit en geslaap het, kan ’n adres hou terwyl ’n nuwe een wag. En ’n kliënt wat ’n statiese konfigurasie van ’n ander netwerk onthou, sal glad nie ’n huurkontrak vra nie, wat van buite identies lyk en by die kliënt reggemaak word, nie op die foon nie.

Hou die vergelyking plaaslik en omkeerbaar

Op ’n toestel waar beleid dit toelaat, vergelyk een aansluiting van ’n nuwe kliënt met die tonnel onaktief en dan aktief, terwyl die hotspot en die kliënt andersins onveranderd bly. Teken die weergawes van die foon en die kliënt aan, die gekose profiel en die presiese fase wat misluk het. Op ’n bestuurde foon, vra die goedgekeurde vergelyking eerder as om die handhawing te deaktiveer om ’n skoner toets te kry.

’n Bestendige huurkontrakmislukking wat van die tonnel afhang, is nuttige bewyse oor plaaslike beleid of ’n implementeringsinteraksie. Dit is nie ’n lisensie om elke deurstuur- en NAT-reël op die toestel te spoel nie. Daardie reëls beskerm onverwante verkeer, en ’n breë deurstuur-toelating verduidelik nie waarom ’n plaaslike DHCP-diens opgehou antwoord het nie.

Moenie ’n ontbrekende huurkontrak met ’n geraaide statiese adres oortrek nie. ’n Doelbewuste statiese konfigurasie het die werklike subnet, die poort, die toekenningsplan en ’n botsingkontrole nodig. Om die kliënt se DNS te verander, verskaf nie een van daardie dinge nie, en dit laat die volgende toestel met dieselfde mislukking.

Wat ’n huurkontrak nie bewys nie

Om ’n adres te kry, bewys toelating tot die plaaslike netwerk, nie beskerming deur die foon se tonnel nie. Sodra die kliënt ’n huurkontrak het, evalueer die stroomafpad op sy eie: loop die kliënt se verkeer werklik deur die foon, word naslaan opgelos waar jy verwag, en stem die buite-adres ooreen met die uitgang wat jy bedoel het? Dit is fase-drie-vrae en hulle verdien hul eie toets eerder as om in die aansluiting ingevou te word.

Werk die fases in volgorde en die mislukking hou op beweeg. ’n Kliënt wat by die verkryging van ’n adres vassit, is ’n plaaslike tethering-vraag; ’n kliënt met ’n adres en geen bladsye nie, is ’n deurstuur- of naamvraag; ’n kliënt met bladsye en die verkeerde uitgang is ’n tonneldekking-vraag. Om hulle apart te hou, is die meeste van die ontfouting.