Un devasador da distribución Linux pode bloquear o teu tráfico VPN

O túnel levanta, o rexistro di conectado e unha aplicación segue sen alcanzar nada. Nun cliente Linux iso adoita significar que o devasador da distribución filtra unha ruta que o cliente VPN nunca xestionou. Dous xestores poden estar activos á vez, cada un coas súas ideas sobre a interface, a zona e a dirección do tráfico. Identificar o propietario antes de tocar nada é máis rápido que probar regras ata que algo funcione.

Atopa o xestor e o backend

Comeza polo que está realmente cargado, non polo que está instalado. Unha distribución pode incluír firewalld, ufw e un servizo nftables sinxelo, e só un deles posúe o conxunto de regras en execución. Os paquetes conviven tranquilamente, e unha regra introducida polo frontend equivocado nunca chega ao núcleo. Le o servizo activo e despois le o conxunto de regras que produciu.

O backend importa tanto como o frontend. Unha instalación de firewalld pode impulsar nftables ou o backend iptables antigo segundo a versión e a configuración, e ambos producen unha saída de inspección distinta. Escribe a distribución, a versión e o backend no ticket antes de comparar o teu sistema con calquera guía.

Axusta a dirección e a interface

Unha solicitude saínte do cliente, un receptor entrante e un paquete reenviado atravesan ganchos diferentes, e unha regra para un non cobre os demais. Unha zona que permite a LAN local a miúdo non inclúe a interface do túnel nin o conxunto de enderezos da VPN. A interface do túnel adoita aterrar na zona predeterminada, que con frecuencia é máis estrita que a zona do adaptador físico. Esa discrepancia explica por que a navegación funciona na LAN e detense no momento en que sobe o túnel.

Pregunta que dirección fallou antes de escoller unha regra. Unha aplicación que non pode conectar cara a fóra necesita a ruta de saída, mentres que un servizo entrante necesita a ruta de entrada na interface do túnel. Engadir unha regra á cadea equivocada produce un cambio que parece aplicado e non fai absolutamente nada.

Mantén de acordo os propietarios das regras

O gancho dun cliente VPN, un contorno de execución de contedores e o servizo da distribución poden modificar a rede, e non se coordinan entre si. As regras introducidas a man desaparecen na seguinte recarga, e as regras inseridas na cadea dun xestor poden avaliarse nunha orde que non pretendías. Usa a configuración persistente do xestor e inspecciona o conxunto de regras resultante en lugar do ficheiro que escribiches. Desactivar todo o devasador porque un servizo non é accesible cambia un problema pequeno por un grande.

Os contadores estreitos son a forma barata de atopar o fluxo rexeitado. Unha regra de rexistro limitada a un destino e un porto mostra se o descarte ocorre localmente sen capturar o tráfico de ninguén máis. Elimina a regra de rexistro cando remate a investigación, porque é un diagnóstico e non unha política, e a documentación de zonas de firewalld explica como se combinan interfaces e servizos.

Comproba a corrección sen perder o bloqueo

Inspecciona o estado aplicado co xestor que o posúe, usando ordes que coincidan co backend que rexistraches. A lista seguinte asume que manda firewalld; substitúea polo equivalente de nftables ou ufw en lugar de executalas todas. Mesturar ferramentas nunha sesión é como unha máquina acaba con dous conxuntos de regras en conflito.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

A primeira orde nomea as zonas e as interfaces asignadas, o que mostra onde aterrou realmente o túnel. A segunda imprime as regras e servizos dunha zona, de xeito que podes ver se a interface VPN está cuberta. A lista de nftables é a verdade fundamental do backend en uso, e unha regra que só existe nun ficheiro de configuración non aparece alí. Compara as tres saídas coa regra que engadiches, e a discrepancia adoita nomearse soa.

Despois repite a solicitude orixinal e o comportamento de fallo que esixes. Un sitio que acaba de funcionar non abonda se o mesmo cambio eliminou o bloqueo do cliente, así que proba tamén unha ruta sen protección. Rexistra o xestor, o backend, a interface e o propósito da regra, porque unha actualización de paquete que reviva un segundo xestor reconstruirá todo o desastre.