Túnel dividit per aplicació o per destinació: què triar

El túnel dividit per aplicació i per destinació no són dos paràmetres per a la mateixa feina. Un pregunta quin procés envia el paquet; l'altre pregunta on va aquest paquet. Una regla feta per a la primera pregunta falla en silenci quan el trànsit ve d'un procés auxiliar, i una regla feta per a la segona falla quan un nom d'amfitrió es resol en una adreça que no heu llistat mai. Trieu l'objecte que coincideix amb el requisit i demostreu-ho amb dos paquets de prova: un que ha d'usar el túnel i un que no.

Les dues regles actuen en capes diferents

Una regla d'aplicació s'aplica per sobre de la capa de xarxa, contra la identitat que el sistema operatiu assigna a l'emissor. A Android és l'UID darrere d'un paquet, i el servei VPN decideix per UID si el trànsit entra al túnel. No es consulta res sobre la destinació, així que l'aplicació seleccionada pot arribar a qualsevol cosa i cap altra aplicació pot arribar a la xarxa interna.

Una regla de destinació s'aplica al paquet mateix. La interfície del túnel posseeix un conjunt de prefixos, la taula d'encaminament hi envia el trànsit que coincideix i el procés emissor és irrellevant. Per això una regla de destinació cobreix un servei, una impressora o una tasca per lots que ningú no va recordar llistar, i per això no es pot expressar com aquest programa en una plataforma el client de la qual no mira mai el procés.

Les regles d'aplicació encaixen en clients mòbils i agents gestionats

Android exposa l'elecció directament: VpnService.Builder.addAllowedApplication() i addDisallowedApplication() prenen noms de paquet i apliquen la decisió per UID, com es descriu a la guia de desenvolupadors de VPN d'Android. iOS té un equivalent mitjançant regles VPN per aplicació basades en identificadors de paquet, normalment lliurades per un perfil MDM en lloc d'escrites a mà.

Els clients d'escriptori són el punt feble. La majoria de clients VPN de Windows i macOS encaminen per destinació i no ofereixen cap selector per procés, perquè el controlador del túnel veu paquets, no processos. Si el vostre pla depèn de túnels per a una aplicació en un portàtil, comproveu les capacitats reals del client abans de dissenyar-hi al voltant; potser trieu entre una llista de destinacions i una segona màquina.

Un corol·lari que la gent passa per alt: no podeu imitar una regla d'aplicació amb rutes en aquestes plataformes. Afegir una ruta d'amfitrió per al servidor de l'aplicació tunelitza el trànsit de tothom cap a aquest servidor, inclòs el navegador i l'actualitzador.

Les regles de destinació encaixen en llistes de subxarxes i abast de llocs

WireGuard fa explícit el model. AllowedIPs és encaminament per clau criptogràfica: un paquet intern la destinació del qual cau dins de la llista d'un parell s'encripta cap a aquell parell, i tota la resta surt sense xifrar pel camí normal. No hi ha cap procés a anomenar ni cap ambigüitat sobre què s'inclou.

OpenVPN arriba al mateix lloc mitjançant la taula d'encaminament empenyuda. route-nopull atura el servidor a l'hora de dictar rutes, i després una route 10.20.0.0 255.255.0.0 vpn_gateway del costat client cobreix exactament el prefix de l'oficina. IPv6 és una declaració separada en cadascun d'aquests clients, i oblidar-lo és la manera més habitual de filtrar al voltant d'un split IPv4 que sembla correcte.

Un nom d'amfitrió no és una ruta. Si el perfil ofereix un camp de domini, tracteu-lo com un nom que el client resol una vegada, no com un rang d'adreces permanent; les xarxes de distribució de contingut i els balancejadors de càrrega donaran adreces diferents demà.

On fallen tots dos models: auxiliars, serveis compartits, resolutors

Els processos auxiliars trenquen les regles d'aplicació d'una manera que sembla una fallada del servidor. L'actualitzador d'un navegador, un informador de fallades, un servei de sincronització que s'executa com a SYSTEM i un WebView incrustat en un altre paquet són identitats separades, així que tunelitzar el navegador pot deixar la petició real fora del túnel. El revés és igual de confús: una aplicació exclosa que crida una biblioteca compartida dins d'un procés tunelitzat encara té el trànsit pel túnel.

Les regles de destinació es trenquen en serveis compartits i en noms. Els recursos compartits de fitxers, les impressores, el DNS intern i el servidor de llicències viuen en adreces, així que un túnel d'una sola aplicació dóna accés al navegador mentre la unitat mapejada queda morta. Aquesta diferència de cobertura no és un error de cap dels dos models, però és la raó per la qual un túnel d'una sola aplicació produeix tan sovint que la VPN funciona i el recurs compartit ha desaparegut.

Els resolutors travessen tots dos. Si el client configura servidors DNS interns però el sistema operatiu fa servir DNS sobre HTTPS cap a un resolutor públic, la resposta ve de fora del túnel i la regla de destinació pot no coincidir mai. Comproveu quin resolutor ha respost realment abans de concloure que la regla és incorrecta, i confirmeu al costat del client si ha instal·lat el resolutor del túnel. Un split que deixa el DNS fora del túnel sembla perfecte a la taula d'encaminament i tot i així falla en tots els noms interns.

Pla de treball: triar, aplicar, verificar

Comenceu pel requisit, no pel menú. Si l'objectiu és només aquesta aplicació pot usar el túnel, necessiteu regles d'aplicació i una plataforma que les admeti. Si l'objectiu és aquestes xarxes són accessibles pel túnel, necessiteu prefixos. Si la resposta és les dues coses, implementeu-les com dos controls separats i anoteu quin posseeix quina fallada.

Apliqueu la forma més estreta que pugueu expressar i després verifiqueu preguntant a la taula d'encaminament en lloc de la icona d'estat del client:

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

Les dues primeres línies nomenen la interfície que faria servir una destinació real; wg show imprimeix la llista de prefixos configurada; a Windows, Find-NetRoute respon la mateixa pregunta que respondrà la pila quan s'enviï el paquet. Si la interfície és el túnel, la regla ha coincidit.

Després proveu un segon paquet que hauria de quedar exclòs, des d'una aplicació diferent, cap a la mateixa destinació. Anoteu al tiquet la versió del client, el tipus de regla, la llista de prefixos o de paquets i els dos resultats observats. Aquest parell de resultats és el que diu al següent enginyer si la política està mal configurada o si el trànsit no hi pertanyia mai.