Unha máquina, dous traballos, unha devasa: unha ligazón ascendente Wi-Fi, unha pequena subrede Ethernet detrás e un cliente VPN de escritorio que supón que todo o que sae do equipo é local. As aplicacións iniciadas localmente saen pola ruta de saída local. Os dispositivos detrás da estación de traballo chegan polo porto Ethernet e necesitan unha decisión de reenvío. Unha exclusión escrita para a primeira ruta nunca ve a segunda, e por iso un navegador evita o túnel mentres que os dispositivos non.

Dúas rutas de paquetes, unha política

OriginPathDecision owner
Application on the workstationOUTPUT then egressThe VPN app's routing policy
Device behind the workstationPREROUTING then FORWARDThe workstation's own forwarding policy

A primeira fila é o que describen a maioría das guías de split-tunneling. A segunda é unha configuración de encamiñador que casualmente vive na mesma máquina. Fusionalas nun só modelo mental é o erro; comparten núcleo, pero non política. Debuxa ambas as rutas antes de editar calquera regra, e o resto do deseño despréndese de cal ruta falta.

A táboa tamén explica por que unha máquina pode pasar unha proba e fallar outra. O navegador na estación de traballo demostra a ruta local; un portátil conectado ao porto Ethernet demostra a ruta de reenvío. Valida cada cambio con ambos, ou o segundo quedará sen probar por moitas veces que recargues o navegador.

Que clasifica realmente unha exclusión de aplicación

Unha exclusión por aplicación adoita funcionar marcando os paquetes dun proceso ou dun usuario e despois encamiñando o tráfico marcado fóra do túnel. Iso é unha construción de saída local. Un paquete dun dispositivo descendente non ten proceso local, así que nunca coincide co selector, sexa cal sexa o selector.

Sexa cal sexa o selector, as dúas listas non son a mesma lista, e aí está todo. A guía de Mullvad para Linux describe marcas que consome a súa devasa e a súa política de encamiñamento, e os seus exemplos apuntan á saída local; non son unha descrición admitida dun encamiñador descendente. Copialas produce unha máquina que cre ter unha exclusión mentres reenvía todo ao túnel.

Escribe o contrato de tránsito

Nomea á vez o prefixo de orixe descendente e a interface de entrada, e despois restrinxe ese prefixo na entrada. Sen a restrición, calquera dispositivo que acade o porto pode reclamar un enderezo excluído e saír pola omisión. Trátao como dúas preguntas: poden estes hosts usar esta ligazón ascendente e poden acadar a estación de traballo ou os rangos privados do túnel? Son permisos adicionais, non efectos secundarios de escoller a ligazón.

Permite o reenvío e despois filtrao. A pasarela Linux necesita o reenvío activado, regras que permitan o tráfico previsto en ambos os sentidos e, ou ben unha ruta de retorno ascendente, ou ben unha tradución de orixe deliberadamente limitada. NAT por si só non selecciona a ligazón ascendente nin concede paso por un filtro; só reescribe un enderezo despois desas decisións.

A clasificación para o tránsito debe ocorrer antes da decisión de ruta de reenvío, é dicir, na etapa de prerouting e non en output. Unha regra colocada despois da decisión aínda pode cambiar o paquete, pero non pode cambiar a onde xa se enviou.

As marcas pertencen á aplicación que as posúe

Os valores de marca, os números de táboa e as prioridades de cadea forman parte da política da aplicación VPN, non son constantes eternas. Unha rede duradeira que dependa de inserir unha regra nunha táboa que outro programa rexenera romperá na próxima actualización, normalmente durante unha reconexión e non nun momento oportuno.

Engadir unha segunda cadea base cun veredicto accept non anula necesariamente o drop dunha cadea posterior. As cadeas base teñen ganchos e prioridades, e gaña o primeiro veredicto da orde; un accept nunha cadea non cancela un drop ao que outra cadea chega antes. Mira o conxunto de regras completo e a orde da política de encamiñamento, non o único contador que se incrementou. Un contador demostra que unha regra se executou, nunca que o seu veredicto fose o aplicado.

Integra, ou move a subrede

Os dous deseños difiren en quen posúe a omisión. Un deseño integrado mantén unha máquina e unha política, a costa de depender do ciclo de vida das táboas da aplicación VPN e dun conxunto de marcas que a súa documentación pode cambiar. Un encamiñador dedicado para a rede descendente elimina esa dependencia por completo: a subrede ten a súa propia ligazón ascendente e a estación de traballo segue a ser un cliente sen papel de reenvío.

Escolle o segundo cando a rede descendente deba seguir funcionando a través de actualizacións do VPN, ou cando ninguén poida probar a política integrada tras cada versión. Escolle o primeiro só cando a integración estea documentada e alguén se faga cargo dela.

Verifica a fronteira en catro estados: conectado, reconectando, bloqueado deliberadamente e detido. Comproba a resolución de nomes e ambas as familias de enderezos en cada un, porque unha omisión que filtra DNS non é a exclusión que deseñaches. A proba debe demostrar a fronteira precisa, non só que unha páxina se cargou.

Artigos relacionados