OpenVPN siger forbundet, og ingen trafik bevæger sig, en sætning der dækker mindst fem urelaterede fejl. At redigere firewallregler, før du ved, hvilket lag der svigter, formerer det ukendte og efterlader den næste ingeniør et rod. Arbejd i stedet udad fra processen, fordi hvert skridt nedenfor enten rydder en fase eller indsnævrer, hvor pakken dør. Rækkefølgen betyder noget her: en optagelse taget, før du ved, hvilken adresse der er bundet, beviser noget, bare ikke det, du har brug for.

Socketten er enten bundet eller ikke

En tjeneste, der rapporterer aktiv, kan stadig være bundet til en adresse eller transport, du aldrig havde tænkt dig. Forespørg den socket selv: ss -lunp viser UDP-lyttere, og ss -ltnp viser TCP, og den kolonne, der er værd at læse, er den lokale adresse, ikke tilstanden.

Et tomt svar betyder normalt en af tre ting: processen afsluttede efter start, den indlæste en anden konfigurationsfil, eller den lytter på en anden adresse end den, der ringes til.

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

En local-direktiv fastgør lytteren til en enkelt adresse, så en klient, der sigter mod et andet sted på samme vært, afvises, mens tjenesten udefra stadig ser sund ud. Et instansnavn kan også pege på en fil, du aldrig har redigeret, hvilket sker på værter, der kører to profiler side om side.

Fang den ydre pakke, ikke tunnelen

Filtrér på den fysiske grænseflade og den rigtige port, med din egen grænseflade indsat: tcpdump -ni eth0 udp port 1194. Udgående pakker uden noget, der kommer tilbage, peger på det, der sidder ovenfor: udbyderfiltrering, en NAT-enhed eller en fjernadresse, der ikke er den, du tror. Tavshed i begge retninger peger på klientrouting eller en lokal firewall. Svar, der ankommer uden fremdrift i tunnelen, peger på kontrolkanalen, altså en nøgle- eller cipher-uoverensstemmelse, ikke på filtrering.

Fang begge retninger, og hold filen kort. En lang optagelse begraver de interessante tre sekunder, og svaret ligger næsten altid i den første udveksling.

Tællere først, spor kun når de lyver

Begynd med tællerne, fordi de ikke koster noget. Enten nft list ruleset eller iptables -L -n -v besvarer det eneste spørgsmål, der betyder noget her: ramte reglen? Rækkefølgen afgør resultatet, fordi det første match vinder, og derfor efterlader et bredt DROP før en senere ACCEPT den ACCEPT død, og derfor reparerer det sjældent noget at tilføje en regel.

Ejerskab snubler folk også. Kernen tilskriver lokalt genererede pakker den proces, der åbnede socketten, og OpenVPN kører normalt som root, så en regel bundet til et almindeligt bruger-ID ser aldrig tunnelens egen trafik. Kontrollér den ejende UID, før du beslutter, at reglen er forkert.

Kun når tællerne forbliver tvetydige, er en log værd at støje med, og så kun for en smal skive: en iptables-regel, der hastighedsbegrænser og sætter præfiks på sine loglinjer, eller en nftables-regel med meta nftrace set 1, mens nft monitor trace kører. Et spor navngiver den kæde og den regel, der accepterede eller droppede pakken. Fjern begge bagefter, og hold payload-logning ude af det.

Kontrollér også transporten. En firewalltjeneste begrænset til TCP siger intet om en UDP-lytter på det nummer, så en regel, der læses korrekt, kan stadig droppe hver pakke.

Routing og vejen tilbage

En accepteret pakke, der stadig forsvinder, kræver, at dens destinationsvej undersøges. ip route get rapporterer den rute, der er valgt for en adresse, og omvendt sti-filtrering kan droppe et svar, der ankommer over en grænseflade, som hovedtabellen aldrig ville vælge. Symptomet ligner præcis et firewall-drop, og derfor kommer denne kontrol før endnu en NAT-regel.

På en gateway skal du undersøge videresendelse og forward-kæden i stedet for input-kæden. Bekræft derefter, at den fjerne side ved, hvordan den når kildeadressen, fordi en fungerende udgående vej uden noget, der kommer tilbage, er tavshed i begge tilfælde.

Hvad noten skal sige

For hver ændring skal du notere det trin, du testede, det bevis, du læste, og tællerværdien på begge sider af det. Den note er det, der gør "det virker nu" overlevelsesdygtigt ved næste gennemgang.

To genveje holder noten ærlig. En pakke, der aldrig forlod værten, kan ikke være droppet af en regel et andet sted, uanset hvor overbevisende den fjerne sides konfiguration ser ud. En pakke, der forlod og vendte tilbage, flytter spørgsmålet over netværkslaget, hvor firewallens tællere ikke har mere at fortælle dig.

Relaterede artikler