Como bloquear a saída de Linux para que non se filtre nada cando cae a VPN

Imaxina unha caixa multimedia nunha conexión doméstica que só debería chegar a internet a través dun túnel. Cando o túnel cae, a aplicación debería deterse en lugar de continuar en silencio pola interface física. Conseguir ese comportamento é un problema de devasa e non de enrutamento, e a distinción importa porque unha ruta pódese substituír reiniciando o demo, mentres que un filtro queda onde o puseches. A continuación verás como decide realmente o camiño do paquete e despois como limitar as excepcións que manteñen o túnel reconectando.

A saída local é un gancho distinto do reenvío

Un paquete que sae dunha aplicación do equipo atravesa o gancho de saída; un paquete que o equipo enruta para outro host atravesa o reenvío. Unha política que só menciona forward restrinxe o segundo e deixa o primeiro completamente aberto, e por iso tantos bloqueos de saída parecen correctos e non fan nada. A coincidencia de interface pertence á mesma regra: oifname "tun0" accept deixa pasar o tráfico que xa se enrutou polo túnel. Enrutamento e filtrado tamén seguen sendo decisións separadas, así que pode existir unha ruta de enlace mentres o filtro rexeita o paquete. Ese separación é o mecanismo no que confías.

Unha pasarela que reenvía para outros dispositivos necesita os dous ganchos. Bloquear só a saída protexe o equipo e deixa cada cliente augas abaixo libre para filtrar.

Escribe a lista de excepcións desde o extremo cara a fóra

Comeza polo extremo do túnel: un enderezo de destino ou un conxunto pequeno aprobado, o protocolo de transporte e o porto de destino, por exemplo udp dport 1194 ip daddr 203.0.113.7 accept. Se o cliente resolve un nome de host, o intercambio DNS inicial necesita a súa propia regra limitada ao resolvedor e ao porto 53, non un permiso xeral ao enderezo dese resolvedor. Cada excepción debería nomear o motivo polo que existe. Un permiso para todo o tráfico UDP cara ao porto da VPN cobre moito máis que o único servizo autenticado que tiñas en mente.

A resolución inicial é onde adoitan podrecer os bloqueos. Un conxunto de enderezos que se refresca cun temporizador precisa un comportamento definido cando o refresco falla, e ese comportamento non pode ser abrir a conexión ata que funcione. Refresca polo túnel mentres o túnel está levantado e, doutro xeito, volve ao último extremo bo coñecido.

A administración local necesita o mesmo trato. Unha subrede de xestión non é fiable só porque os seus enderezos son privados, e unha regra que confía nela convida un segundo camiño arredor do bloqueo.

Coincidir a interface non demostra un túnel san

As regras que aceptan todo o que sae de tun0 supoñen que un paquete nesa interface veu do túnel. Os nomes de interface recréanse, e un nome non é unha identidade criptográfica. O par tamén pode ter desaparecido mentres a interface segue levantada, o que converte a regra nunha non-operación moi convincente.

O seguimento de conexións engade unha trampa relacionada. Unha regra ampla de conexións establecidas reproduce o permiso que un fluxo obtivo antes, así que unha sesión iniciada antes de que caese o túnel segue funcionando despois. Restrinxe a aceptación con estado ás interfaces e enderezos que realmente queres, ou construíches un bloqueo que se abre só. As regras de entrada e de saída tamén responden preguntas distintas, e endurecer unha ignorando a outra deixa o equipo accesible na dirección que non consideraches.

Que sobrevive a unha caída do demo

Un filtro instalado por un script que se executa despois de que suba o túnel desaparece co túnel, xusto no momento en que facía falta. Carga o bloqueo no arranque e deixa que o demo xestione só as súas excepcións.

Borrar a ruta por defecto tampouco é un substituto. A ruta é estado que o demo posúe e reescribe, e eliminala pode quitar o camiño necesario para reconectar. IPv6 necesita o seu propio plan, porque o descubrimento de veciños e os anuncios de router son servizos de enlace que deben seguir funcionando mentres o tráfico ordinario está bloqueado. DHCP pertence á mesma categoría. Anota estas cousas como excepcións cun propósito, en lugar de descubrilas despois como caídas.

Camiño de recuperación antes do despregamento

Proba o bloqueo tal como fallará: arrincar sen túnel, matar o demo, cambiar o extremo e reconectar. Cada caso debería deter as aplicacións e deixar o canal de recuperación funcionando. Faino desde unha consola, porque un shell remoto é a sesión que máis probablemente quede bloqueada pola túa propia regra.

Despois comproba a que pode chegar aínda unha aplicación corrente, cun destino inocuo e unha petición que poidas verificar. O resultado que queres é un rexeitamento no enlace e un éxito polo túnel, non un tempo de espera ambiguo que podería significar calquera das dúas cousas. Mantén o conxunto de regras baixo o mesmo propietario que o resto da devasa, en lugar de substituír toda a táboa desde un script de shell. Unha política na que cada permiso pode xustificarse vale máis que un conxunto longo de regras que ninguén sabe explicar.