Oprava DNS hosta v libvirtu blokovaného VPN firewallem založeným na značkách

Hosté na výchozí síti libvirt překládají jména bezchybně, dokud se nezvedne rozhraní WireGuard, a pak se každé vyhledávání zasekne na stejném místě. dnsmasq stále naslouchá na 192.168.122.1:53, host stále používá tuto adresu jako svůj resolver a dotaz stále přichází. Změnilo se to, že vlastní upstream dotaz hostitele, nebo odpověď na něj, je nyní zahazován pravidlem, které se vyhodnocuje dříve než jakýkoli řetězec filtrů, který byste chtěli upravit. Cesta ven je značka aplikovaná dostatečně brzy, na spojení, které odpověď dědí.

Hosté ztratí DNS ve chvíli, kdy se tunel zvedne

Než cokoli změníte, potvrďte tvar. Sundejte tunel, spusťte dig @192.168.122.1 example.com z hosta a sledujte, jak odpovídá. Zvedněte tunel, opakujte a sledujte, jak vyprší časový limit. Tato dvojice výsledků v jednom kroku vylučuje rozbitou síť libvirt, špatnou adresu resolveru i mrtvý dnsmasq.

Potom se podívejte na stranu hostitele. Pokud dnsmasq zaznamená dotaz a jeho upstream předání, paket dorazil a selhání je na výstupu. Pokud dnsmasq nezaznamená nic, dotaz hosta je zahazován na vstupu a výjimka patří na jiný hook, než který tento článek označuje.

Proč se pravidlo accept v pozdějším řetězci nikdy nespustí

VPN firewall založený na značkách rozhoduje podle značky paketu nebo značky spojení, ne podle vaší zdrojové adresy. Vše, co dorazí na fyzické rozhraní bez očekávané značky, je odmítnuto, a toto odmítnutí se odehrává v sadě pravidel, která vlastní test značky. Řádek ip saddr 192.168.122.0/24 accept přidaný do nějakého pozdějšího řetězce se pro tento paket prostě nikdy nezkoumá, a proto se zřejmé pravidlo zdá správné a nic nemění.

Rozšiřování, dokud něco nefunguje, je druhá past. Přijetí celé podsítě libvirt ve vstupní cestě hostitele otevře hostům každou službu hostitele, zatímco skutečná potřeba je jeden port.

Mechanismem, který úzkou výjimku umožňuje, je sledování spojení. Když nastavíte ct mark na paket, hodnota se uloží do záznamu conntrack, a ne jen do paketu, takže každý paket v tomto spojení ji poté nese, včetně odpovědi z hostitele zpět hostovi. To je celý trik: označte požadavek jednou a zpáteční cesta je již označena.

Označte dotaz dřív, než ho uvidí tabulka VPN

Umístěte výjimku do vlastní tabulky, aby ji pozdější čtenář našel bez rozebírání pravidel 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á, což tento řetězec staví před běžné řetězce filtrů, které balíček VPN instaluje s prioritou nula. Právě pořadí hooků činí pravidlo účinným; stejné pravidlo v řetězci, který se řadí za řetězec VPN, je jen dekorace.

Samotné číslo značky není přenosné. Vezměte hodnotu, kterou instalovaná pravidla VPN přijímají pro svůj vlastní provoz, přečtěte ji ze živé sady pravidel a použijte ji. Špatná značka vytvoří pravidlo, které se čistě načte, odpovídá každému dotazu a nic nepovolí.

Držte díru širokou jako port 53

Jak je napsáno, to povoluje DNS z podsítě libvirt k hostiteli přes TCP nebo UDP port 53 a nic jiného. Neumožňuje hostům dosáhnout internetu mimo tunel a neumožňuje hostiteli otevírat spojení směrem k hostům. Pokud host později potřebuje jinou službu hostitele, přidejte samostatné pravidlo pojmenovávající tento cílový port místo uvolnění tohoto.

Buďte upřímní v tom, co měníte. Host, který dosáhne na resolver, může také tunelovat libovolná data přes DNS dotazy, a tato výjimka je záměrná mezera ve hranici VPN, nikoli tvrzení, že místní síti se dá věřit. Omezení zdroje na 192.168.122.0/24 drží mezeru mimo každou jinou místní podsíť a počítání dotazů proti tomuto zdroji je levné, pokud vám na hrozbě záleží.

Nechte to přežít restart a dokažte obě poloviny

Pravidlo napsané v shellu zmizí při příštím startu a pravidlo načtené poté, co rozhraní VPN už propouští provoz, prohraje závod při prvním spojení. Umístěte tabulku do trvalé konfigurace nftables hostitele nebo do unit, seřazeného před službou VPN, a pořadí zkontrolujte, místo abyste je předpokládali.

Ověření vyžaduje tři samostatné odpovědi. Potvrďte, že je řetězec načtený a seřazený první, potvrďte, že záznam conntrack ukazuje značku v obou směrech, a potvrďte, že vyhledávání hosta vrací adresu. Pak potvrďte druhou polovinu: běžný webový provoz hosta k veřejnému hostiteli stále selhává, dokud je tunel dole nebo blokuje. Pokud DNS funguje a vše ostatní uniká, vaše pravidlo je širší než to výše.

Pokud vyhledávání po nasazení značky stále selhává, odolejte nutkání rozšířit zdroj. Zkontrolujte, kam dnsmasq předává, zda resolver hosta ukazuje na 192.168.122.1 nebo na veřejnou adresu, kterou někdo zadal, a zda se dotaz vůbec dostane k hostiteli. Označení propustí paket a nic jiného, takže špatný upstream nebo rozbitá virtuální síť zůstanou rozbité, ať přidáte kolik pravidel chcete.