OpenVPN kobler til, men ingenting flyter: finn laget der pakken faller

OpenVPN sier tilkoblet og ingen trafikk beveger seg, en setning som dekker minst fem urelaterte feil. Å redigere brannmurregler før du vet hvilket lag som svikter multipliserer det ukjente og etterlater neste ingeniør et rot. Arbeid i stedet utover fra prosessen, fordi hvert trinn nedenfor enten rydder ett stadium eller snevrer inn hvor pakken dør. Rekkefølgen betyr noe her: et opptak tatt før du vet hvilken adresse som er bundet vil bevise noe, bare ikke det du trenger.

Sokkelen er enten bundet eller ikke

En tjeneste som rapporterer aktiv kan fortsatt være bundet til en adresse eller en transport du aldri mente. Spør sokkelen selv: ss -lunp lister UDP-lyttere og ss -ltnp lister TCP, og kolonnen som er verdt å lese er den lokale adressen, ikke tilstanden.

Et tomt svar betyr vanligvis en av tre ting: prosessen avsluttet etter start, den lastet en annen konfigurasjonsfil, eller den lytter på en annen adresse enn den som ringes.

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

En local-direktiv fester lytteren til én adresse, så en klient som sikter et annet sted på samme vert blir avvist mens tjenesten utenfra fortsatt ser sunn ut. Et instansnavn kan også peke på en fil du aldri har redigert, noe som skjer på verter som kjører to profiler side om side.

Fang den ytre pakken, ikke tunnelen

Filtrer på det fysiske grensesnittet og den virkelige porten, med ditt eget grensesnitt satt inn: tcpdump -ni eth0 udp port 1194. Utgående pakker uten noe som kommer tilbake peker på det som sitter ovenfor: leverandørfiltrering, en NAT-enhet eller en ekstern adresse som ikke er den du tror. Stillhet i begge retninger peker på klientrutting eller en lokal brannmur. Svar som ankommer uten tunnel-fremdrift peker på kontrollkanalen, altså en nøkkel- eller chiffer-avvik, ikke på filtrering.

Fang begge retninger og hold filen kort. Et langt opptak begraver de interessante tre sekundene, og svaret ligger nesten alltid i den første utvekslingen.

Tellere først, spor bare når de lyver

Begynn med tellerne, fordi de ikke koster noe. Enten nft list ruleset eller iptables -L -n -v svarer på det eneste spørsmålet som betyr noe her: traff regelen? Rekkefølgen avgjør resultatet, fordi det første treffet vinner, derfor lar et bredt DROP før en senere ACCEPT den ACCEPT-en være død, og derfor reparerer det sjelden noe å legge til en regel.

Eierskap snubler folk også. Kjernen tilskriver lokalt genererte pakker prosessen som åpnet sokkelen, og OpenVPN kjører vanligvis som root, så en regel bundet til en vanlig bruker-ID ser aldri tunnelens egen trafikk. Sjekk den eide UID-en før du bestemmer at regelen er feil.

Bare når tellerne forblir tvetydige er en logg verdt støyen, og da bare for en smal skive: en iptables-regel som hastighetsbegrenser og setter prefiks på logglinjene sine, eller en nftables-regel med meta nftrace set 1 mens nft monitor trace kjører. Et spor navngir kjeden og regelen som godtok eller droppet pakken. Fjern begge etterpå og hold nyttelastlogging utenfor.

Sjekk transporten også. En brannmurtjeneste begrenset til TCP sier ingenting om en UDP-lytter på det nummeret, så en regel som leses riktig kan fortsatt droppe hver pakke.

Rutting og veien tilbake

En godtatt pakke som likevel forsvinner trenger at destinasjonsveien undersøkes. ip route get rapporterer ruten som er valgt for én adresse, og omvendt vei-filtrering kan droppe et svar som ankommer over et grensesnitt som hovedtabellen aldri ville velge. Symptomet ser nøyaktig ut som en brannmur-drop, derfor kommer denne sjekken før en annen NAT-regel.

På en gateway, undersøk videresending og forward-kjeden i stedet for input-kjeden. Bekreft deretter at den fjerne siden vet hvordan den når kildeadressen, fordi en fungerende utgående vei uten noe som kommer tilbake er stillhet i begge tilfeller.

Hva notatet må si

For hver endring, noter stadiet du testet, beviset du leste og tellerverdien på begge sider av det. Det notatet er det som gjør "det virker nå" overlevelsesdyktig ved neste gjennomgang.

To snarveier holder notatet ærlig. En pakke som aldri forlot verten kan ikke ha blitt droppet av en regel et annet sted, uansett hvor overbevisende konfigurasjonen på den fjerne siden ser ut. En pakke som gikk ut og kom tilbake flytter spørsmålet over nettverkslaget, der brannmurens tellere ikke har mer å fortelle deg.