Un client nou de hotspot blocat la obținerea IP nu este o defecțiune VPN

Un telefon se asociază la hotspot, rămâne la „Se obține adresa IP” și în cele din urmă renunță. Concluzia naturală este că VPN-ul telefonului interferează cu DNS, așa că oamenii încep să editeze resolverii și regulile adăugate. Este etapa greșită. Clientul nu a primit niciodată o adresă locală, iar fără una nu are gateway, nu are resolver și nu are ce redirecționa, deci nicio setare VPN de pe telefonul gazdă nu poate explica eșecul. Asocierea, alocarea adresei locale și redirecționarea sunt trei etape separate, iar doar ultima implică tunelul.

Cele trei etape și în care vă aflați

Mai întâi vine asocierea: clientul se alătură rețelei wireless a hotspotului. O parolă greșită, o nepotrivire WPA3 sau o problemă de compatibilitate radio eșuează aici, iar clientul de obicei spune asta. A doua este alocarea adresei: pentru IPv4 clientul cere un lease și primește o adresă plus setări locale de gateway, în timp ce IPv6 folosește de obicei anunțuri de router în loc de DHCP, cum descrie documentația AOSP despre tethering. A treia este accesul spre exterior: telefonul gazdă redirecționează traficul permis către calea superioară pe care a ales-o, care poate fi sau nu tunelul său.

Textul de pe client vă spune etapa. Blocat la obținerea unei adrese este a doua etapă, înainte ca vreun pachet să plece spre internet. Conectat, cu adresă, dar nimic nu se încarcă este a treia etapă, unde rutarea, numele și acoperirea tunelului contează toate. A diagnostica a treia etapă în timp ce clientul este blocat în a doua este felul în care o problemă de lease de cinci minute devine o după-amiază de editări DNS.

Mitul: un VPN rutat transformă DHCP local într-o cerere la distanță

Un tunel rutat mută pachete IP pentru destinațiile pe care le selectează. Descoperirea DHCP este o difuzare pe segmentul propriu al hotspotului, iar serviciul de tethering de pe telefon răspunde local, de aceea clientul poate primi o adresă în timp ce tunelul este activ. Doar un design deliberat punte sau retransmis trimite acel schimb în altă parte, iar aceea este o altă configurare cu altă semnătură de eșec.

Deci „serverul VPN nu răspunde la DHCP” nu este un diagnostic, este o eroare de model. Intermediarul local este pe telefon. Dacă încetează să răspundă, motivele sunt locale: serviciul de tethering, limita de clienți, rezerva de lease-uri sau un client care nu a finalizat niciodată corect asocierea. Niciuna dintre acestea nu locuiește în partea îndepărtată a tunelului.

Ce demonstrează de fapt un client existent care funcționează

Dacă un laptop care era deja conectat încă funcționează, iar telefonul nou nu, hotspotul și calea superioară sunt în general vii. Comparația este utilă și nu este o dovadă a componentei vinovate, pentru că clientul care funcționează poate pur și simplu să păstreze un lease dinainte de schimbare și să îl reînnoiască în liniște.

Merită verificate două limite locale cât timp sunteți acolo. Hotspotul deservește o rezervă finită de lease-uri și o limită configurabilă de clienți, așa că un dispozitiv care s-a asociat și a adormit poate ține o adresă în timp ce unul nou așteaptă. Iar un client care își amintește o configurație statică din altă rețea nu va cere deloc un lease, ceea ce din exterior arată identic și se corectează la client, nu pe telefon.

Păstrați comparația locală și reversibilă

Pe un dispozitiv unde politica permite, comparați o singură asociere de client nou cu tunelul inactiv și apoi activ, păstrând hotspotul și clientul neschimbate în rest. Notați versiunile telefonului și ale clientului, profilul ales și etapa exactă care a eșuat. Pe un telefon administrat, cereți comparația aprobată în loc să dezactivați aplicarea pentru un test mai curat.

Un eșec de lease consistent și dependent de tunel este o dovadă utilă despre politica locală sau o interacțiune de implementare. Nu este o licență pentru a goli fiecare regulă de redirecționare și NAT de pe dispozitiv. Acele reguli protejează traficul necorelat, iar o acceptare largă a redirecționării nu explică de ce un serviciu DHCP local a încetat să răspundă.

Nu acoperiți un lease lipsă cu o adresă statică ghicită. O configurație statică deliberată are nevoie de subrețeaua reală, de gateway, de planul de alocare și de o verificare a coliziunilor. Schimbarea DNS-ului clientului nu oferă niciuna dintre acestea și lasă următorul dispozitiv cu același eșec.

Ce nu demonstrează un lease

Obținerea unei adrese demonstrează admiterea în rețeaua locală, nu protecția prin tunelul telefonului. Odată ce clientul are un lease, evaluați calea descendentă separat: traficul clientului trece într-adevăr prin telefon, căutările se rezolvă unde vă așteptați și adresa exterioară corespunde ieșirii dorite? Sunt întrebări de etapa a treia și merită propriul test în loc să fie pliate în asociere.

Parcurgeți etapele în ordine și eșecul încetează să se mai mute. Un client blocat la obținerea unei adrese este o întrebare locală de tethering; un client cu adresă și fără pagini este o întrebare de redirecționare sau de nume; un client cu pagini și ieșirea greșită este o întrebare de acoperire a tunelului. Ținerea lor separată este cea mai mare parte a depanării.