OpenVPN conéctase pero non pasa nada: atope a capa onde cae o paquete

OpenVPN di conectado e non se move tráfico, unha frase que cobre polo menos cinco fallos non relacionados. Editar regras da devasa antes de saber que capa falla multiplica os descoñecidos e déixalle un desastre ao seguinte enxeñeiro. Traballa mellor desde o proceso cara a fóra, porque cada paso de abaixo ou despexa unha etapa ou estreita onde morre o paquete. A orde importa aquí: unha captura tomada antes de saber que enderezo está ligado demostrará algo, pero non o que vostede necesita.

O socket está ligado ou non o está

Un servizo que informa de que está activo pode seguir ligado a un enderezo ou un transporte que nunca pretendeu. Consulte o propio socket: ss -lunp lista os receptores UDP e ss -ltnp os TCP, e a columna que paga a pena ler é o enderezo local, non o estado.

Unha resposta baleira adoita significar unha de tres cousas: o proceso saíu tras arrancar, cargou outro ficheiro de configuración, ou escoita nun enderezo distinto do que se marca.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Unha directiva local fixa o receptor a un só enderezo, así que un cliente dirixido a outro lugar do mesmo equipo é rexeitado mentres o servizo desde fóra segue parecendo san. Un nome de instancia tamén pode apuntar a un ficheiro que nunca editou, o que ocorre en equipos que executan dous perfís á vez.

Capture o paquete exterior, non o túnel

Filtre na interface física e no porto real, coa súa propia interface substituída: tcpdump -ni eth0 udp port 1194. Os paquetes saíntes sen nada que volva apuntan ao que está augas arriba: filtrado do provedor, un dispositivo NAT ou un enderezo remoto que non é o que vostede cre. O silencio en ambas direccións apunta ao encamiñamento do cliente ou a unha devasa local. As respostas que chegan sen avance do túnel apuntan á canle de control, é dicir, a unha discrepancia de clave ou cifrado, non ao filtrado.

Capture ambas direccións e manteña o ficheiro curto. Unha captura longa entérra os tres segundos interesantes, e a resposta case sempre está no primeiro intercambio.

Primeiro os contadores, traza só cando menten

Comece polos contadores, porque non custan nada. Ou ben nft list ruleset ou ben iptables -L -n -v responde a única pregunta que importa aquí: coincidiu a regra? A orde decide o resultado, porque a primeira coincidencia gaña, por iso un DROP amplo antes dun ACCEPT posterior deixa ese ACCEPT morto e por iso engadir unha regra tan poucas veces repara algo.

A propiedade tamén fai tropezar. O núcleo atribúe os paquetes xerados localmente ao proceso que abriu o socket, e OpenVPN normalmente execútase como root, así que unha regra ligada a un ID de usuario corrente nunca ve o tráfico do propio túnel. Comprobe o UID propietario antes de decidir que a regra está mal.

Só cando os contadores seguen ambiguos paga a pena o ruído dun rexistro, e aínda así só para unha franxa estreita: unha regra de iptables que limita a taxa e pon prefixo ás súas liñas, ou unha regra de nftables con meta nftrace set 1 mentres nft monitor trace se executa. Unha traza nomea a cadea e a regra que aceptou ou descartou o paquete. Retire ambas despois e manteña o rexistro de carga fóra.

Comprobe tamén o transporte. Un servizo de devasa limitado a TCP non di nada sobre un receptor UDP nese número, así que unha regra que se le correctamente aínda pode descartar cada paquete.

Encamiñamento e o camiño de volta

Un paquete aceptado que aínda desaparece necesita que se examine o seu camiño de destino. ip route get informa da ruta elixida para un enderezo, e o filtrado de ruta inversa pode descartar unha resposta que chega por unha interface que a táboa principal nunca elixiría. O síntoma parece exactamente un descarte da devasa, por iso esta comprobación vai antes doutra regra NAT.

Nunha pasarela, inspeccione o reenvío e a cadea forward en lugar da cadea input. Logo confirme que o lado remoto sabe como chegar ao enderezo de orixe, porque un camiño de saída que funciona sen nada que volva é silencio en ambos casos.

Que debe dicir o rexistro

Para cada cambio, anote a etapa que probou, a evidencia que leu e o valor do contador a ambos lados. Esa nota é o que fai que "agora funciona" sobreviva á seguinte revisión.

Dous atallos manteñen a nota honesta. Un paquete que nunca saíu do equipo non puido ser descartado por unha regra noutro lugar, por convincente que pareza a configuración do lado remoto. Un paquete que saíu e volveu move a pregunta por riba da capa de rede, onde os contadores da devasa xa non teñen nada que dicirlle.