UFW zavrže DNS strežnik VPN, takoj ko se tunel dvigne

Imena se prenehajo razreševati v trenutku, ko se VPN poveže, medtem ko ping na javni naslov še vedno odgovarja in stanje požarnega zidu ne kaže ničesar, kar bi bilo videti narobe. V politiki se ni spremenilo nič; spremenilo se je to, da se je pojavil nov vmesnik, in privzeta zavrnitev ga pokriva od prvega paketa. UFW odloča po smeri in vmesniku, zato pravilo, napisano za brezžično povezavo, ne pove ničesar o prometu, ki zapušča tunel. Popravilo je peščica ozkih pravil, uporabljenih v določenem vrstnem redu.

Simptom se pojavi šele po tem, ko se tunel dvigne

Politika privzete zavrnitve dela točno to, kar ji je bilo rečeno: vse brez ustreznega pravila je zavrnjeno, na vsakem obstoječem vmesniku. Tunela ni bilo, ko so bila pravila napisana, zato ga nobeno od njih ne more ujeti, in zavrnitev, ki je bila vedno tam, zdaj velja za razreševanje imen. Neposreden promet na dobesedni naslov lahko še vedno deluje, ko ga pokriva širše dovoljenje, in zato ping na javni razreševalnik uspe, medtem ko iskanje imena spodleti. Vrzel je pravilo za vmesnik, ki ga politika ni nikoli videla.

To tudi pojasni, zakaj se napaka čisto obrne: odstranite tunel in imena se znova razrešijo, ker se poizvedba vrne na vmesnik, ki ima pravila. Politika, ki spodleti le, ko je tunel dvignjen, ni težava DNS, in nastavljanje samega razreševalnika tukaj zapravi največ časa. Preberite seznam vmesnikov, preden preberete konfiguracijo razreševalnika.

Tri smeri, trije različni nabori pravil

Ena seja se dotika pravil v več kot eni smeri, in tunel doda drugi vmesnik skoraj vsakemu od njih. Če promet najprej razvrstite po smeri in vmesniku, postane ostalo mehansko, ker vsaka vrstica spodaj potrebuje svoje pravilo na svojem mestu. Primeri uporabljajo tun0 in nabor 10.8.0.0/24, zato zamenjajte imena in obsege s tistimi iz lastnega izpisa odjemalca.

Dve vrstici se pogosto zamenjujeta, ker obe omenjata tunel. Pravilo za razreševalnik dovoli promet, ki ga odjemalec pošlje v tunel, medtem ko pravilo za SSH dovoli promet, ki ga strežnik prejme od tam; živita na različnih strojih in spodletita neodvisno. Vrstica, ki se najpogosteje pozabi, je druga, ker odjemalec sploh ne more zgraditi tunela, dokler ni dovoljen njegov promet na javni naslov strežnika. Delajte od zgoraj navzdol in vsaka napaka ima en možen vzrok.

Potisnjeni razreševalnik potrebuje svoje pravilo

Ali tunel nosi DNS, je odvisno od tega, kaj pošlje strežnik. Strežnik, ki potisne možnost razreševalnika, namesti zasebni naslov v konfiguracijo odjemalca, in ta naslov je usmerljiv le skozi tunel. Če strežnik ne potisne ničesar, odjemalec obdrži razreševalnik, ki ga je že imel, in pravila spodaj nimajo česa dovoliti. Preden karkoli napišete, preverite potisnjeno stanje in trenutni rezultat poizvedbe:

dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numbered

Izpust stanja navede uporabljeni razreševalnik in povezavo, na katero je vezan, iskanje poti za njim pa pokaže, kateri vmesnik bi nosil poizvedbo na ta naslov. Ko razreševalnik sedi na drugi povezavi, je težava prej kot požarni zid in nobeno pravilo ne bo pomagalo. Ko se oba strinjata glede tunela, sta potrebni dve pravili, ker UDP nosi večino poizvedb, TCP pa prevzame, ko je odgovor skrajšan. Zapišite obe vrednosti, ker ju bodo pravila navedla:

sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'

Odprite zunanjo pot pred notranjo

Odjemalec mora doseči javni naslov strežnika, preden tunel obstaja, zato pravilo zanj sedi na fizični povezavi in mora biti prvo na svojem mestu. Politika, ki dovoli razreševalnik, a pozabi strežnik, pusti odjemalca popolnoma nezmožnega zgraditi tunel, in ta simptom se običajno pripiše kill switchu. Nato dovolite storitve, ki ste jih resnično želeli skozi tunel, po eno ozko pravilo naenkrat, namesto da bi vmesnik odprli v celoti. Ozka pravila so razlog, da lahko zavrnitev ostane na svojem mestu.

sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'

Vrstni red je pri testiranju pomemben, ker je prvo pravilo tisto, ki tunelu sploh dovoli, da se dvigne. Dodajte ga, povežite se in potrdite, da je tunel dvignjen, preden dodate pravilo storitve, ker storiti oboje hkrati pomeni, da napaka ne pove ničesar o tem, katera polovica je napačna. Zamenjajte dokumentacijski naslov zgoraj s končno točko, za katero je odjemalec konfiguriran.

Zaključite odjemalčevo stran z namerno prekinitvijo povezave. Zavrnitev bi morala še vedno zavrniti promet, ki ste ga namerno izključili, ker razreševalnik, ki odgovarja, ko je tunel dvignjen, pokrije le polovico politike, ki ob dvomu zavrne.

Odjemalec, ki se poveže, še ni sprejet

Strežnik mora upoštevati svojo smer, in odjemalec, ki dokonča rokovanje, še vedno ne doseže ničesar, kar teče na strežniku, dokler ga strežnik ne sprejme. Pravilo javnega poslušalca dovoli tunelu le, da obstaja; ne spusti prometa tunela noter. Na strežniku sta to dve pravili plus ena preveritev, da storitev resnično posluša:

sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'

Nabor v pravilu mora biti enak obsegu, ki ga strežnik dodeli, in številka tunela se mora ujemati s tisto, ki jo je ustvaril strežnik, ker pravilo za drug vmesnik ni razločljivo od nobenega pravila. limit je namerno za upravljalna vrata, ker omejuje ponavljajoče se povezave, namesto da bi jih sprejemalo brez omejitve. Preveritev poslušalca loči zaprta vrata od zavrženega paketa, ki sta z vidika odjemalca videti enako. Tudi oštevilčena pravila niso vsa slika: pravila before v UFW in vsaka ročno napisana vrstica nftables se ujemajo prej in lahko še vedno zavrnejo paket, ki ga seznam očitno dovoljuje.