Subxarxa descendent enfront del VPN d'escriptori: exclou el trànsit, no les aplicacions

Una màquina, dues feines, un tallafoc: un enllaç ascendent Wi-Fi, una petita subxarxa Ethernet al darrere i un client VPN d'escriptori que assumeix que tot el que surt de la màquina és local. Les aplicacions iniciades localment surten pel camí de sortida local. Els dispositius darrere de l'estació de treball arriben pel port Ethernet i necessiten una decisió de reenviament. Una exclusió escrita per al primer camí mai no veu el segon, i per això un navegador evita el túnel mentre que els dispositius no ho fan.

Dos camins de paquets, una política

La primera fila és el que descriuen la majoria de guies de split-tunneling. La segona és una configuració d'encaminador que casualment viu a la mateixa màquina. Fusionar-les en un sol model mental és l'error; comparteixen nucli, però no política. Dibuixa tots dos camins abans d'editar qualsevol regla, i la resta del disseny es desprèn de quin camí falta.

La taula també explica per què una màquina pot superar una prova i fallar-ne una altra. El navegador de l'estació de treball demostra el camí local; un portàtil connectat al port Ethernet demostra el camí de reenviament. Valida cada canvi amb tots dos, o el segon quedarà sense provar per moltes vegades que refresquis el navegador.

Què classifica realment una exclusió d'aplicació

Una exclusió per aplicació normalment funciona marcant els paquets d'un procés o d'un usuari, i després encaminant el trànsit marcat fora del túnel. Això és una construcció de sortida local. Un paquet d'un dispositiu descendent no té cap procés local, així que mai no coincideix amb el selector, sigui quin sigui el selector.

Sigui quin sigui el selector, les dues llistes no són la mateixa llista, i aquest és el punt. La guia de Mullvad per a Linux descriu marques consumides pel seu tallafoc i la seva política d'encaminament, i els seus exemples apunten a la sortida local; no són una descripció admesa d'un encaminador descendent. Copiar-les produeix una màquina que creu tenir una exclusió mentre reenvia tot al túnel.

Escriu el contracte de trànsit

Anomena alhora el prefix d'origen descendent i la interfície d'entrada, i després restringeix aquell prefix a l'entrada. Sense la restricció, qualsevol dispositiu que pugui arribar al port pot reclamar una adreça exclosa i sortir per l'elusió. Tracta-ho com dues preguntes: poden aquests hosts utilitzar aquest enllaç ascendent, i poden arribar a l'estació de treball o als rangs privats del túnel? Són permisos addicionals, no efectes secundaris de triar l'enllaç.

Permet el reenviament i després filtra'l. La passarel·la Linux necessita el reenviament activat, regles que permetin el trànsit previst en tots dos sentits i, o bé una ruta de tornada ascendent, o bé una traducció d'origen deliberadament limitada. NAT per si sol no selecciona l'enllaç ascendent ni concedeix pas per un filtre; només reescriu una adreça després d'aquelles decisions.

La classificació per al trànsit ha de passar abans de la decisió de ruta de reenviament, cosa que vol dir a l'etapa de prerouting i no a output. Una regla col·locada després de la decisió encara pot canviar el paquet, però no pot canviar on ja s'ha enviat.

Les marques pertanyen a l'aplicació que les posseeix

Els valors de marca, els números de taula i les prioritats de cadena formen part de la política de l'aplicació VPN, no són constants eternes. Una xarxa duradora que depèn d'inserir una regla en una taula que un altre programa regenera es trencarà a la propera actualització, normalment durant una reconnexió i no en un moment convenient.

Afegir una segona cadena base amb un veredicte accept no necessàriament anul·la el drop d'una cadena posterior. Les cadenes base tenen ganxos i prioritats, i el primer veredicte de l'ordre guanya; un accept en una cadena no cancel·la un drop al qual una altra cadena arriba abans. Mira el conjunt de regles complet i l'ordre de la política d'encaminament, no el comptador únic que s'ha incrementat. Un comptador demostra que una regla s'ha executat, mai que el seu veredicte fos el que s'aplicava.

Integra, o mou la subxarxa

Els dos dissenys difereixen en qui posseeix l'elusió. Un disseny integrat manté una màquina i una política, a costa de dependre del cicle de vida de les taules de l'aplicació VPN i d'un conjunt de marques que la seva documentació pot canviar. Un encaminador dedicat per a la xarxa descendent elimina aquesta dependència del tot: la subxarxa té el seu propi enllaç ascendent i l'estació de treball continua sent un client sense paper de reenviament.

Tria el segon quan la xarxa descendent hagi de continuar funcionant a través d'actualitzacions del VPN, o quan ningú no pugui provar la política integrada després de cada versió. Tria el primer només quan la integració estigui documentada i algú se'n faci càrrec.

Verifica la frontera en quatre estats: connectat, reconnectant, bloquejat deliberadament i aturat. Comprova la resolució de noms i les dues famílies d'adreces en cada estat, perquè una elusió que filtra DNS no és l'exclusió que has dissenyat. La prova ha de demostrar la frontera precisa, no només que una pàgina s'ha carregat.