Ruta VPN ou regra de devasa: cal está descartando o paquete?

Dúas decisións independentes ocorren sobre o mesmo paquete, e calquera delas pode rematar a petición en silencio. A consulta de encamiñamento escolle unha interface e un salto seguinte, logo o filtro de paquetes decide se esa combinación está permitida. Un tempo de espera diche que unha das dúas se negou, non cal. Percorra as etapas en orde e a reparación adoita deixar de ser unha conxectura.

Dúas decisións, un paquete, dous propietarios

A consulta de encamiñamento consulta primeiro as regras de política, despois a táboa á que apuntan, e escolle o prefixo máis específico que coincide co destino. Un cliente que instalou unha ruta de túnel posúe esa decisión, e nada nunha regra de devasa pode substituíla. Cando a consulta apunta a un lugar inesperado, cada etapa posterior traballa sobre o paquete equivocado.

O filtrado é aparte. Nunha máquina Linux, os ganchos de netfilter dividen o tráfico segundo para quen é o paquete: a saída abandona a máquina, a entrada remata nela, o reenvío pásaa. Unha pasarela que acepta clientes VPN e os encamiña a unha LAN necesita a ruta de reenvío, e é exactamente a cadea que a maioría das configuracións por defecto deixan baleira.

A selección de orixe pertence á mesma decisión, e é onde se esconden a maioría dos desaxustes. O núcleo escolle un enderezo de orixe da interface de saída a menos que a ruta nomee un, así que unha regra de filtro escrita para a subrede LAN nunca coincide cun paquete que sae co enderezo do túnel.

Lea o que a consulta escolleu realmente

Imprima a decisión en lugar de inferila. A orde seguinte resolve a ruta que o núcleo usaría para ese destino, incluíndo a interface e a orixe que escollería:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

Os clientes VPN adoitan instalar regras de política en prioridades por baixo da táboa principal, así que unha táboa principal limpa non demostra nada por si soa. Compare as prioridades das regras coas táboas que escolen, e comprobe se a ruta do túnel sobrevive a unha reconexión en lugar de engadirse á man unha vez.

O IPsec baseado en políticas engade unha terceira etapa de coincidencia que o encamiñamento non cobre, como describen as notas de reenvío de strongSwan para configuracións de túnel e transporte. A política de seguridade selecciona o tráfico por prefixo e protocolo, mentres que a ruta só decide onde iría un paquete sen protección. Unha subrede que se encamiña pero non ten selector coincidente ou ben queda desprotexida ou ben se descarta, segundo a configuración, e ningún dos dous resultados parece un problema de devasa. Imprima a política e compare os seus selectores cos prefixos que esperaba que levase o túnel.

O filtrado aplícase nun gancho, non nunha ruta

Unha regra que permite o oínte VPN é unha regra sobre o tráfico dirixido á propia pasarela. Non di nada sobre os clientes que chegan a máquinas detrás desa pasarela, porque o tráfico reenviado atravesa unha cadea distinta. Ler o conxunto de regras como unha lista plana é a razón habitual de que unha regra que parece correcta nunca se active.

Os contadores resolven a cuestión rápido. Unha regra cun reconto de paquetes cero nunca se alcanzou, o que apunta á cadea equivocada, a interface equivocada ou un descarte anterior. Unha regra cun reconto crecente baixo unha política de descarte é o límite que buscaba, e o paquete descártase en lugar de encamiñarse mal.

Envíe unha sonda polo camiño que usa o cliente

As probas executadas na propia pasarela viaxan por saída e entrada, co enderezo de orixe propio da pasarela. É un camiño distinto do da petición reenviada dun cliente, así que un curl local exitoso demostra menos do que parece. Probe desde a máquina que falla, ou fixe explicitamente a interface e a orixe.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Unha captura nos dous extremos separa os casos restantes. Un SYN que sae do cliente e nunca chega significa encamiñamento, cifrado ou unha lista de acceso augas arriba. Un SYN que chega e non obtén resposta significa o servizo ou o seu filtro de máquina, e o túnel nunca foi o problema.

O tráfico de retorno merece a súa propia ollada. O encamiñamento asimétrico máis o filtrado de ruta inversa descartan as respostas que chegan pola interface equivocada, o que se ve como unha conexión unidireccional en lugar dun porto bloqueado. Comprobe o valor de sysctl antes de culpar a devasa dun síntoma que non causou.

O rexistro funciona como unha segunda opinión, non como un primeiro paso. Unha declaración de rexistro temporal na cadea de reenvío nomea a interface e os enderezos que a golpearon, e é fácil de retirar despois. Déixea permanentemente e terá construído un problema de volume de rexistros en lugar dunha resposta.

Poña cada cambio onde sobreviva a unha reconexión

Unha ruta engadida con ip route add vive ata que a interface cae. Gárdea no perfil de conexión: NetworkManager acepta rutas adicionais na conexión, e netplan consérvaas entre arrinques. A mesma regra aplícase a unha excepción de devasa do lado do cliente, que desaparece após a seguinte recarga.

As regras do lado do servidor pertencen ao ficheiro de configuración que o servizo carga ao iniciar, non a unha sesión interactiva que remata cando a pecha. Escriba a regra, recargue e confirme que o contador se moveu, porque unha recarga que rexeitou a sintaxe deixa o conxunto de regras antigo no seu sitio en silencio.

Despois repita a petición orixinal da aplicación de principio a fin e anote que capa cambiou. Unha corrección de ruta que tamén necesitaba un cambio de filtro seguirá fallando, e o segundo fallo lese moito máis facilmente cando sabe que o primeiro desapareceu. Anote a data e a versión do cliente xunto ao resultado, xa que os valores por defecto de encamiñamento e filtrado móvense entre versións. Manteña esa nota no ticket para que a seguinte persoa comece onde vostede parou en lugar de repetir o percorrido de dúas etapas.