OpenVPN verbind, maar niks vloei nie: vind die laag waar die pakket val

OpenVPN sê verbind en geen verkeer beweeg nie, ’n sin wat ten minste vyf onverwante foute dek. Om firewall-reëls te redigeer voordat jy weet watter laag faal, vermenigvuldig die onbekendes en laat die volgende ingenieur ’n gemors. Werk eerder van die proses af uitwaarts, want elke stap hieronder maak een stadium skoon of vernou waar die pakket sterf. Orde maak hier saak: ’n opname wat geneem is voordat jy weet watter adres gebind is, sal iets bewys, net nie die ding wat jy nodig het nie.

Die socket is óf gebind óf nie

’n Diens wat aktief rapporteer, kan steeds aan ’n adres of ’n transport gebind wees wat jy nooit bedoel het nie. Ondersoek die socket self: ss -lunp lys UDP-luisteraars en ss -ltnp lys TCP’s, en die kolom wat die moeite werd is om te lees, is die plaaslike adres, nie die toestand nie.

’n Leë antwoord beteken gewoonlik een van drie dinge: die proses het ná die begin beëindig, dit het ’n ander konfigurasielêer gelaai, of dit luister op ’n ander adres as dié waarna geskakel word.

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

’n local-richtlijn pen die luisteraar aan een adres vas, so ’n kliënt wat elders op dieselfde gasheer mik, word geweier terwyl die diens van buite steeds gesond lyk. ’n Gevalnaam kan ook na ’n lêer wys wat jy nooit geredigeer het nie, wat op gashere gebeur wat twee profiele langs mekaar bedryf.

Vang die buitenste pakket, nie die tonnel nie

Filtreer op die fisiese koppelvlak en die werklike poort, met jou eie koppelvlak ingevul: tcpdump -ni eth0 udp port 1194. Uitgaande pakkette sonder enigiets wat terugkom, wys op wat stroomop sit: verskafferfiltering, ’n NAT-toestel, of ’n afgeleë adres wat nie die een is wat jy dink nie. Stilte in beide rigtings wys op kliëntroetering of ’n plaaslike firewall. Antwoorde wat aankom sonder tonnelvordering wys op die beheerkanaal, dit wil sê ’n verkeerde sleutel of syfer, nie op filtering nie.

Vang beide rigtings en hou die lêer kort. ’n Lang opname begrawe die interessante drie sekondes, en die antwoord sit byna altyd in die eerste uitruiling.

Eers tellers, spoor eers wanneer hulle lieg

Begin met die tellers, want hulle kos niks. Óf nft list ruleset óf iptables -L -n -v beantwoord die enigste vraag wat hier saak maak: het die reël gepas? Orde beslis die uitkoms, want die eerste ooreenkoms wen, en daarom laat ’n breë DROP voor ’n latere ACCEPT daardie ACCEPT dood, en daarom herstel die byvoeg van ’n reël so selde enigiets.

Eienaarskap laat mense ook struikel. Die kernel skryf plaaslik gegenereerde pakkette toe aan watter proses ook al die socket oopgemaak het, en OpenVPN loop gewoonlik as root, so ’n reël wat op ’n gewone gebruikers-ID gemik is, sien nooit die tonnel se eie verkeer nie. Kontroleer die eienaar-UID voordat jy besluit die reël is verkeerd.

Slegs wanneer die tellers dubbelsinnig bly, is ’n log die geraas werd, en dan net vir ’n smal sny: ’n iptables-reël wat tempo beperk en sy loglyne van ’n voorvoegsel voorsien, of ’n nftables-reël met meta nftrace set 1 terwyl nft monitor trace loop. ’n Spoor noem die ketting en die reël wat die pakket aanvaar of laat val het. Verwyder albei daarna en hou nuttige-vrag-logging daar buite.

Kontroleer ook die transport. ’n Firewall-diens wat op TCP gemik is, sê niks oor ’n UDP-luisteraar op daardie nommer nie, so ’n reël wat korrek lees, kan steeds elke pakket laat val.

Roetering en die pad terug

’n Aanvaarde pakket wat steeds verdwyn, se bestemmingspad moet ondersoek word. ip route get rapporteer die roete wat vir een adres gekies is, en omgekeerde-pad-filtering kan ’n antwoord laat val wat oor ’n koppelvlak aankom wat die hoof-tabel nooit sou kies nie. Die simptoom lyk presies soos ’n firewall-lating, en daarom kom hierdie kontrole voor nog ’n NAT-reël.

Op ’n gateway, ondersoek aanstuur en die forward-ketting eerder as die input-ketting. Bevestig dan dat die ander kant weet hoe om die bronadres te bereik, want ’n werkende uitgaande pad met niks wat terugkom, is in beide gevalle stilte.

Wat die rekord moet sê

Vir elke verandering, noteer die stadium wat jy getoets het, die bewyse wat jy gelees het en die tellerwaarde aan beide kante daarvan. Daardie nota is wat "dit werk nou" die volgende hersiening laat oorleef.

Twee kortpaaie hou die nota eerlik. ’n Pakket wat nooit die gasheer verlaat het nie, kon nie deur ’n reël elders laat val gewees het nie, hoe oortuigend die ander kant se konfigurasie ook al lyk. ’n Pakket wat vertrek het en teruggekeer het, skuif die vraag bo die netwerklaag, waar firewall-tellers niks meer het om jou te sê nie.