Com decide el túnel dividit quin trànsit fa servir la VPN

El túnel dividit és una política d'encaminament expressada com un conjunt de regles, i el client només és allò que les instal·la. La separació es produeix en dos llocs: regles de correspondència que trien un camí per a cada paquet, i enllaços que fixen una aplicació a una interfície digui el que digui la taula. En quin mecanisme es basa el vostre client explica la majoria de les sorpreses que la gent assenyala.

Una política que podeu enunciar en una línia és comprovable. Una política descrita com a navegació més ràpida no ho és, i no us dirà quina regla cal canviar quan una sol·licitud va pel camí equivocat.

El client instal·la regles, el nucli fa l'elecció

Quan el túnel s'aixeca, el client afegeix rutes i sovint regles de política a la mateixa taula que fan servir les altres interfícies. Llavors cada paquet arriba a una consulta que compara la seva destinació amb cada prefix candidat i es queda amb la coincidència més específica, mentre que la prioritat resol els empats entre regles que apunten a taules diferents. Res en aquesta consulta sap que el paquet ve d'una pestanya del navegador i no d'una tasca de còpia de seguretat. La regla que guanya és la que fixa el camí, i la podeu llegir abans i després del canvi.

Per això un túnel dividit pot semblar arbitrari. Dues destinacions en una mateixa aplicació poden seguir camins diferents només perquè un prefix és més estret que l'altre.

La mateixa elecció existeix a cada plataforma, tot i que els noms canvien. Windows empeny la decisió cap a la seva plataforma de filtres, Android exposa una llista blanca per aplicació a través del seu servei VPN, i macOS enllaça el túnel a un dispositiu que encara obeeix la taula d'encaminament. Les notes d'encaminament de Microsoft valen la pena per al cas de Windows, i una guia escrita per a una plataforma poques vegades es trasllada sense canvis a una altra.

L'enllaç per aplicació i els prefixos de destinació són eines diferents

Una política de destinació pregunta on va el paquet i consulta la taula de rutes o una regla de política. Una política per aplicació pregunta quin programa ha obert el sòcol, i la plataforma manté aquest programa a la interfície del túnel fins i tot quan una ruta més específica apunta a un altre lloc. La segona és més forta perquè sobreviu als canvis de taula, però només cobreix els processos que la plataforma pot atribuir. Un procés auxiliar, un navegador incrustat o un servei que obre la seva pròpia connexió potser no hereten l'enllaç que havíeu suposat.

Cap dels dos enfocaments sobreviu a una política basada en noms sense ajuda. Les adreces dels llocs grans giren entre xarxes de contingut, així que fixar un nom d'amfitrió a uns quants prefixos produeix una regla que deixa de coincidir en silenci. Una política que ha de seguir noms necessita un component conscient del resoledor en lloc d'una ruta estàtica.

El DNS i l'interruptor de seguretat segueixen les seves pròpies regles

La resolució de noms és una decisió separada de l'encaminament de paquets, i un túnel dividit normalment vol dos resoledors: el de l'empresa per als noms interns, el local per a tot la resta. El client pot instal·lar paràmetres DNS per interfície, passar les consultes a un resoledor intermedi o deixar el valor per defecte del sistema intacte. Un navegador amb el seu propi resoledor xifrat evita les tres disposicions. Proveu una consulta en lloc de suposar que el resoledor ha seguit la ruta.

Un interruptor de seguretat hi afegeix un filtre a sobre, i aquest filtre no sempre distingeix una exclusió volguda d'una fuita accidental. Alguns clients ho bloquegen tot fora del túnel mentre que altres permeten les exclusions que la política declara, així que llegiu quin comportament implementa el vostre abans de confiar en cap dels dos.

Comproveu la divisió des de tots dos costats

Proveu el camí inclòs i el camí exclòs per separat, i jutgeu el resultat pel nom de la interfície i no per una adreça pública. Aquestes ordres pressuposen un amfitrió Linux amb el dispositiu de túnel ja aixecat. Substituïu 203.0.113.10 per una destinació que la vostra política encamini cap a dins, i 198.51.100.25 per una que enviï cap a fora.

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'

Llegiu les dues primeres respostes juntes, perquè la interfície que s'anomena a cadascuna mostra si la divisió ha posat aquella destinació al túnel. La consulta al resoledor mostra quin servidor ha respost al nom intern, i l'última ordre demostra que el dispositiu de túnel pot portar una sol·licitud. Un fracàs a la segona línia mentre la primera té èxit vol dir que la política fa exactament el que se li ha dit.

Repetiu el conjunt després d'una reconnexió i després d'un canvi de xarxa. La renovació del lloguer i el moviment de les interfícies són on una divisió deixa de coincidir amb la intenció per a la qual es va construir, i una sortida desada de cada execució fa evident la deriva.