Sada nftables napájená z DNS do WireGuardu: jak předání funguje

Jména se překládají na adresy a tyto adresy mohou skončit v sadě firewallu, která později ovlivňuje směrování, což umožňuje směrování podle jména bez proxy. Háček je v tom, že čtyři komponenty musí správně předat: resolver, sada, klasifikátor, který označí nový tok, a peer, který ho nese. Každé předání selhává jinak a každé si drží svůj vlastní čas.

Berte návrh jako řetěz, ne jako konfiguraci. Otázka v každém kroku je, která komponenta vlastní rozhodnutí a co se stane, když chybí její vstup.

Co odpověď DNS umí a co ne

dnsmasq umí kopírovat adresy z odpovědí do sady nftables, což je napájení, nikoli rozhodnutí o směrování. Tato volba, popsaná v manuálu dnsmasq, určuje rodinu, tabulku a sadu a její úvodní 4# vybírá jen záznamy A, takže cíle v6 potřebují vlastní uspořádání. Sada už musí existovat, protože resolver přidává prvky do něčeho, co vytvořil vlastník firewallu. Nic v tomto kroku nevybírá rozhraní, tabulku ani peer.

Klient také musí pro jméno použít tento resolver. Aplikace s vlastním šifrovaným DNS nebo odpověď z mezipaměti z doby před politikou se připojí, aniž by v sadě vytvořila jakýkoli záznam.

Sada je vstup, ne trasa

Prvek v sadě je podmínka shody. Něco se na něj musí podívat, rozhodnout, že tento paket začíná nový tok, a použít politiku, která tok pošle tunelem. Na Linuxu to obvykle znamená výstupní cestu schopnou směrování, která umí nastavit značku, pravidlo posílající označené pakety do vyhrazené tabulky a trasu v této tabulce ukazující na zařízení WireGuard. Samotné členství nic z toho nenainstaluje.

nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips

Peer uplatňuje druhou kontrolu pokrytí, na kterou se zapomíná. WireGuard šifruje paket jen pro peer, jehož povolené adresy zahrnují cíl, takže trasování politikou do rozhraní nestačí, když seznam peeru tento prefix vylučuje. Držte seznam pod kontrolou vlastníka směrování, místo abyste spoléhali na to, jaké trasy správce zrovna vytvoří.

Značky, tabulky a pokrytí peeru

Značky jsou sdílený jmenný prostor, takže hodnota i maska musí být dohodnuty se vším ostatním, co je používá. Pravidlo posílající označený provoz do vyhrazené tabulky potřebuje definovaný výsledek, když tato tabulka nemá odpovídající trasu, protože nezodpovězené hledání může pokračovat dalším pravidlem a poslat paket ven fyzickým rozhraním. Výchozí trasa typu blackhole uvnitř vyhrazené tabulky mění ten tichý únik ve viditelné zahození. Co návrh stále neumí, je zavřít se při selhání pro cíl, který se nikdy do sady nedostal.

Vlastní vnější pakety tunelu musí klasifikátoru uniknout. Nástroje WireGuard poskytují značku socketu právě pro tento účel a její použití brání tomu, aby se zapouzdření směrovalo zpět do rozhraní, které buduje.

Testujte každou životnost zvlášť

Tři úložiště stárnou podle tří plánů: mezipaměť resolveru, prvky sady a sledované spojení. Testujte je v tomto pořadí a sledujte, zda se každé pohne, když má. Níže uvedené příkazy čtou resolver, sadu, tabulku spojení a pravidla politiky, aniž by cokoli měnily.

dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show

Čerstvé hledání, které přidá prvek, dokazuje, že napájení funguje, zatímco zastaralý prvek, který přežije svou odpověď, je nesoulad životností, který stojí za zapsání. Nové spojení v tabulce spojení s očekávanou značkou ukazuje, že klasifikátor běžel, a staré spojení držící původní značku je správné chování, ne chyba. Výpis pravidel odpovídá na to, zda hledání politiky vůbec existuje, což je jiná otázka než zda se shodovalo. Přečtěte čtyři výstupy v tomto pořadí a selhávající předání se prozradí samo.

Když je požadavkem, aby určité jméno vždy používalo jednu cestu, sada napájená z DNS to nemůže dokázat, protože sdílené adresy nesou i jiná jména. Proxy nebo mechanismus na úrovni aplikace je nástrojem pro takovou záruku.