Conecte o segundo túnel e o primeiro queda calado, mentres ambos os clientes seguen informando dunha conexión sa. Windows só ten unha ruta predeterminada que dar, e cada perfil que a reclama quítaa ao outro. O síntoma parece unha caída da VPN, pero é unha disputa de encamiñamento entre dous perfís. Decida que túnel debe posuír esa ruta e o resto da configuración séguelle.

Só unha entrada pode ser a mellor ruta predeterminada

A táboa de encamiñamento IPv4 garda unha única ruta gañadora para destinos que non teñen unha coincidencia máis específica. Un perfil de VPN que instala a súa substitúe a anterior en canto se conecta, e o tráfico que antes entraba polo primeiro túnel sae agora polo segundo. O primeiro túnel segue activo; o que desaparece é calquera paquete que o usase para destinos xerais.

As iconas de estado do cliente non poden mostralo. Informan de que se estableceu un túnel, non de que prefixos seguen encamiñándose cara a el, así que o usuario ve dúas iconas verdes e un tempo de espera nunha aplicación. Ler route print -4 durante o fallo é máis informativo que calquera rexistro da VPN.

A resolución de nomes é un segundo conflito independente, e arranxar só a táboa de encamiñamento non o resolverá.

Que instala a caixa e que elimina

A opción está nas propiedades do adaptador de cada perfil de VPN, dentro da configuración avanzada de IPv4, formulada como usar a pasarela predeterminada na rede remota. Activada, cada conexión engade unha ruta predeterminada polo túnel e pon esa interface na cola do tráfico xeral. Desactivada, Windows conserva a ruta para a subrede propia do túnel e deixa o resto da táboa en paz.

É ao desmarcala onde a maioría se atasca. O sitio remoto adoita ter máis dun prefixo, e ningún deses prefixos está dentro da subrede do adaptador, así que os servidores de ficheiros e os enderezos de xestión deixan de responder. A caixa non rompeu o túnel; eliminou a ruta ampla que o cubría todo.

As configuracións mixtas son lexítimas e frecuentes: un perfil corporativo mantén a caixa como túnel completo, mentres que un perfil de laboratorio vai dividido para que non poida desprazar a ruta predeterminada corporativa.

Escolla segundo o que deba transportar cada túnel

Tres preguntas deciden a disposición. Este túnel debe transportar tráfico de internet normal ou só enderezos dentro do seu propio sitio? Usan os dous sitios rangos privados disxuntos? E se o perfil o xestiona un empregador, permíteselle cambiar o seu comportamento de encamiñamento?

Se un túnel debe ser completo, posúe a ruta predeterminada e o outro debe ir dividido. Se ningún necesita tráfico xeral de internet, desmarque a caixa en ambos e deixe que o adaptador físico conserve a ruta predeterminada. Se os rangos se solapan, detéñase: 172.22.0.0/16 non pode significar unha máquina no lado corporativo e outra no lado do laboratorio, e ningunha caixa o resolve.

Anote a decisión xunto aos nomes dos perfís. Se non, unha terceira VPN engadida o próximo trimestre repetirá a investigación desde o principio.

Engada os prefixos que faltan e probe o resultado

Para cada túnel dividido, engada os rangos remotos de forma explícita, usando o enderezo de par que mostra ese adaptador en lugar do enderezo público do servidor:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

Un adaptador PPP usa o seu enderezo de par como seguinte salto, mentres que un adaptador TAP adoita usar a pasarela que mostra esa interface, así que lea os detalles do adaptador en lugar de copiar un número dunha guía. Engada o indicador persistente só despois de que a ruta se demostre correcta, e borre as entradas persistentes antigas antes de engadir substitucións. Os clientes xestionados poden instalar e protexer as súas propias rutas, e nese caso o propietario do perfil ten que facer o cambio.

O DNS necesita unha pasada aparte. Ambos os túneles poden empurrar resolutores, e Windows mantén unha lista por interface cunha orde de preferencia, así que un nome da segunda rede pode acabar no resolutor da primeira. Mire que recibiu realmente cada adaptador antes de escoller unha solución:

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

Unha política de resolución de nomes por dominio adoita ser mellor que substituír a lista global de resolutores, porque esa lista compártea cada aplicación da máquina e cambiala en silencio move buscas non relacionadas.

Acepte a configuración con catro comprobacións: un recurso en cada rede remota accesible por enderezo, unha consulta de nome en cada unha, a ruta predeterminada de internet aínda apuntando ao adaptador físico e unha sesión de escritorio remoto que sobrevive a que se levante a segunda conexión.

Artigos relacionados