Per què la vostra taula de rutes VPN de Windows mostra 0.0.0.0/1 i 128.0.0.0/1
L’opció de passarel·la per defecte afegeix dues mig-rutes, no una. Llegiu el prefix, la mètrica i la interfície abans d’afegir o treure una ruta al client.
Connecteu-vos a una VPN de Windows i obriu la taula de rutes, i hi destaquen dues entrades: 0.0.0.0/1 i 128.0.0.0/1. No són cap error tipogràfic i no substitueixen la ruta per defecte. Que apareguin depèn d’una opció del perfil, i el parell és com es construeix un túnel complet, no una funció de túnel dividit. Llegiu l’opció, el prefix i la interfície junts abans de canviar una sola línia.
Què instal·la l’opció de passarel·la per defecte
L’opció del perfil que ho envia tot pel túnel funciona afegint aquests dos prefixos. Traieu l’opció i desapareixen, deixant una ruta que només cobreix la subxarxa lliurada a l’adaptador del túnel. La casella controla el parell; no reescriu l’única ruta per defecte. Per això la taula després de desmarcar sembla una reescriptura parcial en lloc d’una supressió.
0.0.0.0/1 cobreix la meitat inferior de l’espai IPv4 i 128.0.0.0/1 la meitat superior, així que juntes cobreixen totes les adreces unicast. Cadascuna és més específica que una ruta per defecte 0.0.0.0/0, cosa que significa que la coincidència del prefix més llarg envia el trànsit ordinari al túnel mentre la ruta física per defecte es queda on era. Mantenir aquesta ruta per defecte no és estètic: els paquets que embolcallen la càrrega xifrada van adreçats a l’adreça pública del servidor i han de sortir per l’adaptador físic. Substituïu la ruta per defecte en lloc de dividir-la, i el transport del propi túnel intentarà entrar al túnel, cosa que és un bucle i no una connexió.
Per tant, val la pena aturar-se davant d’una 0.0.0.0/0 literal que apunti a l’adaptador VPN. El client natiu normalment no l’escriu, així que una ruta manual o la configuració d’un altre client ha canviat la taula a la vostra esquena. Trobeu-la abans de depurar res més avall.
Desmuntar és més barat que desar una passarel·la
Desmuntar és l’argument pràctic a favor de dues entrades en lloc d’una. El client posseeix exactament dues rutes mentre està connectat i les esborra en desconnectar, deixant el que l’adaptador físic té en aquell moment. Un client que hagués substituït l’única ruta per defecte hauria de recordar la passarel·la anterior, i després d’un canvi de concessió DHCP podria restaurar-ne una que ja no existeix. Dues entrades pròpies no porten aquest estat.
Altres clients arriben al mateix disseny. Un perfil d’OpenVPN amb redirect-gateway def1 instal·la aquests dos prefixos en lloc d’esborrar la ruta per defecte, i el client de Windows segueix el patró pel mateix motiu d’encaminament.
També és per això que una taula pot semblar un túnel complet quan esperàveu una divisió. El parell és com es construeix el túnel complet, no una prova d’un error de túnel dividit. Si el perfil està configurat per utilitzar la passarel·la remota, tot s’encamina, faci el que faci una aplicació local per arribar-hi.
El prefix més llarg guanya abans que qualsevol mètrica
La longitud del prefix decideix la consulta abans que qualsevol altre camp. La mètrica només desfà els empats entre rutes amb un prefix idèntic, així que una entrada /1 guanya una ruta per defecte /0 fins i tot quan la seva mètrica és pitjor. L’enllaç a la interfície decideix què queda quan dues rutes comparteixen prefix i Windows ha de triar quin adaptador envia el paquet.
route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20
Una taula de túnel dividit conté la ruta física per defecte, les dues mig-rutes, la ruta de la subxarxa del túnel i qualsevol prefix d’oficina que hàgiu afegit. La ruta física per defecte pot seure en una mètrica més baixa o més alta segons el client i el perfil, i mentre existeixi el parell /1 aquesta diferència no canvia res. Ho canvia tot en el moment que es treu el parell, que és quan surt una passarel·la obsoleta o una interfície equivocada. Llegiu tota la taula i no la línia que esperàveu canviar.
Trieu un sol propietari per al prefix de l’oficina
Per a un túnel dividit, anomeneu només el prefix que ha d’usar la VPN i trieu una manera de posseir-lo. Apuntar la ruta a l’adreça de túnel assignada funciona fins que aquesta adreça canvia, mentre que enllaçar-la a la interfície sobreviu al canvi d’adreça però es trenca quan l’índex es reassigna després de reconstruir el perfil. El cmdlet lligat al perfil evita tots dos problemes, a canvi de necessitar el perfil.
route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16
El cmdlet lliga el prefix al perfil anomenat, així que la ruta apareix amb la connexió i se’n va amb ella, que és el que vol un portàtil gestionat. Una ruta persistent sobreviu als reinicis i sobreviu al perfil que la va motivar, i així és com una VPN retirada deixa entrades durant anys. Trieu un mètode per prefix i anoteu l’elecció, perquè una ruta persistent més una ruta de perfil per al mateix prefix produeixen duplicats que són dolorosos de desenredar durant el desmuntatge. Triïu el que triïu, la propietat hauria de ser visible al tiquet i no només a la màquina.
La propietat és la pregunta que respon aquesta secció, no la sintaxi. Dos propietaris per a un prefix és el mode de fallada que val la pena evitar.
Verifiqueu amb una destinació, no amb un lloc web
Proveu la destinació que ha de travessar el túnel, no un lloc web que informi d’una adreça de sortida. Find-NetRoute retorna la ruta seleccionada i l’adreça d’origen, així que podeu veure si ha guanyat el prefix de l’oficina o la ruta física per defecte, i després obriu el recurs compartit mateix.
Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office
Un lloc d’adreça de sortida és una comprovació feble, perquè DNS, IPv6 i un servidor intermediari del navegador poden enviar aquesta petició per camins diferents. IPv4 i IPv6 també tenen configuracions separades al mateix diàleg, i desmarcar una casella deixa l’altra família intacta, així que una màquina de doble pila pot portar IPv6 pel túnel mentre IPv4 segueix la ruta dividida. Comproveu les dues famílies abans de qualificar el perfil de dividit. Si la ruta és correcta i el servei encara falla, la capa que queda és el filtratge i no l’encaminament.
Un tallafoc gestionat pel client pot bloquejar la subxarxa de l’oficina amb una taula de rutes perfecta. Aquesta política pertany a qui va desplegar el perfil, no a qui edita rutes.