OpenVPN verbindt, maar er stroomt niets: vind de laag waar het pakket valt

OpenVPN zegt verbonden en er beweegt geen verkeer, een zin die minstens vijf ongerelateerde fouten dekt. Firewallregels aanpassen voordat je weet welke laag faalt, vermenigvuldigt de onbekenden en laat de volgende ingenieur een puinhoop. Werk in plaats daarvan van het proces naar buiten, want elke stap hieronder ruimt ofwel een fase op of vernauwt waar het pakket sterft. De volgorde is hier belangrijk: een opname die wordt genomen voordat je weet welk adres gebonden is, bewijst iets, alleen niet wat je nodig hebt.

De socket is gebonden of niet

Een dienst die actief meldt, kan nog steeds gebonden zijn aan een adres of transport dat je nooit bedoelde. Vraag het de socket zelf: ss -lunp somt UDP-listeners op en ss -ltnp TCP, en de kolom die het lezen waard is, is het lokale adres, niet de status.

Een leeg antwoord betekent meestal een van drie dingen: het proces stopte na de start, het laadde een ander configuratiebestand, of het luistert op een ander adres dan het adres dat wordt gebeld.

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

Een local-richtlijn zet de listener vast op één adres, dus een client die elders op dezelfde host mikt, wordt geweigerd terwijl de dienst van buitenaf nog gezond lijkt. Een instantienaam kan ook naar een bestand wijzen dat je nooit hebt bewerkt, wat gebeurt op hosts die twee profielen naast elkaar draaien.

Vang het buitenste pakket, niet de tunnel

Filter op de fysieke interface en de echte poort, met je eigen interface ingevuld: tcpdump -ni eth0 udp port 1194. Uitgaande pakketten waar niets op terugkomt, wijzen op wat er boven zit: filtering door de provider, een NAT-apparaat of een extern adres dat niet het adres is dat je denkt. Stilte in beide richtingen wijst op clientrouting of een lokale firewall. Antwoorden die aankomen zonder voortgang van de tunnel wijzen op het controlekanaal, dus een sleutel- of cipherverschil, niet op filtering.

Vang beide richtingen en houd het bestand kort. Een lange opname begraaft de interessante drie seconden, en het antwoord zit bijna altijd in de eerste uitwisseling.

Eerst tellers, trace alleen als ze liegen

Begin met de tellers, want die kosten niets. Ofwel nft list ruleset ofwel iptables -L -n -v beantwoordt de enige vraag die hier telt: raakte de regel? De volgorde bepaalt de uitkomst, want de eerste overeenkomst wint, daarom laat een breed DROP vóór een latere ACCEPT die ACCEPT dood en daarom repareert het toevoegen van een regel zo zelden iets.

Eigendom laat mensen ook struikelen. De kernel schrijft lokaal gegenereerde pakketten toe aan het proces dat de socket heeft geopend, en OpenVPN draait meestal als root, dus een regel die op een gewone gebruikers-ID is gericht, ziet het verkeer van de tunnel zelf nooit. Controleer de eigenaar-UID voordat je besluit dat de regel verkeerd is.

Alleen wanneer de tellers dubbelzinnig blijven, is een log de herrie waard, en dan nog alleen voor een smalle plak: een iptables-regel die de snelheid beperkt en zijn logregels van een voorvoegsel voorziet, of een nftables-regel met meta nftrace set 1 terwijl nft monitor trace draait. Een trace noemt de keten en de regel die het pakket accepteerde of liet vallen. Verwijder daarna beide en houd payload-logging erbuiten.

Controleer ook het transport. Een firewalldienst die tot TCP beperkt is, zegt niets over een UDP-listener op dat nummer, dus een regel die correct leest, kan nog steeds elk pakket laten vallen.

Routing en de weg terug

Een geaccepteerd pakket dat toch verdwijnt, vereist onderzoek van zijn bestemmingspad. ip route get meldt de route die voor één adres is gekozen, en reverse-path-filtering kan een antwoord laten vallen dat binnenkomt via een interface die de hoofdtabel nooit zou kiezen. Het symptoom lijkt precies op een firewall-drop, daarom komt deze controle vóór nog een NAT-regel.

Op een gateway onderzoekt u forwarding en de forward-keten in plaats van de input-keten. Bevestig daarna dat de verre kant weet hoe hij het bronadres bereikt, want een werkend uitgaand pad zonder iets dat terugkomt is stilte in beide gevallen.

Wat de notitie moet zeggen

Noteer voor elke wijziging de geteste fase, het gelezen bewijs en de tellerwaarde aan beide kanten ervan. Die notitie is wat "het werkt nu" bij de volgende beoordeling laat overleven.

Twee snelkoppelingen houden de notitie eerlijk. Een pakket dat de host nooit verliet, kan niet door een regel elders zijn gedropt, hoe overtuigend de configuratie van de verre kant er ook uitziet. Een pakket dat eruit ging en terugkwam, verplaatst de vraag boven de netwerklaag, waar firewaltellers niets meer hebben om u te vertellen.