Túnel dividit a Windows: la casella de passarel·la i el prefix que falta

El túnel informa que està connectat i el wiki encara carrega. Llavors una descàrrega s'encalla i el recurs compartit del prestatge deixa de respondre. El túnel va fer la seva feina, i el perfil simplement reclamava cada destinació.

Windows tracta una connexió VPN com una decisió d'encaminament. Fins que aquesta decisió no s'estrenyi, la màquina es comporta com si s'hagués traslladat a l'oficina.

Per què un túnel que funciona sembla una caiguda

Un perfil autoritzat a usar la passarel·la remota instal·la una ruta per defecte a través del túnel. Aleshores cada destinació que no és a l'enllaç local surt pel tallafoc de l'oficina. Els recursos compartits locals deixen de respondre perquè el seu trànsit ara viatja a un altre continent i torna. Res a l'estat del client ho reflecteix.

Els símptomes són confusos a propòsit. La resolució de noms pot continuar funcionant mentre el recurs compartit expira, o al revés. L'usuari informa que la VPN està trencada, el client informa que ell està bé, i les dues afirmacions són exactes.

La casella amagada al diàleg IPv4

El paràmetre és a diversos diàlegs de fondària. Obriu ncpa.cpl, feu clic amb el botó dret a la connexió, després a les propietats d'IPv4, després a Avançat, i desactiveu l'opció que permet que la connexió es converteixi en la passarel·la per defecte remota. Aquesta sola casella decideix si el perfil és un túnel complet. Tota la resta del perfil continua aplicant-se.

Compareu route print -4 abans i després de reconnectar. L'entrada 0.0.0.0 que abans apuntava al túnel hauria d'haver desaparegut, i els prefixos corporatius haurien de continuar allà.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Canviar la mètrica de la interfície no és un substitut. Una mètrica només decideix entre dues rutes per defecte competidores, i un client que reinstal·la la seva pròpia ruta per defecte en connectar guanya aquesta competició sigui quin sigui el número configurat.

El prefix que ningú no va llistar

El túnel dividit exposa exactament els prefixos registrats al perfil. Una subxarxa d'oficina afegida després d'escriure el perfil queda inaccessible mentre el túnel és perfectament sa. Llavors l'informe arriba com un servidor trencat en lloc d'una VPN trencada.

Una ruta afegida a mà cobreix el buit fins que canvia l'adreça de la passarel·la. Enregistrar el prefix a la connexió és més sòlid, perquè el prefix aleshores segueix la connexió en lloc d'una adreça endevinada.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Llegiu la llista desada i la taula activa alhora. Un prefix desat pot existir mentre la taula no el rep mai, cosa que passa quan un agent de gestió filtra rutes després que la connexió s'aixequi. El contrari també passa, amb una ruta del registre apuntant a un adaptador que està aturat. Cap de les dues vistes per si sola explica tota la història.

Demostrar el resultat després d'un reinici

Feu el traçat en tots dos sentits i resoleu per nom. Un traçat públic hauria de sortir pel proveïdor, un traçat intern hauria d'entrar al túnel, i un amfitrió intern hauria de respondre pel nom i no només per l'adreça.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Repetiu-ho després d'una desconnexió, una reconnexió i un reinici. Un prefix que sobreviu a una reconnexió manual i desapareix després d'un reinici mai no es va desar al perfil.

Mantingueu també la impressora i el NAS a la prova, perquè un túnel dividit que talla els dispositius al costat de l'ordinador portàtil ha resolt un problema creant-ne un de més petit i més irritant. La referència d'Add-VpnConnectionRoute de Microsoft és el lloc on comprovar l'ortografia dels paràmetres amb la versió del vostre mòdul.