Túnel dividido por aplicación ou por destino: cal escoller

O túnel dividido por aplicación e por destino non son dous axustes para a mesma tarefa. Un pregunta que proceso envía un paquete; o outro pregunta cara a onde vai ese paquete. Unha regra creada para a primeira pregunta falla en silencio cando o tráfico vén dun proceso auxiliar, e unha regra creada para a segunda falla cando un nome de host se resolve nun enderezo que nunca incluíu. Escolla o obxecto que coincide co requisito e demóstreo con dous paquetes de proba: un que debe usar o túnel e outro que non.

As dúas regras actúan en capas distintas

Unha regra de aplicación aplícase por riba da capa de rede, contra a identidade que o sistema operativo asigna ao emisor. En Android é o UID detrás dun paquete, e o servizo VPN decide por UID se o tráfico entra no túnel. Non se consulta nada sobre o destino, así que a aplicación escollida pode alcanzar calquera cousa e ningunha outra aplicación pode alcanzar a rede interna.

Unha regra de destino aplícase sobre o propio paquete. A interface do túnel posúe un conxunto de prefixos, a táboa de rutas envía alí o tráfico coincidente e o proceso emisor é irrelevante. Por iso unha regra de destino cobre un servizo, unha impresora ou unha tarefa por lotes que ninguén lembrou incluír, e por iso non se pode expresar como este programa exacto nunha plataforma cuxo cliente nunca mira o proceso.

As regras de aplicación encaixan en clientes móbiles e axentes xestionados

Android expón a elección directamente: VpnService.Builder.addAllowedApplication() e addDisallowedApplication() toman nomes de paquete e aplican a decisión por UID, como se describe na guía para desenvolvedores de VPN de Android. iOS ten un equivalente mediante regras VPN por aplicación baseadas en identificadores de paquete, normalmente entregadas por un perfil MDM en lugar de escribirse a man.

Os clientes de escritorio son o punto débil. A maioría dos clientes VPN de Windows e macOS encaminan por destino e non ofrecen ningún selector por proceso, porque o controlador do túnel ve paquetes, non procesos. Se o seu plan depende de tunelizar unha aplicación nun portátil, comprobe as capacidades reais do cliente antes de deseñar arredor diso; quizais estea escollendo entre unha lista de destinos e unha segunda máquina.

Un corolario que a xente pasa por alto: non pode imitar unha regra de aplicación con rutas nesas plataformas. Engadir unha ruta de host para o servidor da aplicación tuneliza o tráfico de todos cara a ese servidor, incluídos o navegador e o actualizador.

As regras de destino encaixan en listas de subredes e alcance de sitios

WireGuard fai explícito o modelo. AllowedIPs é encamiñamento por clave criptográfica: un paquete interno cuxo destino cae dentro da lista dun par cifrase cara a ese par, e todo o demais sae sen cifrar pola ruta normal. Non hai ningún proceso que nomear nin ambigüidade sobre o que se inclúe.

OpenVPN chega ao mesmo punto mediante a táboa de rutas empurrada. route-nopull impide que o servidor dite rutas, e despois unha route 10.20.0.0 255.255.0.0 vpn_gateway do lado do cliente cobre exactamente o prefixo da oficina. IPv6 é unha declaración aparte en cada un destes clientes, e esquecelo é a forma máis habitual de filtrar arredor dun split IPv4 que parece correcto.

Un nome de host non é unha ruta. Se o perfil ofrece un campo de dominio, tráteo como un nome que o cliente resolve unha vez, non como un rango de enderezos permanente; as redes de distribución de contido e os balanceadores de carga entregarán enderezos distintos mañá.

Onde fallan ambos os modelos: auxiliares, servizos compartidos, resolutores

Os procesos auxiliares rompen as regras de aplicación dun xeito que parece un fallo do servidor. O actualizador dun navegador, un informador de fallos, un servizo de sincronización que se executa como SYSTEM e un WebView incrustado noutro paquete son identidades separadas, así que tunelizar o navegador pode deixar a petición real fóra do túnel. O revés é igual de confuso: unha aplicación excluída que chama unha biblioteca compartida dentro dun proceso tunelizado segue tendo o seu tráfico dentro do túnel.

As regras de destino rompen en servizos compartidos e en nomes. Os recursos compartidos de ficheiros, as impresoras, o DNS interno e o servidor de licenzas viven en enderezos, así que un túnel dunha soa aplicación dá acceso ao navegador mentres a unidade mapeada queda morta. Esa diferenza de cobertura non é un erro de ningún dos dous modelos, pero é a razón pola que un túnel dunha soa aplicación produce tan a miúdo que a VPN está activa e o recurso compartido desapareceu.

Os resolutores atravesan ambos. Se o cliente configura servidores DNS internos pero o sistema operativo usa DNS sobre HTTPS cara a un resolutor público, a resposta vén de fóra do túnel e a regra de destino pode non coincidir nunca. Comprobe que resolutor respondeu realmente antes de concluír que a regra é incorrecta, e confirme no lado do cliente se instalou o resolutor do túnel. Un split que deixa o DNS fóra do túnel parece perfecto na táboa de rutas e aínda así falla en todos os nomes internos.

Procedemento: escoller, aplicar, verificar

Comece polo requisito, non polo menú. Se o obxectivo é que só esta aplicación poida usar o túnel, necesita regras de aplicación e unha plataforma que as admita. Se o obxectivo é que estas redes sexan accesibles a través do túnel, necesita prefixos. Se a resposta é ambas as dúas cousas, implénteas como dous controis separados e anote cal posúe que fallo.

Aplique a forma máis estreita que poida expresar e despois verifique preguntando á táboa de rutas en lugar de ao icono de estado do cliente:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

As dúas primeiras liñas nomean a interface que usaría un destino real; wg show imprime a lista de prefixos configurada; en Windows, Find-NetRoute responde á mesma pregunta que responderá a pila cando se envíe o paquete. Se a interface é o túnel, a regra coincidiu.

Despois probe un segundo paquete que debería quedar excluído, desde outra aplicación, cara ao mesmo destino. Anote no tícket a versión do cliente, o tipo de regra, a lista de prefixos ou de paquetes e os dous resultados observados. Ese par de resultados é o que lle di ao seguinte enxeñeiro se a política está mal configurada ou se o tráfico nunca lle pertenceu.