Blokerer UFWs nødafbryder din VPN? Tillad modparten

Du fulgte tjeklisten: afvis udgående, tillad tunnelen, aktivér ufw. Så venter klienten ved håndtrykket og forbinder aldrig, eller den forbinder og ingen side indlæses. Begge fejl kommer fra samme hul. Reglen, der lader tunnelen eksistere, mangler, fordi tunnelen ikke er et interface, som dine pakker forlader.

Hvorfor en tilladelse på tun0 først ikke matcher noget

tun0 oprettes af klienten, efter at en session findes. De datagrammer, der bygger den session, er almindelige UDP-pakker adresseret til udbyderen på port 1194, og de forlader wlan0 eller eth0 med den fysiske kildeadresse. allow out on tun0 matcher kun trafik, hvis udgående interface er tun0, så under håndtrykket matcher den slet ingenting.

Sæt default deny outgoing oven på det, og de ydre pakker droppes, før interfacet overhovedet dukker op. Klienten prøver igen, timer ud og rapporterer en TLS- eller håndtryksfejl, hvilket sender folk på jagt i certifikater og MTU, mens firewallen stille spiser forbindelsen. Reglen, der skulle inddæmme din trafik, forhindrer, at den trafik bliver inddæmmet.

Refleksrettelsen gør lækagen permanent. sudo ufw allow out on wlan0, eller at skifte standarden tilbage til tillad, bringer tunnelen op og efterlader maskinen uden nødafbryder: næste gang tunnelen falder, genoptages alt over den fysiske adapter. Jeg tabte en eftermiddag på præcis det par ændringer, før jeg fandt ud af, hvilken pakke jeg egentlig filtrerede.

Hvad de to sæt pakker har brug for

Din trafik krydser firewallen to gange, i to former. Den indre pakke løber fra tunneladressen ud gennem tun0. Den ydre pakke løber fra den fysiske adresse til modparten, og den er det eneste, der er synligt på ledningen. Én regel pr. form:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

Erstat adressen og porten med dem fra din egen profil. WireGuard-modparter svarer normalt på 51820/udp; OpenVPN-profiler, der kører over TCP 443, har brug for den port i stedet. Detaljerne er forskellige, formen ikke: begge regler er smalle, og sammen definerer de de eneste destinationer, maskinen kan nå, mens tunnelen er nede.

Rækkefølge er den anden myte. Med rå iptables læser du kæden fra top til bund og ræsonnerer om, hvilken regel der vinder. ufw er ikke en tynd indpakning omkring listen, du skrev; den kompilerer dine regler i sine egne kæder og vælger indsættelsespunkterne. ufw status viser dem i ufw's rækkefølge, ikke din. Når en regel ser ud til at blive ignoreret, så sammenlign ufw show added med det kompilerede sæt fra iptables -S | grep ufw før du omskriver noget.

Undtagelsen skal blive én adresse bred

En modpartsregel er kun korrekt, mens den nævner den adresse, klienten ringer til. Udbyderne roterer endepunkter, og en profil, der opløser et værtsnavn, vil følge en DNS-ændring til en ny adresse, mens reglen fortsat peger på den gamle. Når en tunnel, der virkede i månedsvis, holder op med at komme op, så sammenlign adressen i reglen med den, klienten rækker efter, før du udvider noget.

At udvide til et helt subnet, eller til hver destination på port 1194, gør politikken tilbage til en firewall med et hul. Undtagelsen er nødafbryderen; når den først er bred, er der intet tilbage at afbryde. Hold den på én adresse, og efterlad en kommentar, der navngiver profilen og udbyderen, den hører til, for om seks måneder vil adressen se vilkårlig ud.

Navneopløsning fortjener sin egen linje. Opslaget sker, før tunnelen findes, over det fysiske interface, så en streng afvis-udgående-politik kan efterlade klienten ude af stand til at finde sin egen server. Tillad port 53 til din resolvers adresse, eller opløs én gang og fastlås adressen i profilen. At tillade DNS på alle interfaces er en beslutning, ikke en standard.

Byg politikken, før tunnelen er nødvendig

ufw enable anvender hele politikken på én gang og genindlæser sine kæder, og ændring af en standardpolitik på en kørende firewall genindlæser dem også. ufw-manualen advarer om, at dette kan droppe eksisterende forbindelser som SSH. Så kommandoerne går i denne rækkefølge, med SSH-reglen før aktiveringen og en åben konsolsession:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset er bevidst udeladt af den blok. Den sletter hver regel og deaktiverer firewallen, og på en fjern vært er den efterfølgende aktivering det, der dropper din session. Hvis du alligevel nulstiller, så tilføj SSH-reglen og bekræft en anden vej tilbage via en konsol, før du går videre.

Rækkefølgen er ikke kosmetisk. Regler, der tilføjes, mens ufw kører, skyller intet, men i det øjeblik du vender en standardpolitik, genindlæses kæderne, og en session, som den gamle politik tillod, går med dem. Gør standarderne, tilladelserne og aktiveringen i ét gennemløb, mens du stadig har en vej ind, der ikke afhænger af maskinen.

Test den blokerede tilstand, og behold fortrydelsen

En utestet nødafbryder er et gæt. Afbryd klienten med vilje, og prøv at indlæse en side: det må fejle. Gentilslut, og den skal komme sig uden at røre en regel. sudo ufw status verbose bekræfter standarderne og logningstilstanden, og ufw status numbered viser, hvilken testregel der skal slettes, når den overlever sit formål.

Hold det omvendte script ved siden af det fremadrettede. En maskine med afvis-udgående og en død tunnel kan ikke hente sin egen reparation, så fortrydelsen skal ligge på disken og kunne læses fra en konsol:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Kør det, når tunnelen allerede er nede, og reglerne skal af, ikke som et rutinetrin. Før du lukker terminalen, skal fire ting gælde: modpartsreglen nævner præcis én adresse, DNS har en navngivet undtagelse, aktiveringen kom efter tilladelserne, og når du trækker tunnelen, dræber det almindelig trafik uden at dræbe klienten for godt.