Blokkerer UFWs nødstopp VPN-en din? Tillat motparten

Du fulgte sjekklisten: avvis utgående, tillat tunnelen, aktiver ufw. Så venter klienten på håndtrykket og kobler aldri til, eller den kobler til og ingen side lastes. Begge feilene kommer fra samme hull. Regelen som lar tunnelen eksistere mangler, fordi tunnelen ikke er et grensesnitt pakkene dine forlater gjennom.

Hvorfor en tillatelse på tun0 først ikke matcher noe

tun0 opprettes av klienten etter at en sesjon finnes. Datagrammene som bygger den sesjonen er vanlige UDP-pakker adressert til leverandøren på port 1194, og de forlater gjennom wlan0 eller eth0 med den fysiske kildeadressen. allow out on tun0 matcher bare trafikk der det utgående grensesnittet er tun0, så under håndtrykket matcher den ingenting i det hele tatt.

Sett default deny outgoing oppå det, og de ytre pakkene slippes før grensesnittet i det hele tatt dukker opp. Klienten prøver igjen, timer ut og rapporterer en TLS- eller håndtrykkfeil, noe som sender folk på jakt gjennom sertifikater og MTU mens brannmuren stille spiser forbindelsen. Regelen som skulle holde trafikken din inne, hindrer at den trafikken blir holdt inne.

Refleksfiksen gjør lekkasjen permanent. sudo ufw allow out on wlan0, eller å vri standarden tilbake til tillat, får tunnelen opp og lar maskinen stå uten nødstopp: neste gang tunnelen faller, fortsetter alt over den fysiske adapteren. Jeg mistet en ettermiddag på akkurat det paret med endringer før jeg fant ut hvilken pakke jeg faktisk filtrerte.

Hva de to pakkesettene trenger

Trafikken din krysser brannmuren to ganger, i to former. Den indre pakken går fra tunneladressen og ut gjennom tun0. Den ytre pakken går fra den fysiske adressen til motparten, og den er det eneste som er synlig på ledningen. Én regel per 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'

Erstatt adressen og porten med dem fra din egen profil. WireGuard-motparter svarer vanligvis på 51820/udp; OpenVPN-profiler som går over TCP 443 trenger den porten i stedet. Detaljene er forskjellige, formen ikke: begge reglene er smale, og sammen definerer de de eneste destinasjonene maskinen kan nå mens tunnelen er nede.

Rekkefølge er den andre myten. Med rå iptables leser du kjeden ovenfra og ned og resonnerer deg fram til hvilken regel som vinner. ufw er ikke en tynn innpakning rundt listen du skrev; det kompilerer reglene dine inn i sine egne kjeder og velger innsettingspunktene. ufw status skriver dem ut i ufw sin rekkefølge, ikke din. Når en regel ser ut til å bli ignorert, sammenlign ufw show added med det kompilerte settet fra iptables -S | grep ufw før du skriver om noe.

Unntaket må forbli én adresse bredt

En motpartsregel er bare riktig så lenge den navngir adressen klienten ringer. Leverandører roterer endepunkter, og en profil som slår opp et vertsnavn vil følge en DNS-endring til en ny adresse mens regelen fortsatt peker på den gamle. Når en tunnel som virket i månedsvis slutter å komme opp, sammenlign adressen i regelen med den klienten leter etter før du utvider noe.

Å utvide til et helt subnett, eller til hver destinasjon på port 1194, gjør politikken tilbake til en brannmur med et hull. Unntaket er nødstoppen; når den først er bred, er det ingenting igjen å stoppe. Hold den på én adresse og legg igjen en kommentar som navngir profilen og leverandøren den hører til, for om seks måneder vil adressen se vilkårlig ut.

Navneoppslag fortjener sin egen linje. Oppslaget skjer før tunnelen finnes, over det fysiske grensesnittet, så en streng avvis-utgående-politikk kan la klienten være ute av stand til å finne sin egen server. Tillat port 53 til adressen til resolveryen din, eller løs opp én gang og fest adressen i profilen. Å tillate DNS på alle grensesnitt er en beslutning, ikke en standard.

Bygg politikken før tunnelen trengs

ufw enable bruker hele politikken på én gang og laster inn kjedene sine på nytt, og endring av en standardpolitikk på en kjørende brannmur laster dem også inn på nytt. ufw-håndboken advarer om at dette kan slippe eksisterende forbindelser som SSH. Derfor går kommandoene i denne rekkefølgen, med SSH-regelen før aktiveringen og en åpen konsollsesjon:

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 bevisst utelatt fra den blokken. Den sletter hver regel og deaktiverer brannmuren, og på en ekstern vert er den påfølgende aktiveringen det som slipper sesjonen din. Hvis du likevel nullstiller, legg til SSH-regelen og bekreft en annen vei tilbake via en konsoll før du går videre.

Rekkefølgen er ikke kosmetisk. Regler som legges til mens ufw kjører, spyler ingenting, men i det øyeblikket du vrir en standardpolitikk, lastes kjedene på nytt, og en sesjon som den gamle politikken tillot, går med dem. Gjør standardene, tillatelsene og aktiveringen i én runde, mens du fortsatt har en vei inn som ikke avhenger av maskinen.

Test den blokkerte tilstanden, og behold angre-kommandoen

En utestet nødstopp er en gjetning. Koble fra klienten med vilje og prøv å laste en side: det må feile. Koble til igjen, og den må komme seg uten å røre en regel. sudo ufw status verbose bekrefter standardene og loggetilstanden, og ufw status numbered viser hvilken testregel som skal slettes når den overlever formålet sitt.

Hold det omvendte skriptet ved siden av det fremoverrettede. En maskin med avvis-utgående og en død tunnel kan ikke laste ned sin egen reparasjon, så angre-kommandoen må ligge på disken og være lesbar fra en konsoll:

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

Kjør det når tunnelen allerede er nede og reglene må av, ikke som et rutinetrinn. Før du lukker terminalen, skal fire ting holde: motpartsregelen navngir nøyaktig én adresse, DNS har et navngitt unntak, aktiveringen kom etter tillatelsene, og å trekke tunnelen dreper vanlig trafikk uten å drepe klienten for godt.