OpenVPN es connecta però no hi passa res: trobeu la capa on cau el paquet
Un túnel connectat sense trànsit té almenys cinc causes. Demostreu que l’oient existeix, captureu el paquet exterior i deixeu que els comptadors o una traça nomenin la regla.
OpenVPN diu connectat i no es mou cap trànsit, una frase que cobreix almenys cinc avaries no relacionades. Editar regles del tallafoc abans de saber quina capa falla multiplica els desconeguts i deixa un desori al proper enginyer. Treballeu més aviat des del procés cap enfora, perquè cada pas de sota o bé neteja una etapa o bé estreta on mor el paquet. L’ordre importa aquí: una captura feta abans de saber quina adreça està lligada demostrarà alguna cosa, però no la que necessiteu.
El sòcol o està lligat o no ho està
Un servei que informa que està actiu pot continuar lligat a una adreça o un transport que no volíeu. Consulteu el sòcol mateix: ss -lunp llista els oients UDP i ss -ltnp llista els TCP, i la columna que val la pena llegir és l’adreça local, no l’estat.
Una resposta buida normalment significa una de tres coses: el procés ha sortit després d’arrencar, ha carregat un altre fitxer de configuració, o escolta en una adreça diferent de la que es marca.
ss -lunp | grep 1194
ss -ltnp | grep 1194
Una directiva local fixa l’oient en una sola adreça, així que un client adreçat a un altre lloc del mateix amfitrió és refusat mentre el servei encara sembla sa des de fora. Un nom d’instància també pot apuntar a un fitxer que no heu editat mai, cosa que passa en amfitrions que executen dos perfils alhora.
Captureu el paquet exterior, no el túnel
Filtreu per la interfície física i el port real, amb la vostra interfície substituïda: tcpdump -ni eth0 udp port 1194. Els paquets sortints sense res que torni assenyalen el que hi ha aigües amunt: filtratge del proveïdor, un dispositiu NAT o una adreça remota que no és la que penseu. El silenci en totes dues direccions assenyala l’encaminament del client o un tallafoc local. Les respostes que arriben sense progrés del túnel assenyalen el canal de control, és a dir, una discrepància de clau o xifratge, no el filtratge.
Captureu les dues direccions i manteniu el fitxer curt. Una captura llarga enterra els tres segons interessants, i la resposta gairebé sempre és al primer intercanvi.
Primer els comptadors, traça només quan menteixen
Comenceu pels comptadors, perquè no costen res. O bé nft list ruleset o bé iptables -L -n -v respon l’única pregunta que importa aquí: ha coincidit la regla? L’ordre decideix el resultat, perquè la primera coincidència guanya, i per això un DROP ampli abans d’un ACCEPT posterior deixa aquell ACCEPT mort i per això afegir una regla tan poques vegades repara res.
La propietat també despista. El nucli atribueix els paquets generats localment al procés que va obrir el sòcol, i OpenVPN normalment s’executa com a root, així que una regla lligada a un ID d’usuari ordinari mai no veu el trànsit del propi túnel. Comproveu l’UID propietari abans de decidir que la regla és dolenta.
Només quan els comptadors segueixen ambigus val la pena el soroll d’un registre, i encara només per a una franja estreta: una regla d’iptables que limita la taxa i posa prefix a les seves línies, o una regla de nftables amb meta nftrace set 1 mentre nft monitor trace s’executa. Una traça nomena la cadena i la regla que va acceptar o va descartar el paquet. Traieu totes dues després i manteniu el registre de càrrega fora.
Comproveu també el transport. Un servei de tallafoc limitat a TCP no diu res sobre un oient UDP en aquest número, així que una regla que es llegeix correctament encara pot descartar cada paquet.
Encaminament i el camí de tornada
Un paquet acceptat que encara desapareix necessita que s’examini el camí de destí. ip route get informa de la ruta triada per a una adreça, i el filtratge de camí invers pot descartar una resposta que arriba per una interfície que la taula principal mai no triaria. El símptoma sembla exactament un descart del tallafoc, i per això aquesta comprovació va abans d’una altra regla NAT.
En una passarel·la, inspeccioneu el reenviament i la cadena forward en lloc de la cadena input. Després confirmeu que el costat llunyà sap com arribar a l’adreça d’origen, perquè un camí de sortida que funciona sense res que torni és silenci en tots dos casos.
Què ha de dir el registre
Per a cada canvi, anoteu l’etapa que heu provat, l’evidència que heu llegit i el valor del comptador a banda i banda. Aquesta nota és el que fa que "ara funciona" sobrevisqui a la propera revisió.
Dos dreceres mantenen la nota honesta. Un paquet que mai no ha sortit de l’amfitrió no pot haver estat descartat per una regla en un altre lloc, per convincent que sembli la configuració del costat llunyà. Un paquet que ha sortit i ha tornat mou la pregunta per sobre de la capa de xarxa, on els comptadors del tallafoc ja no tenen res a dir-vos.