Sense internet en una VPN de Windows? El sospitós és el conjunt d’adreces

Windows mostra el túnel com a connectat i l’etiqueta com a Sense accés a internet, cosa que la gent llegeix com una raresa de Windows. És una afirmació sobre què ha rebut el client: cap passarel·la predeterminada utilitzable, cap resolutor que funcioni o cap camí de tornada per a les adreces dins del túnel. Quan el servidor és una connexió entrant de Windows, un sol paràmetre explica la majoria d’aquests informes. L’etiqueta no és un diagnòstic, però estreny la cerca a tres llocs.

Llegeix l’arrendament abans de canviar-lo

Executa ipconfig /all al client i troba l’adaptador VPN entre les entrades. L’adreça, la passarel·la predeterminada i el servidor DNS que hi apareixen són les dades que necessites, i sovint són diferents del que l’administrador suposa que s’ha lliurat.

Tres patrons corresponen a tres fallades. Una adreça dins de 169.254.0.0/16 vol dir que el client no ha rebut res i s’ha assignat una adreça local d’enllaç. Una adreça plausible sense passarel·la vol dir que el conjunt s’ha servit sense l’opció que dona al client una ruta predeterminada. Un arrendament complet que encara no arriba enlloc apunta a reenviament o traducció al costat del servidor.

Anota els valors abans de tocar el servidor. El pas següent els compara amb el rang que el servidor creu que reparteix, i la memòria és un mal substitut d’un arrendament.

Per què l’assignació automàtica pot deixar sense passarel·la

L’entrada Connexions entrants té les seves pròpies propietats IPv4, separades de l’adaptador físic. El valor predeterminat d’allà ofereix assignar adreces automàticament, cosa que depèn de l’assignador integrat de la connexió per proporcionar una adreça, una màscara, una passarel·la i DNS.

En una estació de treball aïllada, aquest assignador no té cap àmbit d’on treure res, tret que una altra cosa de la màquina n’aporti un, així que el client pot acabar amb una adreça local d’enllaç o amb una adreça però sense passarel·la. La connexió sembla establerta perquè l’enllaç s’ha aixecat, mentre que la configuració que hi ha darrere és incompleta.

Per això canviar a un rang especificat arregla tants d’aquests informes. Deixes de demanar a un servei que potser no s’executa que inventi un arrendament i comences a declarar tu mateix l’arrendament.

La mateixa confusió apareix quan algú espera que el servidor DHCP del router LAN serveixi els clients del túnel. El descobriment per difusió no travessa un túnel encaminat, així que aquest servidor no veu mai la petició. Suposar el contrari és la raó més habitual per culpar un conjunt d’un client que mai no li ha preguntat res.

Defineix un rang explícit que el servidor pugui encaminar

Tria un bloc petit dins d’una subxarxa a què el servidor pugui arribar, fora del rang que reparteix el router LAN i fora de qualsevol altre conjunt de la xarxa. Si el servidor és a 172.20.10.0/24 i el router té 172.20.10.1, un bloc curt a la part alta d’aquesta subxarxa, posem per cas de 172.20.10.201 a 172.20.10.209, manté els arrendaments del túnel allunyats del repartiment que el router ja gestiona.

Introdueix-lo a les propietats IPv4 de la connexió entrant, torna a connectar el client i llegeix l’adaptador una altra vegada abans de canviar res més. La segona lectura és la que et diu si el conjunt era la fallada o només una fallada entre diverses.

Aquestes ordres imprimeixen la configuració resultant i les rutes que el client té ara:

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

La passarel·la de l’arrendament hauria de ser una adreça que el servidor tingui, i la ruta predeterminada del client hauria d’apuntar-hi. Si l’arrendament és complet però no existeix cap ruta, el servidor ha assignat sense empènyer una passarel·la, i la configuració del conjunt continua sent el lloc on mirar.

Una adreça no és un camí a internet

Rebre un arrendament només mou paquets del client al servidor. Per accedir a internet, el servidor ha de reenviar aquests paquets i traduir-los cap al seu propi enllaç ascendent, i això és una configuració separada amb les seves pròpies maneres de fallar.

La compartició de connexió a internet és la drecera. Converteix l’adaptador orientat a internet en una passarel·la compartida i executa el seu propi adreçament, que pot reescriure l’adreça d’aquell adaptador i deixar una regla NAT existent apuntant a un valor que ja no existeix. Anota la configuració original abans d’activar-la.

L’alternativa encaminada manté l’adreçament estable i et demana que configuris el reenviament i la traducció explícitament. Cap dels dos enfocaments és incorrecte; barrejar-los a mitges produeix un túnel amb arrendament i sense sortida, que és exactament el símptoma amb què vas començar. Tria un model i acaba’l abans d’afegir l’altre.

Descarta primer el camí exterior

Cap conjunt no pot ajudar si el túnel no es forma mai. El protocol decideix què ha de portar el camí: PPTP vol TCP 1723 i GRE, que és el protocol IP 47 i no un port; L2TP/IPsec vol UDP 1701 més 500 i 4500; SSTP vol TCP 443.

Un router que reenvia el port però no el protocol produeix un intent de connexió que no s’autentica mai. Aquesta és una fallada diferent d’un túnel que es forma i després no arriba enlloc, i les dues no s’han de depurar juntes.

Prova des de la mateixa LAN i des de la xarxa remota. Si l’intent des de la LAN funciona i el remot no arriba mai a l’autenticació, el problema és el camí exterior. Si tots dos s’autentiquen i només el client remot no té internet, torna al conjunt i a la sortida.