UFW avarinis išjungiklis blokuoja jūsų VPN? Leiskite partneriui

Jūs įvykdėte kontrolinį sąrašą: uždrausti išeinantį, leisti tunelį, įjungti ufw. Tada klientas laukia rankos paspaudimo ir niekada neprisijungia, arba prisijungia ir joks puslapis neįkeliamas. Abi nesėkmės kyla iš tos pačios spragos. Trūksta taisyklės, leidžiančios tuneliui egzistuoti, nes tunelis nėra sąsaja, iš kurios išeina jūsų paketai.

Kodėl leidimas tun0 iš pradžių nieko neatitinka

tun0 sukuria klientas, kai sesija jau egzistuoja. Datagramos, kurios kuria tą sesiją, yra įprasti UDP paketai, adresuoti tiekėjui 1194 prievadu, ir jie išeina per wlan0 arba eth0 su fiziniu šaltinio adresu. allow out on tun0 atitinka tik tą srautą, kurio išeinanti sąsaja yra tun0, todėl rankos paspaudimo metu jis neatitinka nieko.

Uždėkite default deny outgoing ir išoriniai paketai išmetami dar prieš atsirandant sąsajai. Klientas bando dar kartą, pasiekia laiko limitą ir praneša apie TLS arba rankos paspaudimo klaidą, o tai siunčia žmones ieškoti sertifikatuose ir MTU, kol ugniasienė tyliai suvalgo ryšį. Taisyklė, kuri turėjo sulaikyti jūsų srautą, trukdo tam srautui būti sulaikytam.

Refleksinis pataisas padaro nutekėjimą nuolatiniu. sudo ufw allow out on wlan0, arba grąžinus numatytąją reikšmę į leisti, pakelia tunelį ir palieka mašiną be avarinio išjungiklio: kitą kartą tuneliui nukritus, viskas atsinaujina per fizinį adapterį. Aš praradau popietę būtent dėl šios poros pakeitimų, kol išsiaiškinau, kurį paketą iš tikrųjų filtruoju.

Ko reikia dviem paketų rinkiniams

Jūsų srautas ugniasienę kerta du kartus, dviem formomis. Vidinis paketas eina nuo tunelio adreso į išorę per tun0. Išorinis paketas eina nuo fizinio adreso iki partnerio, ir tai vienintelis dalykas, matomas laide. Viena taisyklė vienai formai:

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'

Pakeiskite adresą ir prievadą tais, kurie yra jūsų profilyje. WireGuard partneriai paprastai atsako 51820/udp; OpenVPN profiliai, einantys per TCP 443, vietoj to reikalauja šio prievado. Detalės skiriasi, forma ne: abi taisyklės siauros, ir kartu jos apibrėžia vienintelius tikslus, kuriuos mašina gali pasiekti, kol tunelis neveikia.

Tvarka yra antrasis mitas. Su neapdorotu iptables skaitote grandinę iš viršaus į apačią ir samprotaujate, kuri taisyklė laimi. ufw nėra plonas įvesto sąrašo apvalkalas; jis kompiliuoja jūsų taisykles į savo grandines ir parenka įterpimo taškus. ufw status išspausdina jas ufw tvarka, o ne jūsų. Kai taisyklė atrodo ignoruojama, palyginkite ufw show added su sukompiliuotu rinkiniu iš iptables -S | grep ufw prieš ką nors perrašydami.

Išimtis turi likti vieno adreso pločio

Partnerio taisyklė teisinga tik tol, kol ji nurodo adresą, kuriuo skambina klientas. Tiekėjai rotuoja galinius taškus, o profilis, kuris išsprendžia hostname, seks DNS pakeitimą į naują adresą, kol taisyklė tebebo nurodo senąjį. Kai mėnesius veikęs tunelis nebepakyla, prieš ką nors plėsdami palyginkite taisyklės adresą su tuo, kurio ieško klientas.

Išplėtimas į visą potinklį arba į kiekvieną tikslą 1194 prievadu paverčia politiką vėl ugniasiene su skyle. Išimtis yra avarinis išjungiklis; kai ji plati, nebelieka ko išjungti. Laikykite ją viename adrese ir palikite komentarą, nurodantį profilį ir tiekėją, kuriam ji priklauso, nes po šešių mėnesių adresas atrodys savavališkas.

Vardų sprendimas nusipelno savo eilutės. Paieška vyksta prieš atsirandant tuneliui, per fizinę sąsają, todėl griežta išeinančio draudimo politika gali palikti klientą neįgalų susirasti savo serverį. Leiskite 53 prievadą į savo resolverio adresą arba išspręskite vieną kartą ir įtvirtinkite adresą profilyje. Leisti DNS visose sąsajose yra sprendimas, ne numatytoji reikšmė.

Sukurkite politiką prieš prireikiant tunelio

ufw enable taiko visą politiką iš karto ir įkelia iš naujo savo grandines, o numatytosios politikos pakeitimas veikiančioje ugniasienėje taip pat įkelia jas iš naujo. ufw vadovas įspėja, kad tai gali numesti esamus ryšius, pavyzdžiui, SSH. Todėl komandos eina šia tvarka, su SSH taisykle prieš įjungimą ir atvira konsolės sesija:

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 sąmoningai paliktas už šio bloko. Jis ištrina kiekvieną taisyklę ir išjungia ugniasienę, o nuotoliniame hoste būtent tolesnis įjungimas numeta jūsų sesiją. Jei vis tiek atstatysite, pridėkite SSH taisyklę ir prieš eidami toliau patvirtinkite antrą kelią atgal per konsolę.

Seka nėra kosmetinė. Taisyklės, pridėtos veikiant ufw, nieko neišplauna, bet tuo metu, kai apverčiate numatytąją politiką, grandinės įkeliamos iš naujo, ir sesija, kurią leido senoji politika, išeina kartu. Atlikite numatytąsias, leidimus ir įjungimą vienu ėjimu, kol dar turite įėjimą, kuris nepriklauso nuo mašinos.

Išbandykite užblokuotą būseną ir pasilikite atšaukimą

Neišbandytas avarinis išjungiklis yra spėjimas. Sąmoningai atjunkite klientą ir pabandykite įkelti puslapį: turi nepavykti. Prisijunkite iš naujo, ir jis turi atsistatyti nelietus jokios taisyklės. sudo ufw status verbose patvirtina numatytąsias ir registravimo būseną, o ufw status numbered parodo, kurią bandomąją taisyklę ištrinti, kai ji pergyvena savo paskirtį.

Laikykite atvirkštinį skriptą šalia tiesioginio. Mašina su išeinančio draudimu ir mirusiu tuneliu negali atsisiųsti savo remonto, todėl atšaukimas turi būti diske ir skaitomas iš konsolės:

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

Paleiskite jį, kai tunelis jau neveikia ir taisykles reikia nuimti, o ne kaip įprastą žingsnį. Prieš uždarydami terminalą, turi galioti keturi dalykai: partnerio taisyklė nurodo tiksliai vieną adresą, DNS turi įvardytą išimtį, įjungimas įvyko po leidimų, o tunelio nutraukimas užmuša įprastą srautą nesunaikindamas kliento visam laikui.