Kas UFW hädapeatnupp blokeerib sinu VPN-i? Lubage partner

Järgisid kontrollnimekirja: keela väljuv, luba tunnel, luba ufw. Siis jääb klient käepigistuse juures ootama ega ühenda kunagi, või ühendab ja ükski leht ei laadi. Mõlemad tõrked tulevad samast tühikust. Puudu on reegel, mis laseb tunnelil olemas olla, sest tunnel ei ole liides, mille kaudu sinu paketid väljuvad.

Miks luba tun0-l alguses mitte millegagi ei kattu

tun0 loob klient pärast sessiooni olemasolu. Seda sessiooni ehitavad datagrammid on tavalised UDP-paketid, mis on adresseeritud teenusepakkujale pordile 1194, ja need väljuvad läbi wlan0 või eth0 füüsilise lähteaadressiga. allow out on tun0 kattub ainult liiklusega, mille väljuv liides on tun0, seega käepigistuse ajal ei kattu see üldse millegagi.

Aseta default deny outgoing selle peale ja välised paketid visatakse ära enne, kui liides üldse ilmub. Klient proovib uuesti, aegub ja teatab TLS-i või käepigistuse tõrkest, mis saadab inimesed sertifikaate ja MTU-d uurima, samal ajal kui tulemüür sööb ühenduse vaikselt ära. Reegel, mis pidi sinu liiklust ohjeldama, takistab selle liikluse ohjeldamist.

Refleksne parandus muudab lekkimise püsivaks. sudo ufw allow out on wlan0, või vaikeväärtuse tagasi lubamiseks keeramine, tõstab tunneli üles ja jätab masina ilma hädapeatnupust: järgmisel korral, kui tunnel kukub, jätkub kõik füüsilise adapteri kaudu. Kaotasin terve pärastlõuna täpselt sellele muudatuste paarile, enne kui taipasin, millist paketti ma tegelikult filtreerin.

Mida kaks paketihulka vajavad

Sinu liiklus läbib tulemüüri kaks korda, kahes vormis. Sisemine pakett läheb tunneli aadressilt välja läbi tun0. Välimine pakett läheb füüsiliselt aadressilt partnerini ja see on ainus, mis on juhtmel nähtav. Üks reegel vormi kohta:

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'

Asenda aadress ja port nendega omaenda profiilist. WireGuardi partnerid vastavad tavaliselt aadressil 51820/udp; OpenVPN-i profiilid, mis sõidavad üle TCP 443, vajavad selle asemel seda porti. Üksikasjad erinevad, vorm mitte: mõlemad reeglid on kitsad ja koos määratlevad need ainsad sihtkohad, kuhu masin pääseb, kui tunnel on maas.

Järjekord on teine müüt. Toore iptablesi puhul loed ahelat ülalt alla ja mõtled, milline reegel võidab. ufw ei ole õhuke ümbris selle nimekirja ümber, mille sa trükkisid; see kompileerib sinu reeglid oma ahelatesse ja valib sisestuskohad. ufw status trükib need ufw järjekorras, mitte sinu omas. Kui reegel tundub ignoreerituna, võrdle ufw show added kompileeritud hulgaga iptables -S | grep ufw enne, kui midagi ümber kirjutad.

Erand peab jääma ühe aadressi laiuseks

Partnerireegel on õige ainult seni, kuni see nimetab aadressi, millele klient valib. Teenusepakkujad pööravad lõpp-punkte ja hostinime lahendav profiil järgib DNS-i muutust uuele aadressile, samal ajal kui reegel osutab endiselt vanale. Kui tunnel, mis töötas kuid, ei tõuse enam üles, võrdle reeglis olevat aadressi sellega, mida klient otsib, enne kui midagi laiendad.

Laiendamine tervele alamvõrgule või kõikidele sihtkohtadele pordil 1194 muudab poliitika jälle tulemüüriks, milles on auk. Erand on hädapeatnupp; kui see on lai, ei ole enam midagi peatada. Hoia seda ühel aadressil ja jäta kommentaar, mis nimetab profiili ja teenusepakkuja, kellele see kuulub, sest kuue kuu pärast näeb aadress meelevaldne välja.

Nimelahendus väärib omaette rida. Päring toimub enne, kui tunnel olemas on, füüsilise liidese kaudu, seega range väljuva keelav poliitika võib jätta kliendi oma serverit leidmata. Lubage port 53 oma resolveri aadressile, või lahendage üks kord ja kinnitage aadress profiili. DNS-i lubamine igal liidesel on otsus, mitte vaikeväärtus.

Ehita poliitika enne, kui tunnelit vaja läheb

ufw enable rakendab kogu poliitika korraga ja laadib oma ahelad uuesti, ning vaikimisi poliitika muutmine töötaval tulemüüril laadib need samuti uuesti. ufw käsiraamat hoiatab, et see võib katkestada olemasolevad ühendused, näiteks SSH. Seepärast lähevad käsud sellises järjekorras, SSH-reegel enne lubamist ja avatud konsoolisessiooniga:

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 on sellest plokist meelega välja jäetud. See kustutab iga reegli ja lülitab tulemüüri välja, ning kaugvastuvõtjas on järgnev lubamine see, mis sinu sessiooni maha viskab. Kui siiski lähtestad, lisa SSH-reegel ja kinnita teine tee tagasi konsooli kaudu enne, kui edasi lähed.

Järjestus ei ole kosmeetiline. Reeglid, mis lisatakse ufw töötamise ajal, ei loputa midagi, kuid hetkel, mil sa vaikimisi poliitika ümber pöörad, laaditakse ahelad uuesti ja sessioon, mille vana poliitika lubas, läheb nendega kaasa. Tee vaikeväärtused, load ja lubamine ühe hooga, kuni sul on veel sissepääs, mis ei sõltu masinast.

Testi blokeeritud olekut ja hoia tagasivõtmine alles

Testimata hädapeatnupp on oletus. Ühenda klient meelega lahti ja proovi lehte laadida: see peab ebaõnnestuma. Ühenda uuesti ja see peab taastuma ilma ühtegi reeglit puutumata. sudo ufw status verbose kinnitab vaikeväärtused ja logimise oleku, ning ufw status numbered näitab, milline testreegel kustutada, kui see oma otstarbe üle elab.

Hoia tagurpidi skript päriskripti kõrval. Masin, millel on väljuva keeld ja surnud tunnel, ei saa oma parandust alla laadida, seega peab tagasivõtmine olema kettal ja konsoolist loetav:

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

Käivita see siis, kui tunnel on juba maas ja reeglid tuleb maha võtta, mitte rutiinse sammuna. Enne, kui terminali sulged, peaks kehtima neli asja: partnerireegel nimetab täpselt ühte aadressi, DNS-il on nimetatud erand, lubamine tuli pärast lubasid, ja tunneli katkestamine tapab tavalise liikluse, ilma et tapaks kliendi jäädavalt.