En firewall i en Linux-distribution kan blokere din VPN-trafik

Tunnelen kommer op, loggen siger forbundet, og en applikation kan stadig ikke nå noget. På en Linux-klient betyder det som regel, at distributionens firewall filtrerer en sti, som VPN-klienten aldrig styrede. To administratorer kan være aktive på én gang, hver med sine egne forestillinger om grænsefladen, zonen og trafikkens retning. At identificere ejeren, før man redigerer noget, er hurtigere end at prøve regler, indtil noget virker.

Find administratoren og backend

Begynd med det, der faktisk er indlæst, ikke det, der er installeret. En distribution kan levere firewalld, ufw og en almindelig nftables-tjeneste, og kun én af dem ejer det kørende regelsæt. Pakkerne sameksisterer fredeligt, og en regel, der indtastes gennem den forkerte frontend, når aldrig kernen. Læs den aktive tjeneste, og læs derefter det regelsæt, den producerede.

Backend betyder lige så meget som frontend. En firewalld-installation kan drive nftables eller den gamle iptables-backend afhængigt af version og konfiguration, og de to giver forskelligt inspektionsoutput. Skriv distributionen, versionen og backend i billetten, før du sammenligner dit system med nogen guide.

Tilpas retningen og grænsefladen

En udgående klientanmodning, en indgående lytter og en videresendt pakke passerer forskellige kroge, og en regel for den ene dækker ikke de andre. En zone, der tillader det lokale LAN, omfatter ofte ikke tunnelgrænsefladen eller VPN-adressepuljen. En tunnelgrænseflade lander normalt i standardzonen, som ofte er strengere end den zone, den fysiske adapter sidder i. Den uoverensstemmelse forklarer, hvorfor browsing virker på LAN, og stopper i det øjeblik tunnelen kommer op.

Spørg, hvilken retning der fejlede, før du vælger en regel. En applikation, der ikke kan forbinde udad, har brug for udgangsstien, mens en indgående tjeneste har brug for indgangsstien på tunnelgrænsefladen. At tilføje en regel til den forkerte kæde giver en ændring, der ser anvendt ud og slet ikke gør noget.

Hold regelejerne enige

En VPN-klients krog, en container-runtime og distributionens tjeneste kan alle ændre netværket, og de koordinerer ikke med hinanden. Håndindtastede regler forsvinder ved næste genindlæsning, og regler, der indsættes i en administrators kæde, kan evalueres i en rækkefølge, du ikke havde tænkt dig. Brug administratorens vedvarende konfiguration, og inspicér det resulterende regelsæt i stedet for den fil, du skrev. At slå hele firewallen fra, fordi én tjeneste er utilgængelig, bytter et lille problem for et stort.

Smalte tællere er den billige måde at finde den afviste strøm. En logregel begrænset til én destination og én port viser, om drop sker lokalt uden at fange andres trafik. Fjern logreglen, når undersøgelsen slutter, da den er diagnostik og ikke politik, og firewallds zonedokumentation forklarer, hvordan grænseflader og tjenester kombineres.

Kontrollér rettelsen uden at miste lockdown

Inspicér den anvendte tilstand med den administrator, der ejer den, ved at bruge kommandoer, der matcher den backend, du noterede. Listen nedenfor antager, at firewalld har ansvaret; indsæt ækvivalenten for nftables eller ufw i stedet for at køre dem alle. At blande værktøjer i én session er, hvordan en maskine ender med to modstridende regelsæt.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

Den første kommando navngiver zonerne og de grænseflader, der er tildelt dem, hvilket viser, hvor tunnelen faktisk landede. Den anden udskriver en zones regler og tjenester, så du kan se, om VPN-grænsefladen overhovedet er dækket. nftables-listen er grundsandheden for den anvendte backend, og en regel, der kun findes i en konfigurationsfil, optræder ikke der. Sammenlign de tre output med den regel, du tilføjede, og uoverensstemmelsen navngiver som regel sig selv.

Gentag derefter den oprindelige anmodning og den fejlopførsel, du kræver. Et nyfungerende websted er ikke nok, hvis den samme ændring fjernede klientens lockdown, så test også en ubeskyttet sti. Notér administrator, backend, grænseflade og formålet med reglen, fordi en pakkeopdatering, der genopliver en anden administrator, ellers genopbygger hele rodet.