UFW odbacuje DNS server VPN-a čim se tunel podigne

Imena prestaju da se razrješavaju u trenutku kada se VPN poveže, dok ping na javnu adresu još uvijek odgovara, a status firewall-a ne pokazuje ništa što izgleda pogrešno. U politici se ništa nije promijenilo; promijenilo se to da se pojavilo novo sučelje, a podrazumijevano odbijanje ga pokriva od prvog paketa. UFW odlučuje po smjeru i sučelju, pa pravilo napisano za bežični link ne govori ništa o prometu koji izlazi iz tunela. Popravka je šačica uskih pravila primijenjenih u određenom redoslijedu.

Simptom se pojavljuje tek nakon što se tunel podigne

Politika podrazumijevanog odbijanja radi tačno ono što joj je rečeno: sve bez odgovarajućeg pravila se odbija, na svakom sučelju koje postoji. Tunel nije postojao kada su pravila pisana, pa nijedno od njih ne može da ga pokrije, a odbijanje koje je oduvijek bilo tu sada se primjenjuje na razrješavanje imena. Direktan promet na doslovnu adresu još može raditi kada ga pokriva šire dopuštenje, zbog čega ping na javni razrješivač uspijeva dok traženje imena ne uspijeva. Praznina je pravilo za sučelje koje politika nikada nije vidjela.

To također objašnjava zašto se kvar čisto poništava: spustite tunel i imena se ponovo razrješavaju, jer se upit vraća na sučelje koje ima pravila. Politika koja ne uspijeva samo dok je tunel podignut nije DNS problem, a podešavanje samog razrješivača ovdje gubi najviše vremena. Pročitajte listu sučelja prije nego što pročitate konfiguraciju razrješivača.

Tri smjera, tri različita skupa pravila

Jedna sesija dotiče pravila u više od jednog smjera, a tunel dodaje drugo sučelje gotovo svakom od njih. Ako prvo sortirate promet po smjeru i sučelju, ostatak postaje mehanički, jer svaki red ispod traži vlastito pravilo na vlastitom mjestu. Primjeri koriste tun0 i skup 10.8.0.0/24, pa zamijenite imena i raspone onima iz vlastitog izlaza klijenta.

Dva reda se često brkaju jer oba spominju tunel. Pravilo za razrješivač dopušta promet koji klijent šalje u tunel, dok pravilo za SSH dopušta promet koji server odatle prima; ona žive na različitim mašinama i nezavisno ne uspijevaju. Red koji se najčešće zaboravlja je drugi, jer klijent uopće ne može uspostaviti tunel dok njegov promet na javnu adresu servera nije dopušten. Radite odozgo prema dolje i svaki kvar ima jedan vjerojatan uzrok.

Gurnuti razrješivač traži vlastito pravilo

Da li tunel nosi DNS zavisi od toga šta server šalje. Server koji gura opciju razrješivača instalira privatnu adresu u konfiguraciju klijenta, a ta adresa je rutabilna samo kroz tunel. Ako server ne gura ništa, klijent zadržava razrješivač koji je već imao i pravila ispod nemaju šta dopustiti. Provjerite gurnuto stanje i trenutni rezultat upita prije nego što bilo šta napišete:

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

Izlaz statusa imenuje razrješivač koji se koristi i link na koji je vezan, a traženje rute iza njega pokazuje koje bi sučelje nosilo upit na tu adresu. Kada razrješivač sjedi na drugom linku, problem je ranije od firewall-a i nijedno pravilo neće pomoći. Kada se oba slože oko tunela, potrebna su dva pravila, jer UDP nosi većinu upita a TCP preuzima kada je odgovor skraćen. Zapišite obje vrijednosti, jer su to one koje će pravila imenovati:

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'

Otvorite vanjski put prije unutrašnjeg

Klijent mora doći do javne adrese servera prije nego što tunel postoji, pa pravilo za nju sjedi na fizičkom linku i mora biti na mjestu prvo. Politika koja dopušta razrješivač ali zaboravlja server ostavlja klijenta potpuno nesposobnim da izgradi tunel, a taj simptom se obično pripisuje kill switch-u. Zatim dopustite usluge koje ste zaista htjeli kroz tunel, po jedno usko pravilo odjednom, umjesto da otvorite sučelje u cjelini. Uska pravila su razlog zašto odbijanje može ostati na mjestu.

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'

Redoslijed je važan dok testirate, jer prvo pravilo je ono koje uopće pušta tunel da se podigne. Dodajte ga, povežite se i potvrdite da je tunel podignut prije nego što dodate pravilo usluge, jer raditi oboje odjednom znači da kvar ne govori ništa o tome koja je polovina pogrešna. Zamijenite adresu iz dokumentacije iznad krajnjom točkom za koju je klijent konfigurisan.

Završite stranu klijenta tako što ćete se namjerno odspojiti. Odbijanje bi i dalje trebalo odbijati promet koji ste namjerno izuzeli, jer razrješivač koji odgovara dok je tunel podignut pokriva samo polovinu politike koja odbija u slučaju sumnje.

Klijent koji se poveže još nije dopušten

Server ima vlastiti smjer koji treba razmotriti, a klijent koji završi rukovanje još ne može doći do ničega što radi na serveru dok ga server ne dopusti. Pravilo javnog slušatelja samo dopušta postojanje tunela; ono ne pušta promet tunela unutra. Na serveru su to dva pravila plus jedna provjera da usluga zaista sluš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'

Skup u pravilu mora biti jednak rasponu koji server dodjeljuje, a broj tunela mora odgovarati onom koji je server stvorio, jer se pravilo za drugo sučelje ne razlikuje od nikakvog pravila. limit je namjerno za administrativni port, jer ograničava ponovljene veze umjesto da ih prima bez ograničenja. Provjera slušatelja razdvaja zatvoren port od odbačenog paketa, koji izgledaju identično sa strane klijenta. Numerisana pravila također nisu cijela slika: UFW-ova before pravila i svi ručno napisani nftables redovi podudaraju se ranije i još mogu odbiti paket koji lista naizgled dopušta.