Fără internet pe un VPN Windows? Piscina de adrese este suspectul

Windows arată tunelul ca fiind conectat și îl etichetează Fără acces la internet, ceea ce oamenii citesc ca o ciudățenie a Windows. Este o afirmație despre ce a primit clientul: niciun gateway implicit utilizabil, niciun resolver funcțional sau nicio cale de întoarcere pentru adresele din interiorul tunelului. Când serverul este o Incoming Connection Windows, o singură setare explică majoritatea acestor rapoarte. Eticheta nu este un diagnostic, dar restrânge căutarea la trei locuri.

Citește bail-ul înainte de a-l schimba

Rulează ipconfig /all pe client și găsește adaptorul VPN printre intrări. Adresa, gateway-ul implicit și serverul DNS pe care le listează sunt faptele de care ai nevoie și deseori diferă de ceea ce administratorul presupune că a fost alocat.

Trei modele corespund la trei defecțiuni. O adresă în 169.254.0.0/16 înseamnă că clientul nu a primit nimic și și-a atribuit singur o adresă link-local. O adresă plauzibilă fără gateway înseamnă că piscina a fost servită fără opțiunea care îi dă clientului o rută implicită. Un bail complet care tot nu ajunge nicăieri indică forwardare sau traducere pe partea serverului.

Notează valorile înainte de a atinge serverul. Pasul următor le compară cu intervalul pe care serverul crede că îl distribuie, iar memoria este un substitut slab pentru un bail.

De ce alocarea automată poate lăsa fără gateway

Intrarea Incoming Connections are propriile proprietăți IPv4, separate de adaptorul fizic. Valoarea implicită de acolo oferă să aloce adrese automat, ceea ce se bazează pe alocatorul încorporat al conexiunii pentru a furniza adresă, mască, gateway și DNS.

Pe o stație de lucru independentă acel alocator nu are un interval din care să extragă decât dacă altceva de pe mașină furnizează unul, așa că clientul poate ajunge cu o adresă link-local sau cu o adresă dar fără gateway. Conexiunea pare stabilită pentru că legătura a urcat, în timp ce configurația din spate este incompletă.

De aceea trecerea la un interval specificat repară atât de multe dintre aceste rapoarte. Oprești cererea către un serviciu care poate nu rulează să inventeze un bail și începi să declari tu însuți bail-ul.

Aceeași confuzie apare când cineva se așteaptă ca serverul DHCP al routerului LAN să deservească clienții tunelului. Descoperirea prin broadcast nu traversează un tunel rutat, așa că acel server nu vede niciodată cererea. A presupune contrariul este cel mai frecvent motiv pentru care o piscină este învinuită pentru un client care nu i-a cerut niciodată nimic.

Setează un interval explicit pe care serverul îl poate ruta

Alege un bloc mic într-o subrețea pe care serverul o poate atinge, în afara intervalului pe care routerul LAN îl distribuie și în afara oricărei alte piscine din rețea. Dacă serverul stă pe 172.20.10.0/24 și routerul deține 172.20.10.1, un bloc scurt lângă partea de sus a acelei subrețele, să zicem de la 172.20.10.201 la 172.20.10.209, ține bail-urile tunelului departe de distribuirea pe care routerul o administrează deja.

Introdu-l în proprietățile IPv4 ale Incoming Connection, reconectează clientul și citește adaptorul din nou înainte de a schimba orice altceva. A doua citire este cea care îți spune dacă piscina a fost defectul sau doar un defect dintre mai multe.

Aceste comenzi afișează configurația rezultată și rutele pe care clientul le are acum:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Gateway-ul din bail ar trebui să fie o adresă pe care serverul o deține, iar ruta implicită a clientului ar trebui să indice spre ea. Dacă bail-ul este complet dar nu există nicio rută, serverul a alocat fără a împinge un gateway, iar setările piscinei rămân locul de căutat.

O adresă nu este o cale spre internet

Primirea unui bail mută doar pachetele de la client la server. Pentru acces la internet serverul trebuie să forwardeze acele pachete și să le traducă spre propriul uplink, iar aceasta este o configurație separată cu propriile moduri de eșec.

Internet Connection Sharing este scurtătura. Transformă adaptorul orientat spre internet într-un gateway partajat și rulează propria adresare, ceea ce poate rescrie adresa acelui adaptor și poate lăsa o regulă NAT existentă indicând o valoare care nu mai există. Notează setările originale înainte de a-l activa.

Alternativa rutată menține adresarea stabilă și îți cere să configurezi forwardarea și traducerea în mod explicit. Niciuna dintre abordări nu este greșită; amestecarea lor pe jumătate produce un tunel cu bail și fără ieșire, care este exact simptomul cu care ai început. Alege un model și termină-l înainte de a-l adăuga pe celălalt.

Elimină mai întâi calea exterioară

Nicio piscină nu ajută dacă tunelul nu se formează niciodată. Protocolul decide ce trebuie să transporte calea: PPTP vrea TCP 1723 și GRE, care este protocolul IP 47, nu un port; L2TP/IPsec vrea UDP 1701 plus 500 și 4500; SSTP vrea TCP 443.

Un router care forwardează portul dar nu protocolul produce o încercare de conexiune care nu se autentifică niciodată. Este o defecțiune diferită de un tunel care se formează și apoi nu ajunge nicăieri, iar cele două nu ar trebui depistate împreună.

Testează din același LAN și din rețeaua la distanță. Dacă încercarea din LAN funcționează iar cea la distanță nu ajunge niciodată la autentificare, calea exterioară este problema. Dacă ambele se autentifică și doar clientul la distanță nu are internet, întoarce-te la piscină și la ieșire.