OpenVPN ansluter men ingenting flödar: hitta lagret där paketet faller

OpenVPN säger anslutet och ingen trafik rör sig, en mening som täcker minst fem orelaterade fel. Att redigera brandväggsregler innan du vet vilket lager som fallerar multiplicerar det okända och lämnar nästa ingenjör en röra. Arbeta i stället utåt från processen, eftersom varje steg nedan antingen rensar ett stadium eller snävar in var paketet dör. Ordningen spelar roll här: en avlyssning som tas innan du vet vilken adress som är bunden bevisar något, bara inte det du behöver.

Socketen är antingen bunden eller inte

En tjänst som rapporterar aktiv kan fortfarande vara bunden till en adress eller en transport som du aldrig avsåg. Fråga socketen själv: ss -lunp listar UDP-lyssnare och ss -ltnp listar TCP, och kolumnen som är värd att läsa är den lokala adressen, inte tillståndet.

Ett tomt svar betyder vanligtvis en av tre saker: processen avslutades efter start, den laddade en annan konfigurationsfil, eller den lyssnar på en annan adress än den som rings.

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

Ett local-direktiv fäster lyssnaren vid en enda adress, så en klient som siktar någon annanstans på samma värd avvisas medan tjänsten utifrån fortfarande ser frisk ut. Ett instansnamn kan också peka på en fil du aldrig har redigerat, vilket händer på värdar som kör två profiler sida vid sida.

Fånga det yttre paketet, inte tunneln

Filtrera på det fysiska gränssnittet och den riktiga porten, med ditt eget gränssnitt insatt: tcpdump -ni eth0 udp port 1194. Utgående paket utan något som kommer tillbaka pekar på det som sitter ovanför: leverantörsfiltrering, en NAT-enhet eller en fjärradress som inte är den du tror. Tystnad i båda riktningarna pekar på klientroutning eller en lokal brandvägg. Svar som anländer utan tunnelns framdrift pekar på kontrollkanalen, alltså en nyckel- eller chifferavvikelse, inte på filtrering.

Fånga båda riktningarna och håll filen kort. En lång avlyssning begraver de intressanta tre sekunderna, och svaret ligger nästan alltid i det första utbytet.

Räknare först, spår bara när de ljuger

Börja med räknarna, eftersom de inte kostar något. Antingen nft list ruleset eller iptables -L -n -v svarar på den enda frågan som spelar roll här: träffade regeln? Ordningen avgör resultatet, eftersom den första träffen vinner, därför lämnar ett brett DROP före en senare ACCEPT den ACCEPT död och därför reparerar det sällan något att lägga till en regel.

Ägandeskap snubblar också folk. Kärnan tillskriver lokalt genererade paket processen som öppnade socketen, och OpenVPN kör vanligtvis som root, så en regel bunden till ett vanligt användar-ID ser aldrig tunnelns egen trafik. Kontrollera den ägande UID:n innan du bestämmer att regeln är fel.

Bara när räknarna förblir tvetydiga är en logg värd oljudet, och då bara för en smal skiva: en iptables-regel som hastighetsbegränsar och sätter prefix på sina loggrader, eller en nftables-regel med meta nftrace set 1 medan nft monitor trace körs. Ett spår namnger kedjan och regeln som accepterade eller släppte paketet. Ta bort båda efteråt och håll nyttolastsloggning utanför.

Kontrollera transporten också. En brandväggstjänst begränsad till TCP säger ingenting om en UDP-lyssnare på det numret, så en regel som läses korrekt kan fortfarande släppa varje paket.

Routning och vägen tillbaka

Ett accepterat paket som ändå försvinner kräver att dess destinationsväg undersöks. ip route get rapporterar rutten som valts för en adress, och omvänd väg-filtrering kan släppa ett svar som anländer över ett gränssnitt som huvudtabellen aldrig skulle välja. Symtomet ser exakt ut som en brandväggs-släpp, därför kommer den här kontrollen före ännu en NAT-regel.

På en gateway, granska vidarebefordran och forward-kedjan i stället för input-kedjan. Bekräfta sedan att fjärrsidan vet hur den når källadressen, eftersom en fungerande utgående väg utan något som kommer tillbaka är tystnad i båda fallen.

Vad anteckningen måste säga

För varje ändring, notera stadiet du testade, beviset du läste och räknarvärdet på båda sidor om det. Den anteckningen är det som gör "det fungerar nu" överlevnadsdugligt vid nästa genomgång.

Två genvägar håller anteckningen ärlig. Ett paket som aldrig lämnade värden kan inte ha släppts av en regel någon annanstans, hur övertygande fjärrsidans konfiguration än ser ut. Ett paket som gick ut och kom tillbaka flyttar frågan ovanför nätverkslagret, där brandväggens räknare inte har mer att säga dig.