Opravte DNS hosťa libvirt blokovaný firewallom VPN založeným na značkách

Hostia v predvolenej sieti libvirt prekladajú názvy dokonale, kým sa neobjaví rozhranie WireGuard, a potom sa každé vyhľadanie zasekne na tom istom mieste. dnsmasq stále počúva na 192.168.122.1:53, hosť má stále túto adresu ako resolver a dopyt stále prichádza. Zmenilo sa to, že vlastný nadradený dopyt hostiteľa alebo odpoveď naň teraz zahadzuje pravidlo, ktoré sa vyhodnocuje skôr než ktorýkoľvek reťazec filtrov, ktorý by ste chceli upraviť. Východiskom je značka nasadená dosť skoro, na spojení, ktoré odpoveď dedí.

Hostia stratia DNS v okamihu, keď sa tunel zdvihne

Potvrďte tvar, skôr než čokoľvek zmeníte. Zložte tunel, spustite dig @192.168.122.1 example.com z hosťa a sledujte, ako odpovedá. Zdvihnite tunel, zopakujte a sledujte, ako vyprší. Táto dvojica výsledkov v jednom kroku vylúči pokazenú sieť libvirt, nesprávnu adresu resolvera a mŕtvy dnsmasq.

Potom sa pozrite na stranu hostiteľa. Ak dnsmasq loguje dopyt a jeho nadradené preposlanie, paket dorazil a zlyhanie je na výstupe. Ak dnsmasq neloguje nič, dopyt hosťa sa zahadzuje na vstupe a výnimka patrí inému hooku, než aký označuje tento článok.

Prečo pravidlo accept v neskoršom reťazci nikdy nezaberie

Firewall VPN založený na značkách rozhoduje pohľadom na značku paketu alebo značku spojenia, nie na vašu zdrojovú adresu. Všetko, čo príde na fyzické rozhranie bez očakávanej značky, je odmietnuté, a toto odmietnutie sa deje v množine pravidiel, ktorá vlastní test značky. ip saddr 192.168.122.0/24 accept riadok pridaný do akéhokoľvek neskoršieho reťazca sa pre ten paket jednoducho nikdy neberie do úvahy, preto zjavné pravidlo vyzerá správne a nič nemení.

Rozširovanie, kým niečo nezačne fungovať, je druhá pasca. Prijatie celej podsiete libvirt na vstupnej ceste hostiteľa otvorí každú službu hostiteľa hosťom, hoci skutočná potreba je jeden port.

Mechanizmom, ktorý umožňuje úzku výnimku, je sledovanie spojení. Keď nastavíte ct mark na paket, hodnota sa uloží do záznamu conntrack a nie iba na paket, takže každý paket toho spojenia ju potom nesie, vrátane odpovede z hostiteľa späť hosťovi. To je celý trik: označte žiadosť raz a spiatočná cesta je už označená.

Označte dopyt skôr, než ho uvidí tabuľka VPN

Umiestnite výnimku do vlastnej tabuľky, aby ju neskorší čitateľ našiel bez parsovania pravidiel VPN:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle je záporná, čo tento reťazec stavia pred bežné reťazce filtrov, ktoré balík VPN inštaluje s prioritou nula. Práve poradie hookov robí pravidlo účinným; to isté pravidlo v reťazci, ktorý sa radí za reťazcom VPN, je len dekorácia.

Samotné číslo značky nie je prenosné. Vezmite hodnotu, ktorú nainštalované pravidlá VPN akceptujú pre svoju vlastnú prevádzku, prečítajte ju zo živého súboru pravidiel a použite ju. Nesprávna značka vytvorí pravidlo, ktoré sa načíta čisto, zhoduje sa s každým dopytom a nič nepustí.

Držte dieru na šírku portu 53

Ako je napísané, toto povoľuje DNS z podsiete libvirt na hostiteľa cez TCP alebo UDP port 53 a nič iné. Nepustí hostí na internet mimo tunela a nepustí hostiteľa otvárať spojenia smerom k hosťom. Ak hosť neskôr bude potrebovať inú službu hostiteľa, pridajte samostatné pravidlo pomenúvajúce ten cieľový port namiesto uvoľnenia tohto.

Buďte úprimní v tom, čo vymieňate. Hosť, ktorý dosiahne resolver, môže tiež tunelovať ľubovoľné dáta cez DNS dopyty, a táto výnimka je zámerná diera v hranici VPN, nie vyhlásenie, že lokálna sieť je dôveryhodná. Obmedzenie zdroja na 192.168.122.0/24 drží dieru ďalej od každej inej lokálnej podsiete a počítanie dopytov z tohto zdroja je lacné, ak je pre vás hrozba dôležitá.

Zabezpečte, aby to prežilo reštart, a dokážte obe polovice

Pravidlo napísané na príkazovom riadku zmizne pri ďalšom štarte a pravidlo načítané po tom, čo rozhranie VPN už prepúšťa prevádzku, prehrá pretek na prvom spojení. Umiestnite tabuľku do trvalej konfigurácie nftables hostiteľa alebo do jednotky zoradenej pred službou VPN, a poradie skontrolujte, namiesto toho, aby ste ho predpokladali.

Overenie potrebuje tri samostatné odpovede. Potvrďte, že reťazec je načítaný a zoradený prvý, potvrďte, že záznam conntrack ukazuje značku v oboch smeroch, a potvrďte, že vyhľadanie z hosťa vráti adresu. Potom potvrďte druhú polovicu: bežná webová prevádzka hosťa na verejného hostiteľa stále zlyháva, kým je tunel zložený alebo blokuje. Ak DNS funguje a všetko ostatné presakuje, vaše pravidlo je širšie než to vyššie.

Ak vyhľadania stále zlyhávajú po nasadení značky, odolajte nutkaniu rozšíriť zdroj. Skontrolujte, kam dnsmasq preposiela, či resolver hosťa ukazuje na 192.168.122.1 alebo na verejnú adresu, ktorú niekto napísal, a či sa dopyt vôbec dostane k hostiteľovi. Označovanie pustí paket a nič iné, takže zlý nadradený server alebo pokazená virtuálna sieť zostanú pokazené, nech pridáte akokoľvek veľa pravidiel.