DNS-matad nftables-uppsättning till WireGuard: så fungerar överlämningen
Ett DNS-svar kan mata en nftables-uppsättning, men en uppsättning dirigerar ingenting. Följ de fyra överlämningarna och de tre livslängderna som avgör om styrningen fungerar.
Namn löses upp till adresser, och dessa adresser kan hamna i en brandväggsuppsättning som senare påverkar routningen, vilket gör namnbaserad styrning möjlig utan proxy. Haken är att fyra komponenter måste lämna över korrekt: resolvern, uppsättningen, klassificeraren som markerar ett nytt flöde och peeren som bär det. Varje överlämning misslyckas olika och var och en håller sin egen tid.
Behandla designen som en kedja och inte som en konfiguration. Frågan vid varje steg är vilken komponent som äger beslutet och vad som händer när dess indata saknas.
Vad DNS-svaret kan och inte kan
dnsmasq kan kopiera adresser från svar till en nftables-uppsättning, vilket är matning och inte ett routningsbeslut. Det alternativet, dokumenterat i dnsmasq-handboken, anger familj, tabell och uppsättning, och dess inledande 4# väljer bara A-poster, så v6-mål behöver sin egen ordning. Uppsättningen måste redan finnas, eftersom resolvern lägger till element i något som brandväggens ägare har skapat. Ingenting i det steget väljer ett gränssnitt, en tabell eller en peer.
Klienten måste också använda den resolvern för namnet. Ett program med egen krypterad DNS, eller ett cachat svar från tiden före policyn, ansluter utan att skapa någon post i uppsättningen.
Uppsättningen är indata, inte en rutt
Ett element i en uppsättning är ett matchningsvillkor. Något måste titta på det, avgöra att detta paket startar ett nytt flöde och tillämpa policyn som skickar flödet genom tunneln. På Linux betyder det vanligtvis en routningsduglig utgångsväg som kan sätta en markering, en regel som skickar markerade paket till en egen tabell och en rutt i den tabellen mot WireGuard-enheten. Enbart medlemskap installerar inget av detta.
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
Peeren tillämpar en andra täckningskontroll som folk glömmer. WireGuard krypterar bara ett paket för en peer vars tillåtna adresser omfattar målet, så en policyrutt in i gränssnittet räcker inte när peerens lista utesluter det prefixet. Håll listan under routningsägarens kontroll i stället för att lita på vilken rutt som helst som hanteraren råkar skapa.
Markeringar, tabeller och peer-täckning
Markeringar är ett delat namnrum, så både värdet och masken måste stämmas av med allt annat som använder dem. En regel som skickar markerad trafik till en egen tabell behöver ett definierat resultat när tabellen inte har någon matchande rutt, eftersom ett obesvarat uppslag kan fortsätta till nästa regel och skicka paketet ut genom det fysiska gränssnittet. En blackhole-standardrutt inne i den egna tabellen förvandlar den tysta flykten till ett synligt tapp. Det designen fortfarande inte kan är att stänga vid fel för ett mål som aldrig kom in i uppsättningen.
Tunnelns egna yttre paket måste undkomma klassificeraren. WireGuard-verktyg tillhandahåller en socketmarkering just för det syftet, och att använda den hindrar inkapslingen från att routas tillbaka in i gränssnittet den bygger.
Testa varje livslängd för sig
Tre lager åldras enligt tre scheman: resolverns cache, uppsättningens element och den spårade anslutningen. Testa dem i den ordningen och se om var och en rör sig när den ska. Kommandona nedan läser resolvern, uppsättningen, anslutningstabellen och policyreglerna utan att ändra något.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Ett färskt uppslag som lägger till ett element bevisar att matningen fungerar, medan ett inaktuellt element som överlever sitt svar är en livslängdsavvikelse som är värd att skriva ned. En ny anslutning i anslutningstabellen med den förväntade markeringen visar att klassificeraren körde, och en gammal anslutning som behåller sin ursprungliga markering är korrekt beteende och inte en bugg. Regelistan svarar på om policyuppslaget alls finns, vilket är en annan fråga än om det matchade. Läs de fyra utdata i den ordningen och den misslyckade överlämningen avslöjar sig själv.
Där kravet är att ett visst namn alltid använder en väg kan en DNS-matad uppsättning inte bevisa det, eftersom delade adresser också bär andra namn. En proxy eller en mekanism på applikationsnivå är verktyget för den garantin.