VPN conectada pero o cortalumes segue bloqueando: como saber cal

O túnel está activo e un porto segue fallando. Le o camiño, despois a política en cada capa, e cambia a regra máis estreita en lugar de desactivar calquera dos dous controis.

O cliente di conectado, o recurso segue rexeitando, e o seguinte paso habitual é desactivar algo. Os dous controis desa frase fan traballos distintos: a VPN constrúe un camiño para o tráfico cuberto, e un cortalumes decide por conexión se o tráfico pode pasar. Un túnel que funciona cunha política que rexeita vese exactamente como un túnel roto desde a cadeira do usuario, así que a tarefa é descubrir que capa responde. Esta é a orde que sigo, coa lectura que che di que pares.

Separa o camiño da política

Comeza pola forma do fallo, porque é información gratis. Unha caída de paquete produce un tempo de espera: o cliente reintenta, non volve nada e o comando colga ata render. Un rexeitamento produce unha negativa ou un reinicio: algo respondeu e dixo que non. Un servizo que non escoita rexeita no propio host, sen ningún cortalumes polo medio.

Eses tres resultados apuntan a capas distintas. O tempo de espera significa que algunha política nalgún lugar descarta en silencio, ou que a ruta nunca sae da máquina. Rexeitado significa que chegaches ao host e a súa pila ou o seu cortalumes local dixo que non. Silencio total, coa interface do túnel activa e sen ruta ao destino, significa que o camiño está mal e ningunha regra de cortalumes o arranxará.

Le o camiño dunha pasada

Confirma que o túnel cobre o destino antes de mirar unha soa regra. Un túnel dividido que só leva a subrede da oficina non encamiñará unha petición a outro rango, e entón o fallo parece un bloqueo do cortalumes que non o é:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

A saída da ruta nomea a interface pola que sairá o paquete e o enderezo de orixe que levará. Se esa interface é a túa tarxeta de rede física e non o túnel, o problema é de encamiñamento ou dos rangos permitidos do túnel, e pertence á configuración da VPN e non ao cortalumes.

Unha trampa específica da VPN merece a súa propia comprobación. En WireGuard, AllowedIPs dun par é á vez unha ruta e un filtro criptográfico: un paquete cuxo enderezo de orixe non coincide co conxunto permitido do par descártase antes de consultar ningunha regra de cortalumes. Así, un cortalumes local perfectamente correcto pode estar detrás dun descarte silencioso que parece unha política, e o arranxo é unha liña de configuración da chave e non unha regra.

Le a política na capa que responde

Cando o camiño é correcto, percorre a política desde o host cara a fóra e observa a única capa cuxos contadores se moven:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

O socket que escoita responde unha pregunta distinta da das regras. Se nada escoita no porto, o núcleo rexeita a conexión e ningunha regra de entrada é relevante. Se o socket existe e a conexión desde un cliente remoto expira, está a producirse un descarte nalgún punto do camiño, e os contadores das regras dinche se ocorre aquí.

Activa o rexistro do perfil ou da cadea que sospeitas en lugar de adiviñar desde fóra. Un só descarte rexistrado que nomea a orixe, o destino e o porto identifica a capa e a regra, e ademais demostra que o paquete chegou, algo que ningunha proba do lado do cliente pode establecer.

Le a decisión da pasarela cando o túnel remata alí

Nunha pasarela sitio a sitio ou de acceso remoto, a VPN autentica un usuario e a política autoriza un recurso, e esas son concesións separadas. Un usuario admitido no túnel non está admitido automaticamente en cada host interno, e o rexeitamento adoita vir dunha regra de reenvío mentres o túnel mesmo está san. A mesma separación aparece en IPsec, onde a política de seguridade que selecciona o tráfico é distinta do filtro que o admite, e por iso ambos se documentan como mecanismos diferentes en RFC 4301.

Comproba o camiño de volta co mesmo coidado que o de ida. O filtrado con estado necesita ver a resposta, así que o encamiñamento asimétrico polo túnel nunha dirección e arredor del na outra produce descartes que parecen aleatorios e só se reproducen desde algúns clientes. Se o tráfico chega á pasarela e se detén, le a regra de reenvío e a ruta de volta xuntas antes de ampliar nada.

A pasarela é tamén onde unha regra de NAT ou de enmascaramento pode ocultar a orixe real. Se os hosts internos ven o enderezo da pasarela en lugar do cliente, as súas regras de cortalumes local que deben coincidir co grupo de clientes nunca coincidirán, e o arranxo pertence á pasarela e non a cada servidor.

Cambia a capa máis estreita e logo verifica

Resiste a reparación ampla. Desactivar o cortalumes local, engadir unha regra que o permita todo ou forzar cada interface a un perfil de confianza elimina en cada caso o control que facía o seu traballo, e o cambio sobrevive ao incidente. Unha regra limitada ao rango de orixe e ao porto en cuestión é máis fácil de revisar, máis fácil de quitar e deixa o resto da política da máquina intacta.

Verifica coa mesma proba que fallou, desde o mesmo cliente, e logo unha vez máis tras reconectar, porque unha regra que coincide antes de que o túnel renegocie pode deixar de coincidir despois:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Antes de pechalo:

  • A ruta ao destino sae pola interface do túnel, e o enderezo de orixe coincide co que espera a política.
  • Algo escoita no porto, e a negativa ou o tempo de espera atribúese a unha regra nomeada en lugar de supoñerse.
  • A pasarela reenvía en ambos os sentidos, e o destino ve a orixe para a que se escribiron as túas regras.
  • Ningún control se desactivou para que a proba pasase, e o cambio que fixeches nomea un só rango de orixe e un só porto.

Artigos relacionados