Prešli ste kontrolný zoznam: zakážte odchádzajúci, povoľte tunel, zapnite ufw. Potom klient čaká na handshake a nikdy sa nepripojí, alebo sa pripojí a nenačíta sa žiadna stránka. Obe zlyhania pochádzajú z tej istej medzery. Chýba pravidlo, ktoré tunelu umožňuje existovať, pretože tunel nie je rozhranie, cez ktoré odchádzajú vaše pakety.

Prečo povolenie na tun0 najprv ničomu nezodpovedá

tun0 vytvára klient po tom, ako existuje relácia. Datagramy, ktoré túto reláciu stavajú, sú obyčajné UDP pakety adresované poskytovateľovi na port 1194 a odchádzajú cez wlan0 alebo eth0 s fyzickou zdrojovou adresou. allow out on tun0 zodpovedá len prevádzke, ktorej odchádzajúce rozhranie je tun0, takže počas handshake nezodpovedá vôbec ničomu.

Dajte default deny outgoing navrch a vonkajšie pakety sa zahodia skôr, než sa rozhranie vôbec objaví. Klient to skúša znova, vyprší časový limit a ohlási zlyhanie TLS alebo handshake, čo pošle ľudí pátrať po certifikátoch a MTU, zatiaľ čo firewall potichu požiera spojenie. Pravidlo, ktoré malo vašu prevádzku udržať, bráni tomu, aby sa tá prevádzka udržala.

Reflexná oprava robí únik trvalým. sudo ufw allow out on wlan0, alebo prepnutie predvoleného nastavenia späť na povoliť, zdvihne tunel a nechá stroj bez núdzového vypínača: nabudúce, keď tunel spadne, všetko pokračuje cez fyzický adaptér. Stratil som popoludnie presne na tej dvojici úprav, kým som zistil, ktorý paket vlastne filtrujem.

Čo obe sady paketov potrebujú

Vaša prevádzka prechádza firewallom dvakrát, v dvoch podobách. Vnútorný paket ide z adresy tunela von cez tun0. Vonkajší paket ide z fyzickej adresy k partnerovi a je jediné, čo je na drôte vidieť. Jedno pravidlo na podobu:

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'

Nahraďte adresu a port tými zo svojho profilu. Partneri WireGuard zvyčajne odpovedajú na 51820/udp; profily OpenVPN idúce cez TCP 443 potrebujú namiesto toho tento port. Podrobnosti sa líšia, podoba nie: obe pravidlá sú úzke a spolu určujú jediné ciele, ktoré stroj dosiahne, kým tunel nebeží.

Poradie je druhý mýtus. Pri surovom iptables čítate reťaz zhora nadol a uvažujete, ktoré pravidlo vyhrá. ufw nie je tenký obal okolo zoznamu, ktorý ste napísali; kompiluje vaše pravidlá do vlastných reťazí a vyberá miesta vloženia. ufw status vypisuje ich v poradí ufw, nie vašom. Keď pravidlo vyzerá ignorované, porovnajte ufw show added s preloženou sadou z iptables -S | grep ufw skôr, než čokoľvek prepíšete.

Výnimka musí zostať široká jednu adresu

Pravidlo pre partnera je správne len dovtedy, kým menuje adresu, na ktorú klient vytáča. Poskytovatelia rotujú koncové body a profil, ktorý prekladá názov hostiteľa, bude nasledovať zmenu DNS na novú adresu, zatiaľ čo pravidlo ďalej ukazuje na starú. Keď tunel, ktorý mesiace fungoval, prestane nabiehať, porovnajte adresu v pravidle s tou, ktorú klient hľadá, skôr než čokoľvek rozšírite.

Rozšírenie na celú podsiete alebo na každý cieľ na porte 1194 premení politiku späť na firewall s dierou. Výnimkou je núdzový vypínač; keď je široký, nezostáva čo vypnúť. Držte ho na jednej adrese a nechajte komentár s názvom profilu a poskytovateľa, ktorému patrí, pretože o pol roka bude adresa vyzerať ľubovoľne.

Preklad názvov si zaslúži vlastný riadok. Vyhľadanie prebieha skôr, než tunel existuje, cez fyzické rozhranie, takže prísna politika zákazu odchádzajúceho provozu môže nechať klienta neschopného nájsť vlastný server. Povoľte port 53 na adresu vášho resolvera, alebo raz preložte a adresu pripnite v profile. Povolenie DNS na každom rozhraní je rozhodnutie, nie predvolené nastavenie.

Postavte politiku skôr, než bude tunel potrebný

ufw enable uplatní celú politiku naraz a znovu načíta svoje reťaze, a zmena predvolenej politiky na bežiacom firewalle ich tiež znovu načíta. ufw manuál varuje, že to môže zhodiť existujúce spojenia ako SSH. Preto idú príkazy v tomto poradí, s pravidlom SSH pred zapnutím a otvorenou konzolovou reláciou:

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 z toho bloku zámerne vynechaný. Zmaže každé pravidlo a vypne firewall, a na vzdialenom hostiteľovi je to nasledujúce zapnutie, čo zhodí vašu reláciu. Ak napriek tomu resetujete, pridajte pravidlo SSH a pred ďalším krokom potvrďte druhú cestu späť cez konzolu.

Poradie nie je kozmetické. Pravidlá pridané počas behu ufw nič nevypláchnu, ale v momente, keď prepnete predvolenú politiku, sa reťaze znovu načítajú a relácia, ktorú stará politika povoľovala, ide s nimi. Urobte predvolené nastavenia, povolenia a zapnutie v jednom prechode, kým máte ešte cestu dovnútra, ktorá nezávisí od stroja.

Otestujte zablokovaný stav a ponechajte zrušenie

Neotestovaný núdzový vypínač je dohad. Odpojte klienta zámerne a skúste načítať stránku: musí zlyhať. Pripojte sa znova a musí sa zotaviť bez dotknutia sa pravidla. sudo ufw status verbose potvrdzuje predvolené nastavenia a stav protokolovania, a ufw status numbered ukazuje, ktoré testovacie pravidlo zmazať, keď prežije svoj účel.

Držte opačný skript vedľa priameho. Stroj so zákazom odchádzajúceho a mŕtvym tunelom si nemôže stiahnuť vlastnú opravu, takže zrušenie musí ležať na disku a byť čitateľné z konzoly:

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

Spustite ho, keď tunel už spadol a pravidlá musia ísť dole, nie ako rutinný krok. Pred zatvorením terminálu musia platiť štyri veci: pravidlo pre partnera menuje presne jednu adresu, DNS má pomenovanú výnimku, zapnutie prišlo po povoleniach a stiahnutie tunela zabije bežnú prevádzku bez toho, aby klienta navždy zabilo.

Súvisiace články