UFW zhodí DNS server VPN, len čo sa tunel zdvihne
Politika predvoleného odmietnutia v UFW pokrýva aj rozhranie tunela. Zoraďte prevádzku podľa smeru, povoľte pretlačený prekladač na tun0 a potom otvorte vonkajšiu cestu.
Mená sa prestanú prekladať v okamihu, keď sa VPN pripojí, pričom ping na verejnú adresu ešte odpovedá a stav firewallu neukazuje nič, čo by vyzeralo nesprávne. V politike sa nezmenilo nič; zmenilo sa to, že sa objavilo nové rozhranie, a predvolené odmietnutie ho pokrýva od prvého paketu. UFW rozhoduje podľa smeru a rozhrania, takže pravidlo napísané pre bezdrôtové spojenie nehovorí nič o prevádzke, ktorá opúšťa tunel. Oprava je hrsť úzkych pravidiel použitých v určitom poradí.
Príznak sa objaví až po zdvihnutí tunela
Politika predvoleného odmietnutia robí presne to, čo jej bolo povedané: všetko bez zodpovedajúceho pravidla je odmietnuté, na každom existujúcom rozhraní. Tunel neexistoval, keď sa písali pravidlá, preto ho žiadne z nich nemôže zachytiť, a odmietnutie, ktoré tam bolo vždy, sa teraz vzťahuje na preklad mien. Priama prevádzka na doslovnú adresu môže stále fungovať, keď ju pokrýva širšie povolenie, a preto ping na verejný prekladač uspeje, kým hľadanie mena zlyhá. Medzera je pravidlo pre rozhranie, ktoré politika nikdy nevidela.
To tiež vysvetľuje, prečo sa zlyhanie čisto obráti: zložte tunel a mená sa znovu preložia, pretože dopyt sa vracia na rozhranie, ktoré pravidlá má. Politika, ktorá zlyháva len pri zdvihnutom tuneli, nie je problém DNS, a ladenie samotného prekladača tu stráca najviac času. Prečítajte si zoznam rozhraní skôr, než prečítate konfiguráciu prekladača.
Tri smery, tri rôzne sady pravidiel
Jedna relácia sa dotýka pravidiel vo viac ako jednom smere a tunel pridáva druhé rozhranie takmer ku každému z nich. Ak najprv zoradíte prevádzku podľa smeru a rozhrania, zvyšok sa stane mechanickým, pretože každý riadok nižšie potrebuje svoje vlastné pravidlo na svojom mieste. Príklady používajú tun0 a fond 10.8.0.0/24, preto nahraďte názvy a rozsahy tými z vlastného výstupu klienta.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
Dva riadky sa často zamieňajú, pretože oba spomínajú tunel. Pravidlo pre prekladač povoľuje prevádzku, ktorú klient posiela do tunela, zatiaľ čo pravidlo pre SSH povoľuje prevádzku, ktorú server odtiaľ prijíma; žijú na rôznych strojoch a zlyhávajú nezávisle. Riadok, na ktorý sa najčastejšie zabúda, je druhý, pretože klient vôbec nemôže tunel vytvoriť, kým nie je povolená jeho prevádzka na verejnú adresu servera. Pracujte zhora nadol a každé zlyhanie má jednu pravdepodobnú príčinu.
Pretlačený prekladač potrebuje vlastné pravidlo
Či tunel nesie DNS, závisí od toho, čo server posiela. Server, ktorý pretlačí voľbu prekladača, nainštaluje do konfigurácie klienta súkromnú adresu a táto adresa je smerovateľná len cez tunel. Ak server nič nepretlačí, klient si ponechá prekladač, ktorý už mal, a pravidlá nižšie nemajú čo povoliť. Pred písaním čohokoľvek skontrolujte pretlačený stav a aktuálny výsledok dopytu:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedVýstup stavu pomenuje používaný prekladač a spojenie, ku ktorému je pripútaný, a hľadanie trasy za ním ukáže, ktoré rozhranie by dopyt na tú adresu nieslo. Keď prekladač sedí na inom spojení, problém je skôr než firewall a žiadne pravidlo nepomôže. Keď sa oba zhodnú na tuneli, sú potrebné dve pravidlá, pretože UDP nesie väčšinu dopytov a TCP preberá, keď je odpoveď skrátená. Zapíšte obe hodnoty, pretože práve tie pravidlá pomenujú:
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'Otvorte vonkajšiu cestu skôr než vnútornú
Klient sa musí dostať na verejnú adresu servera skôr, než tunel existuje, takže pravidlo pre ňu sedí na fyzickom spojení a musí byť na mieste prvé. Politika, ktorá povolí prekladač, ale zabudne server, nechá klienta úplne neschopného tunel postaviť, a tento príznak sa zvyčajne zvaľuje na kill switch. Potom povoľte služby, ktoré ste naozaj chceli cez tunel, po jednom úzkom pravidle, namiesto otvorenia rozhrania celého. Úzke pravidlá sú dôvodom, prečo môže odmietnutie zostať na mieste.
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'Poradie je pri testovaní dôležité, pretože prvé pravidlo je to, čo tunelu vôbec dovolí zdvihnúť sa. Pridajte ho, pripojte sa a potvrďte, že tunel je zdvihnutý, skôr než pridáte pravidlo služby, pretože robiť oboje naraz znamená, že zlyhanie nič nepovie o tom, ktorá polovica je nesprávna. Nahraďte dokumentačnú adresu vyššie koncovým bodom, pre ktorý je klient nakonfigurovaný.
Dokončite klientsku stranu tým, že sa zámerne odpojíte. Odmietnutie by stále malo odmietať prevádzku, ktorú ste zámerne vylúčili, pretože prekladač, ktorý odpovedá pri zdvihnutom tuneli, pokrýva len polovicu politiky, ktorá pri pochybnosti odmieta.
Klient, ktorý sa pripojí, ešte nie je vpustený
Server má vlastný smer, ktorý treba zvážiť, a klient, ktorý dokončí handshake, sa stále nedostane na nič, čo na serveri beží, kým ho server nevpustí. Pravidlo verejného listenera dovoľuje len existenciu tunela; nepúšťa prevádzku tunela dnu. Na serveri sú to dve pravidlá plus jedna kontrola, že služba skutočne načúva:
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'Fond v pravidle sa musí rovnať rozsahu, ktorý server prideľuje, a číslo tunela musí zodpovedať tomu, ktoré server vytvoril, pretože pravidlo pre iné rozhranie je nerozoznateľné od žiadneho pravidla. limit je zámerné pre administratívny port, pretože obmedzuje opakované pripojenia namiesto toho, aby ich prijímalo bez limitu. Kontrola listenera oddeľuje zatvorený port od zahodeného paketu, ktoré z pohľadu klienta vyzerajú rovnako. Ani číslované pravidlá nie sú celý obraz: pravidlá before v UFW a každý ručne napísaný riadok nftables sa zhodujú skôr a stále môžu odmietnuť paket, ktorý zoznam zdanlivo povoľuje.