Como o túnel dividido decide que tráfico usa a VPN

O túnel dividido é unha política de encamiñamento expresada como un conxunto de regras, e o cliente é só o que as instala. A separación ocorre en dous lugares: regras de coincidencia que elixen un camiño para cada paquete, e vinculacións que manteñen unha aplicación nunha interface diga o que diga a táboa. En que mecanismo se apoia o seu cliente explica a maioría das sorpresas que a xente reporta.

Unha política que pode formular nunha liña é comprobable. Unha política descrita como navegación máis rápida non o é, e non lle dirá que regra cambiar cando unha solicitude vai polo camiño equivocado.

O cliente instala regras, o núcleo toma a decisión

Cando o túnel se levanta, o cliente engade rutas e a miúdo regras de política á mesma táboa que usan as súas outras interfaces. Cada paquete chega entón a unha busca que compara o seu destino con cada prefixo candidato e conserva a coincidencia máis específica, mentres a prioridade resolve empates entre regras que apuntan a táboas distintas. Nada nesa busca sabe que o paquete veu dunha pestana do navegador e non dunha tarefa de copia de seguridade. A regra que gaña é a que fixa a ruta, e pode lela antes e despois do cambio.

Por iso un túnel dividido pode parecer arbitrario. Dous destinos nunha mesma aplicación poden tomar rutas distintas só porque un prefixo é máis estreito que o outro.

A mesma elección existe en cada plataforma, aínda que os nomes cambian. Windows empuxa a decisión á súa plataforma de filtros, Android expón unha lista de permitidos por aplicación a través do seu servizo VPN, e macOS ata o túnel a un dispositivo que aínda obedece a táboa de encamiñamento. As notas de encamiñamento de Microsoft merecen lerse para o caso de Windows, e unha guía escrita para unha plataforma raras veces se traslada sen cambios a outra.

A vinculación por aplicación e os prefixos de destino son ferramentas distintas

Unha política de destino pregunta cara a onde vai o paquete e consulta a táboa de rutas ou unha regra de política. Unha política por aplicación pregunta que programa abriu o socket, e a plataforma mantén ese programa na interface do túnel mesmo cando unha ruta máis específica apunta a outro sitio. A segunda é máis forte porque sobrevive aos cambios de táboa, pero só cobre os procesos que a plataforma pode atribuír. Un proceso auxiliar, un navegador incrustado ou un servizo que abre a súa propia conexión pode que non herden a vinculación que vostede supuxo.

Ningún dos dous enfoques sobrevive a unha política baseada en nomes sen axuda. Os enderezos dos sitios grandes rotan entre redes de contido, así que fixar un nome de host a uns poucos prefixos produce unha regra que deixa de coincidir en silencio. Unha política que debe seguir nomes necesita un compoñente consciente do resolver en lugar dunha ruta estática.

O DNS e o interruptor de seguridade seguen as súas propias regras

A resolución de nomes é unha decisión separada do encamiñamento de paquetes, e un túnel dividido normalmente quere dous resolvers: o da empresa para nomes internos, o local para todo o demais. O cliente pode instalar axustes DNS por interface, entregar as consultas a un resolver intermedio ou deixar o valor predeterminado do sistema intacto. Un navegador co seu propio resolver cifrado evita as tres disposicións. Probe unha consulta en lugar de supor que o resolver seguiu a ruta.

Un interruptor de seguridade engade un filtro por riba, e ese filtro non sempre distingue unha exclusión deliberada dunha fuga accidental. Algúns clientes bloquean todo fóra do túnel mentres outros permiten as exclusións que a política declara, así que lea que comportamento implementa o seu antes de confiar en calquera dos dous.

Comprobe a división desde ambos os lados

Probe a ruta incluída e a ruta excluída por separado, e xulgue o resultado polo nome da interface e non por un enderezo público. Estes comandos supoñen un host Linux co dispositivo de túnel xa levantado. Substitúa 203.0.113.10 por un destino que a súa política encamiña cara a dentro, e 198.51.100.25 por un que envía cara a fóra.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Lea as dúas primeiras respostas xuntas, porque a interface nomeada en cada unha mostra se a división puxo ese destino no túnel. A consulta ao resolver mostra que servidor respondeu ao nome interno, e o último comando demostra que o dispositivo de túnel pode transportar unha solicitude. Un fallo na segunda liña mentres a primeira ten éxito significa que a política fai exactamente o que se lle dixo.

Repita o conxunto tras unha reconexión e tras un cambio de rede. A renovación do arrendamento e a axitación das interfaces son onde unha división deixa de coincidir coa intención para a que se construíu, e unha saída gardada de cada execución fai evidente a deriva.