Blokkerer naudstoppen til UFW VPN-en din? Tillat motparten

Du følgde sjekklista: avvis utgåande, tillat tunnelen, aktiver ufw. Så ventar klienten på handtrykket og koplar aldri til, eller han koplar til og inga side lastar. Begge feila kjem frå same hòlet. Regelen som lèt tunnelen eksistere manglar, fordi tunnelen ikkje er eit grensesnitt pakkane dine forlèt gjennom.

Kvifor ei tillating på tun0 først ikkje passar med noko

tun0 vert oppretta av klienten etter at ein sesjon finst. Datagramma som byggjer den sesjonen er vanlege UDP-pakkar adresserte til leverandøren på port 1194, og dei forlèt gjennom wlan0 eller eth0 med den fysiske kjeldeadressa. allow out on tun0 passar berre med trafikk der det utgåande grensesnittet er tun0, så under handtrykket passar han med ingenting i det heile.

Set default deny outgoing oppå det, og dei ytre pakkane vert sleppte før grensesnittet i det heile dukkar opp. Klienten prøver igjen, timar ut og rapporterer ein TLS- eller handtrykkfeil, noko som sender folk på jakt gjennom sertifikat og MTU medan brannmuren stille et sambandet. Regelen som skulle halde trafikken din inne, hindrar at den trafikken vert halden inne.

Refleksfiksen gjer lekkasjen permanent. sudo ufw allow out on wlan0, eller å vri standarden tilbake til tillat, får tunnelen opp og lèt maskinen stå utan naudstopp: neste gong tunnelen fell, held alt fram over den fysiske adapteren. Eg mista ein ettermiddag på akkurat det paret med endringar før eg fann ut kva pakke eg faktisk filtrerte.

Kva dei to pakkesetta treng

Trafikken din kryssar brannmuren to gonger, i to former. Den indre pakken går frå tunneladressa og ut gjennom tun0. Den ytre pakken går frå den fysiske adressa til motparten, og han er det einaste som er synleg på leiaren. Éin 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 adressa og porten med dei frå din eigen profil. WireGuard-motpartar svarar vanlegvis på 51820/udp; OpenVPN-profilar som går over TCP 443 treng den porten i staden. Detaljane er ulike, forma ikkje: begge reglane er smale, og saman definerer dei dei einaste destinasjonane maskinen kan nå medan tunnelen er nede.

Rekkjefølgje er den andre myten. Med rå iptables les du kjeda ovanfrå og ned og resonnerer deg fram til kva regel som vinn. ufw er ikkje ei tynn innpakning rundt lista du skreiv; det kompilerer reglane dine inn i sine eigne kjeder og vel innsetjingspunkta. ufw status skriv dei ut i rekkjefølgja til ufw, ikkje di. Når ein regel ser ut til å verte ignorert, samanlikn ufw show added med det kompilerte settet frå iptables -S | grep ufw før du skriv om noko.

Unntaket må halde fram som éi adresse breitt

Ein motpartsregel er berre rett så lenge han namngjev adressa klienten ringjer. Leverandørar roterer endepunkt, og ein profil som slår opp eit vertsnamn vil følgje ei DNS-endring til ei ny adresse medan regelen framleis peikar på den gamle. Når ein tunnel som verka i månadsvis sluttar å kome opp, samanlikn adressa i regelen med den klienten leitar etter før du utvidar noko.

Å utvide til eit heilt subnett, eller til kvar destinasjon på port 1194, gjer politikken tilbake til ein brannmur med eit hòl. Unntaket er naudstoppen; når han først er brei, er det ingenting att å stoppe. Hald han på éi adresse og legg att ein kommentar som namngjev profilen og leverandøren han høyrer til, for om seks månader vil adressa sjå vilkårleg ut.

Namneoppslag fortener si eiga linje. Oppslaget skjer før tunnelen finst, over det fysiske grensesnittet, så ein streng avvis-utgåande-politikk kan la klienten vere ute av stand til å finne sin eigen server. Tillat port 53 til adressa til resolveryen din, eller løys opp éin gong og fest adressa i profilen. Å tillate DNS på alle grensesnitt er ei avgjerd, ikkje ein standard.

Bygg politikken før tunnelen trengst

ufw enable brukar heile politikken på éin gong og lastar inn kjedene sine på nytt, og endring av ein standardpolitikk på ein køyrande brannmur lastar dei òg inn på nytt. ufw-handboka åtvarar om at dette kan sleppe eksisterande samband som SSH. Derfor går kommandoane i denne rekkjefølgja, med SSH-regelen før aktiveringa og ein open konsollsasjon:

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 medvite utelaten frå den blokka. Han slettar kvar regel og deaktiverer brannmuren, og på ein ekstern vert er den påfølgjande aktiveringa det som slepp sesjonen din. Viss du likevel nullstiller, legg til SSH-regelen og stadfest ein annan veg tilbake via ein konsoll før du går vidare.

Rekkjefølgja er ikkje kosmetisk. Reglar som vert lagde til medan ufw køyrer, spylar ingenting, men i det augeblikket du vrir ein standardpolitikk, vert kjedene lasta inn på nytt, og ein sesjon som den gamle politikken tillét, går med dei. Gjer standardane, tillatingane og aktiveringa i éin runde, medan du framleis har ein veg inn som ikkje er avhengig av maskinen.

Test den blokkerte tilstanden, og behald angre-kommandoen

Ein utesta naudstopp er ei gjetting. Kople frå klienten med vilje og prøv å laste ei side: det må feile. Kople til igjen, og han må kome seg utan å røre ein regel. sudo ufw status verbose stadfestar standardane og loggtilstanden, og ufw status numbered viser kva testregel som skal slettast når han overlever føremålet sitt.

Hald det omvende skriptet ved sida av det framoverretta. Ein maskin med avvis-utgåande og ein daud tunnel kan ikkje laste ned si eiga reparasjon, så angre-kommandoen må liggje på disken og vere lesbar frå ein konsoll:

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

Køyr det når tunnelen alt er nede og reglane må av, ikkje som eit rutinesteg. Før du lukkar terminalen, skal fire ting halde: motpartsregelen namngjev nøyaktig éi adresse, DNS har eit namngjeve unntak, aktiveringa kom etter tillatingane, og å trekke tunnelen drep vanleg trafikk utan å drepe klienten for godt.