Varnostno stikalo UFW blokira vaš VPN? Dovolite partnerju

Sledili ste kontrolnemu seznamu: zavrnite odhodno, dovolite tunel, omogočite ufw. Nato odjemalec čaka na rokovanje in se nikoli ne poveže, ali pa se poveže in nobena stran se ne naloži. Obe napaki izhajata iz iste vrzeli. Manjka pravilo, ki tunelu omogoča obstoj, ker tunel ni vmesnik, skozi katerega odhajajo vaši paketi.

Zakaj se dovoljenje na tun0 sprva ne ujema z ničimer

tun0 ustvari odjemalec, ko seja obstaja. Datagrami, ki gradijo to sejo, so običajni paketi UDP, naslovljeni na ponudnika na vratih 1194, in odhajajo skozi wlan0 ali eth0 s fizičnim izvornim naslovom. allow out on tun0 se ujema le s prometom, katerega odhodni vmesnik je tun0, zato se med rokovanjem ne ujema z ničimer.

Postavite default deny outgoing povrh in zunanji paketi se zavržejo, še preden se vmesnik sploh pojavi. Odjemalec poskusi znova, poteče čas in sporoči napako TLS ali rokovanja, kar pošlje ljudi iskat po potrdilih in MTU, medtem ko požarni zid tiho požira povezavo. Pravilo, ki naj bi vaš promet zadržalo, preprečuje, da bi se ta promet zadržal.

Refleksni popravek naredi uhajanje trajno. sudo ufw allow out on wlan0, ali vrnitev privzete vrednosti na dovoli, dvigne tunel in pusti stroj brez varnostnega stikala: naslednjič, ko tunel pade, se vse nadaljuje prek fizičnega adapterja. Izgubil sem popoldne prav zaradi tega para sprememb, preden sem ugotovil, kateri paket pravzaprav filtriram.

Kaj potrebujeta oba niza paketov

Vaš promet dvakrat prečka požarni zid, v dveh oblikah. Notranji paket gre z naslova tunela ven skozi tun0. Zunanji paket gre s fizičnega naslova do partnerja in je edino, kar je vidno na žici. Eno pravilo na obliko:

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'

Zamenjajte naslov in vrata s tistimi iz svojega profila. Partnerji WireGuard običajno odgovarjajo na 51820/udp; profili OpenVPN, ki gredo čez TCP 443, namesto tega potrebujejo ta vrata. Podrobnosti se razlikujejo, oblika ne: obe pravili sta ozki in skupaj določata edine cilje, ki jih stroj lahko doseže, ko tunel ne deluje.

Vrstni red je drugi mit. Pri surovem iptablesu berete verigo od zgoraj navzdol in razmišljate, katero pravilo zmaga. ufw ni tanka ovojnica okoli seznama, ki ste ga vnesli; vaša pravila prevede v svoje verige in izbere mesta vstavljanja. ufw status jih izpiše v vrstnem redu ufw, ne vašem. Ko je pravilo videti prezrto, primerjajte ufw show added s prevedenim nizom iz iptables -S | grep ufw preden kar koli prepišete.

Izjema mora ostati široka en naslov

Pravilo za partnerja je pravilno le, dokler navaja naslov, na katerega kliče odjemalec. Ponudniki vrtijo končne točke in profil, ki razreši ime gostitelja, bo sledil spremembi DNS na nov naslov, medtem ko pravilo še vedno kaže na starega. Ko tunel, ki je deloval mesece, neha vstajati, primerjajte naslov v pravilu s tistim, ki ga odjemalec išče, preden karkoli razširite.

Razširitev na celotno podomrežje ali na vsak cilj na vratih 1194 spremeni politiko nazaj v požarni zid z luknjo. Izjema je varnostno stikalo; ko je enkrat široko, ni več česa izklopiti. Držite ga na enem naslovu in pustite komentar z imenom profila in ponudnika, ki mu pripada, ker bo čez šest mesecev naslov videti samovoljen.

Razreševanje imen si zasluži svojo vrstico. Iskanje se zgodi, preden tunel obstaja, prek fizičnega vmesnika, zato lahko stroga politika zavrnitve odhoda pusti odjemalca nezmožnega najti svoj strežnik. Dovolite vrata 53 na naslov svojega razreševalnika ali enkrat razrešite in naslov pripnite v profil. Dovoljenje DNS na vsakem vmesniku je odločitev, ne privzeto.

Zgradite politiko, preden bo tunel potreben

ufw enable uporabi celotno politiko naenkrat in znova naloži svoje verige, sprememba privzete politike na delujočem požarnem zidu pa jih prav tako znova naloži. ufw priročnik opozarja, da lahko to odvrže obstoječe povezave, kot je SSH. Zato gredo ukazi v tem vrstnem redu, s pravilom SSH pred omogočanjem in odprto konzolno sejo:

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 je namerno izpuščen iz tega bloka. Izbriše vsako pravilo in onemogoči požarni zid, na oddaljenem gostitelju pa je prav naslednje omogočanje tisto, ki odvrže vašo sejo. Če vseeno ponastavite, dodajte pravilo SSH in pred nadaljevanjem potrdite drugo pot nazaj prek konzole.

Zaporedje ni kozmetično. Pravila, dodana med delovanjem ufw, ničesar ne izplaknejo, a v trenutku, ko obrnete privzeto politiko, se verige znova naložijo in seja, ki jo je stara politika dovoljevala, gre z njimi. Naredite privzete vrednosti, dovoljenja in omogočanje v enem prehodu, dokler imate še pot noter, ki ni odvisna od stroja.

Preizkusite blokirano stanje in obdržite razveljavitev

Nepreizkušeno varnostno stikalo je ugibanje. Odjemalec namenoma odklopite in poskusite naložiti stran: mora spodleteti. Znova se povežite in mora si opomoči brez dotika pravila. sudo ufw status verbose potrdi privzete vrednosti in stanje beleženja, in ufw status numbered pokaže, katero preskusno pravilo izbrisati, ko preživi svoj namen.

Držite obrnjeni skript ob prednjem. Stroj z zavrnitvijo odhoda in mrtvim tunelom ne more prenesti lastnega popravka, zato mora razveljavitev ležati na disku in biti berljiva s konzole:

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

Zaženite ga, ko je tunel že dol in je treba pravila odstraniti, ne kot rutinski korak. Preden zaprete terminal, morajo veljati štiri stvari: pravilo za partnerja navaja natanko en naslov, DNS ima imenovano izjemo, omogočanje je prišlo po dovoljenjih in vlečenje tunela ubije običajen promet, ne da bi odjemalca dokončno ubilo.