Por que a súa táboa de rutas VPN de Windows mostra 0.0.0.0/1 e 128.0.0.0/1

Conéctese a unha VPN de Windows e abra a táboa de rutas, e dúas entradas destacan: 0.0.0.0/1 e 128.0.0.0/1. Non son un erro tipográfico e non substitúen a ruta predeterminada. Que aparezan depende dunha opción do perfil, e o par é a forma en que se constrúe un túnel completo, non unha función de túnel dividido. Lea a opción, o prefixo e a interface xuntos antes de cambiar unha soa liña.

Que instala a opción de porta de enlace predeterminada

A opción do perfil que o envía todo polo túnel funciona engadindo eses dous prefixos. Quite a opción e desaparecen, deixando unha ruta que só cobre a subrede entregada ao adaptador do túnel. A caixa controla o par; non reescribe a única ruta predeterminada. Por iso a táboa tras desmarcar parece unha reescritura parcial en lugar dun borrado.

0.0.0.0/1 cobre a metade inferior do espazo IPv4 e 128.0.0.0/1 a metade superior, así que xuntas cobren todos os enderezos unicast. Cada unha é máis específica ca unha ruta predeterminada 0.0.0.0/0, o que significa que a coincidencia do prefixo máis longo envía o tráfico ordinario ao túnel mentres a ruta física predeterminada queda onde estaba. Conservar esa ruta predeterminada non é cosmético: os paquetes que envolven a carga cifrada van dirixidos ao enderezo público do servidor e teñen que saír polo adaptador físico. Substitúa a ruta predeterminada en lugar de dividila, e o transporte do propio túnel tentará entrar no túnel, o que é un bucle e non unha conexión.

Por iso paga a pena deterse ante unha 0.0.0.0/0 literal que apunte ao adaptador VPN. O cliente nativo normalmente non a escribe, así que unha ruta manual ou a configuración doutro cliente cambiou a táboa ás súas costas. Atópea antes de depurar calquera cousa máis abaixo.

Desmontar é máis barato ca gardar unha porta de enlace

Desmontar é o argumento práctico a favor de dúas entradas en lugar dunha. O cliente posúe exactamente dúas rutas mentres está conectado e elimínaas ao desconectar, deixando o que o adaptador físico teña nese momento. Un cliente que substituíse a única ruta predeterminada tería que lembrar a porta de enlace anterior, e tras un cambio de concesión DHCP podería restaurar unha que xa non existe. Dúas entradas propias non levan ese estado.

Outros clientes chegan ao mesmo deseño. Un perfil de OpenVPN con redirect-gateway def1 instala eses dous prefixos en lugar de borrar a ruta predeterminada, e o cliente de Windows segue o patrón polo mesmo motivo de encamiñamento.

Tamén é por iso que unha táboa pode parecer un túnel completo cando esperaba unha división. O par é a forma en que se constrúe o túnel completo, non unha proba dun erro de túnel dividido. Se o perfil está configurado para usar a porta de enlace remota, todo se encamiña, faga o que faga unha aplicación local por chegar.

O prefixo máis longo gaña antes ca calquera métrica

A lonxitude do prefixo decide a consulta antes ca calquera outro campo. A métrica só desfai os empates entre rutas cun prefixo idéntico, así que unha entrada /1 gaña a unha ruta predeterminada /0 mesmo cando a súa métrica é peor. A vinculación á interface decide que queda cando dúas rutas comparten prefixo e Windows ten que escoller que adaptador envía o paquete.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

Unha táboa de túnel dividido contén a ruta física predeterminada, as dúas medias rutas, a ruta da subrede do túnel e calquera prefixo de oficina que engadise. A ruta física predeterminada pode estar nunha métrica máis baixa ou máis alta segundo o cliente e o perfil, e mentres exista o par /1 esa diferenza non cambia nada. Cámbiao todo no momento en que se quita o par, que é cando aparece unha porta de enlace obsoleta ou unha interface equivocada. Lea toda a táboa e non a liña que esperaba cambiar.

Escolla un único propietario para o prefixo da oficina

Para un túnel dividido, nomee só o prefixo que ten que usar a VPN e escolla unha forma de posuílo. Apuntar a ruta ao enderezo de túnel asignado funciona ata que ese enderezo cambia, mentres que vincularla á interface sobrevive ao cambio de enderezo pero rompe cando o índice se reasigna tras reconstruír o perfil. O cmdlet vinculado ao perfil evita ambos os problemas, a costa de necesitar o 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

O cmdlet vincula o prefixo ao perfil nomeado, así que a ruta aparece coa conexión e vaise con ela, que é o que quere un portátil xestionado. Unha ruta persistente sobrevive aos reinicios e sobrevive ao perfil que a motivou, e así é como unha VPN retirada deixa entradas durante anos. Escolla un método por prefixo e anote a elección, porque unha ruta persistente máis unha ruta de perfil para o mesmo prefixo producen duplicados que son dolorosos de desenredar durante a desmontaxe. Escolla o que escolla, a propiedade debería ser visible no tícket e non só na máquina.

A propiedade é a pregunta que responde esta sección, non a sintaxe. Dous propietarios para un prefixo é o modo de fallo que paga a pena evitar.

Verifique cun destino, non cun sitio web

Proba o destino que ten que cruzar o túnel, non un sitio web que informe dun enderezo de saída. Find-NetRoute devolve a ruta seleccionada e o enderezo de orixe, así que pode ver se gañou o prefixo da oficina ou a ruta física predeterminada, e despois abre o recurso compartido en si.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

Un sitio de enderezo de saída é unha comprobación feble, porque DNS, IPv6 e un proxy do navegador poden enviar esa petición por un camiño distinto. IPv4 e IPv6 tamén teñen axustes separados no mesmo diálogo, e desmarcar unha caixa deixa intacta a outra familia, así que unha máquina de dobre pila pode levar IPv6 polo túnel mentres IPv4 segue a ruta dividida. Comprobe ambas as familias antes de cualificar o perfil de dividido. Se a ruta é correcta e o servizo segue fallando, a capa restante é o filtrado e non o encamiñamento.

Un cortalumes xestionado polo cliente pode bloquear a subrede da oficina cunha táboa de rutas perfecta. Esa política pertence a quen despregou o perfil, non a quen edita rutas.