Sen internet nunha VPN de Windows? O pool de enderezos é o sospeitoso

Windows amosa o túnel como conectado e etiquétao como Sen acceso a Internet, o que a xente le como unha rareza de Windows. É unha afirmación sobre o que recibiu o cliente: ningunha porta de enlace predeterminada utilizábel, ningún resolvedor que funcione, ou ningún camiño de volta para os enderezos dentro do túnel. Cando o servidor é unha Incoming Connection de Windows, unha soa configuración explica a maioría destes informes. A etiqueta non é un diagnóstico, pero reduce a busca a tres lugares.

Le a concesión antes de cambiala

Executa ipconfig /all no cliente e localiza o adaptador VPN entre as entradas. O enderezo, a porta de enlace predeterminada e o servidor DNS que lista son os datos que necesitas, e con frecuencia son distintos do que o administrador supón que se entregou.

Tres patróns corresponden a tres fallos. Un enderezo en 169.254.0.0/16 significa que o cliente non recibiu nada en absoluto e asignouse un enderezo de enlace local. Un enderezo plausible sen porta de enlace significa que o pool se serviu sen a opción que lle dá ao cliente unha ruta predeterminada. Unha concesión completa que aínda non chega a nada apunta ao encamiñamento ou á tradución no lado do servidor.

Anota os valores antes de tocar o servidor. O seguinte paso compáraos co rango que o servidor cre que está a entregar, e a memoria é un mal substituto dunha concesión.

Por que a asignación automática pode deixar sen porta de enlace

A entrada Incoming Connections ten as súas propias propiedades IPv4, separadas do adaptador físico. O predeterminado alí ofrece asignar enderezos automaticamente, o que depende do asignador incorporado da conexión para fornecer un enderezo, unha máscara, unha porta de enlace e DNS.

Nunha estación de traballo illada ese asignador non ten ningún ámbito do que tirar a non ser que outra cousa na máquina forneza un, polo que o cliente pode acabar cun enderezo de enlace local ou cun enderezo pero sen porta de enlace. A conexión parece establecida porque o enlace se levantou, mentres que a configuración detrás del está incompleta.

Por iso cambiar a un rango especificado arranxa tantos destes informes. Deixas de pedirlle a un servizo que pode non estar en funcionamento que invente unha concesión e comezas a declarala ti mesmo.

A mesma confusión aparece cando alguén espera que o servidor DHCP do router da LAN atenda os clientes do túnel. A descuberta por difusión non atravesa un túnel encamiñado, así que ese servidor nunca ve a solicitude. Supor o contrario é a razón máis común pola que se culpa a un pool dun cliente que nunca lle pediu nada.

Define un rango explícito que o servidor poida encamiñar

Escolle un bloque pequeno dentro dunha subrede á que o servidor poida chegar, fóra do rango que reparte o router da LAN e fóra de calquera outro pool da rede. Se o servidor está en 172.20.10.0/24 e o router ten 172.20.10.1, un bloque curto preto do final desa subrede, digamos de 172.20.10.201 a 172.20.10.209, mantén as concesións do túnel lonxe do reparto que o router xa xestiona.

Insíreo nas propiedades IPv4 da Incoming Connection, reconecta o cliente e le o adaptador de novo antes de cambiar calquera outra cousa. Unha segunda lectura é o que che di se o pool era o fallo ou só un fallo entre varios.

Estes comandos imprimen a configuración resultante e as rutas que o cliente ten agora:

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

A porta de enlace da concesión debería ser un enderezo que o servidor posúa, e a ruta predeterminada do cliente debería apuntar a ela. Se a concesión está completa pero non existe ningunha ruta, o servidor asignou sen empurrar unha porta de enlace, e a configuración do pool segue sendo o lugar onde mirar.

Un enderezo non é un camiño a internet

Recibir unha concesión só move paquetes do cliente ao servidor. Para o acceso a internet o servidor debe encamiñar eses paquetes e traducilos cara ao seu propio uplink, e iso é unha configuración separada cos seus propios modos de fallo.

Internet Connection Sharing é o atallo. Converte o adaptador orientado a internet nunha porta de enlace compartida e executa o seu propio enderezamento, o que pode reescribir o enderezo dese adaptador e deixar unha regra NAT existente apuntando a un valor que xa non existe. Anota a configuración orixinal antes de activalo.

A alternativa encamiñada mantén o enderezamento estable e pídeche configurar o encamiñamento e a tradución de forma explícita. Ningún dos dous enfoques está mal; mesturalos a medias produce un túnel cunha concesión e sen saída, que é exactamente o síntoma co que comezaches. Escolle un modelo e remátao antes de engadir o outro.

Descarta primeiro o camiño exterior

Ningún pool pode axudar se o túnel nunca se forma. O protocolo decide o que debe levar o camiño: PPTP quere TCP 1723 e GRE, que é o protocolo IP 47 e non un porto; L2TP/IPsec quere UDP 1701 máis 500 e 4500; SSTP quere TCP 443.

Un router que reenvía o porto pero non o protocolo produce un intento de conexión que nunca se autentica. Iso é un fallo distinto dun túnel que se forma e despois non chega a nada, e os dous non deberían depurarse xuntos.

Proba desde a mesma LAN e desde a rede remota. Se o intento na LAN funciona e o remoto nunca chega á autenticación, o camiño exterior é o problema. Se ambos se autentican e só o cliente remoto non ten internet, volve ao pool e á saída.