Slijedili ste kontrolni popis: zabranite izlazni, dopustite tunel, omogućite ufw. Zatim klijent čeka na rukovanju i nikada se ne povezuje, ili se poveže i nijedna stranica se ne učita. Obje pogreške dolaze iz iste praznine. Nedostaje pravilo koje dopušta postojanje tunela, jer tunel nije sučelje iz kojeg vaši paketi izlaze.

Zašto dopuštenje na tun0 isprva ništa ne pogađa

tun0 stvara klijent nakon što sesija postoji. Datagrami koji grade tu sesiju obični su UDP paketi upućeni pružatelju na port 1194 i izlaze kroz wlan0 ili eth0 s fizičkom izvornom adresom. allow out on tun0 pogađa samo promet čije je izlazno sučelje tun0, pa se tijekom rukovanja ne pogađa baš ništa.

Stavite default deny outgoing povrh toga i vanjski paketi se odbacuju prije nego se sučelje uopće pojavi. Klijent pokušava ponovno, istječe vrijeme i prijavljuje TLS ili grešku rukovanja, što ljude šalje u lov po certifikatima i MTU-u dok vatrozid tiho jede vezu. Pravilo koje je trebalo zadržati vaš promet sprječava da se taj promet zadrži.

Refleksno rješenje čini curenje trajnim. sudo ufw allow out on wlan0, ili vraćanje zadanog na dopuštenje, podiže tunel i ostavlja stroj bez prekidača: sljedeći put kada tunel padne, sve se nastavlja preko fizičkog adaptera. Izgubio sam poslijepodne upravo na taj par izmjena prije nego što sam shvatio koji paket zapravo filtriram.

Što trebaju dva skupa paketa

Vaš promet prelazi vatrozid dvaput, u dva oblika. Unutarnji paket ide od adrese tunela kroz tun0. Vanjski paket ide od fizičke adrese do parnjaka i jedino je što je vidljivo na žici. Jedno pravilo po obliku:

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'

Zamijenite adresu i port onima iz vlastitog profila. WireGuard parnjaci obično odgovaraju na 51820/udp; OpenVPN profili koji idu preko TCP 443 trebaju taj port umjesto toga. Pojedinosti se razlikuju, oblik ne: oba pravila su uska i zajedno određuju jedine odredišta do kojih stroj može doći dok je tunel pao.

Redoslijed je drugi mit. Sirovim iptablesom čitate lanac odozgo prema dolje i zaključujete koje pravilo pobjeđuje. ufw nije tanka omotnica oko popisa koji ste otipkali; on prevodi vaša pravila u svoje lance i bira točke umetanja. ufw status ispisuje ih u ufw redoslijedu, ne vašem. Kada pravilo izgleda zanemareno, usporedite ufw show added s prevedenim skupom iz iptables -S | grep ufw prije nego što bilo što prepišete.

Iznimka mora ostati široka jednu adresu

Pravilo za parnjaka ispravno je samo dok imenuje adresu koju klijent poziva. Pružatelji okreću završne točke, a profil koji razrješava ime hosta slijedit će promjenu DNS-a na novu adresu dok pravilo nastavlja pokazivati na staru. Kada tunel koji je mjesecima radio prestane dizati se, usporedite adresu u pravilu s onom koju klijent traži prije nego što bilo što proširite.

Proširenje na cijelu podmrežu, ili na svako odredište na portu 1194, vraća politiku u vatrozid s rupom. Iznimka je prekidač; kad je širok, nema više što prekinuti. Držite ga na jednoj adresi i ostavite komentar koji imenuje profil i pružatelja kojem pripada, jer će za šest mjeseci adresa izgledati proizvoljno.

Razrješavanje imena zaslužuje svoj redak. Pretraga se događa prije nego tunel postoji, preko fizičkog sučelja, pa stroga politika zabrane izlaznog može ostaviti klijent nesposobnim pronaći vlastiti poslužitelj. Dopustite port 53 na adresu svog razrješivača, ili razriješite jednom i prikujte adresu u profilu. Dopuštanje DNS-a na svakom sučelju odluka je, ne zadano.

Izgradite politiku prije nego tunel zatreba

ufw enable primjenjuje cijelu politiku odjednom i ponovno učitava svoje lance, a promjena zadane politike na pokrenutom vatrozidu također ih ponovno učitava. ufw priručnik upozorava da to može odbaciti postojeće veze poput SSH-a. Zato naredbe idu ovim redom, s SSH pravilom prije omogućavanja i otvorenom konzolnom sesijom:

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 namjerno je izostavljen iz tog bloka. Briše svako pravilo i onemogućuje vatrozid, a na udaljenom hostu sljedeće omogućavanje je ono što odbacuje vašu sesiju. Ako ipak resetirate, dodajte SSH pravilo i potvrdite drugi put natrag kroz konzolu prije nego što nastavite.

Redoslijed nije kozmetički. Pravila dodana dok ufw radi ne ispiraju ništa, ali u trenutku kada okrenete zadanu politiku lanci se ponovno učitavaju, a sesija koju je stara politika dopuštala ide s njima. Učinite zadane, dopuštenja i omogućavanje u jednom prolazu, dok još imate put unutra koji ne ovisi o stroju.

Testirajte blokirano stanje i sačuvajte poništenje

Netestiran prekidač je nagađanje. Namjerno isključite klijent i pokušajte učitati stranicu: mora neuspjeti. Ponovno se povežite i mora se oporaviti bez diranja pravila. sudo ufw status verbose potvrđuje zadane i stanje bilježenja, a ufw status numbered pokazuje koje testno pravilo izbrisati kada nadživi svoju svrhu.

Držite obrnutu skriptu pokraj prednje. Stroj sa zabranom izlaznog i mrtvim tunelom ne može preuzeti vlastiti popravak, pa poništenje mora stajati na disku i biti čitljivo s konzole:

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

Pokrenite ga kada je tunel već pao i pravila se moraju skinuti, ne kao rutinski korak. Prije nego što zatvorite terminal, četiri stvari moraju vrijediti: pravilo za parnjaka imenuje točno jednu adresu, DNS ima imenovanu iznimku, omogućavanje je došlo poslije dopuštenja, a povlačenje tunela ubija običan promet bez trajnog ubijanja klijenta.

Povezani članci