DNS-fodret nftables-sæt til WireGuard: sådan virker overdragelsen

Navne opløses til adresser, og disse adresser kan ende i et firewall-sæt, som senere påvirker routing, hvilket gør navnebaseret styring mulig uden en proxy. Haken er, at fire komponenter skal overdrage korrekt: resolveren, sættet, klassifikatoren der markerer en ny flow, og peer'en der bærer den. Hver overdragelse fejler forskelligt, og hver holder sin egen tid.

Behandl designet som en kæde frem for en konfiguration. Spørgsmålet ved hvert trin er, hvilken komponent der ejer beslutningen, og hvad der sker, når dens input mangler.

Hvad DNS-svaret kan og ikke kan

dnsmasq kan kopiere adresser fra svar til et nftables-sæt, hvilket er en fodring og ikke en routingbeslutning. Den valgmulighed, der er dokumenteret i dnsmasq-manualen, angiver familie, tabel og sæt, og dens indledende 4# vælger kun A-poster, så v6-destinationer kræver deres egen ordning. Sættet skal allerede findes, fordi resolveren tilføjer elementer til noget, som firewallens ejer har oprettet. Intet i det trin vælger en grænseflade, en tabel eller en peer.

Klienten skal også bruge den resolver til navnet. Et program med egen krypteret DNS, eller et cachelagret svar fra før politikken fandtes, forbinder uden at oprette nogen post i sættet.

Sættet er et input, ikke en rute

Et element i et sæt er en matchningsbetingelse. Noget skal se på det, beslutte at denne pakke starter en ny flow og anvende den politik, der sender flowen gennem tunnelen. På Linux betyder det normalt en ruteegnet udgangsvej, der kan sætte et mærke, en regel der sender markerede pakker til en dedikeret tabel, og en rute i den tabel, der peger på WireGuard-enheden. Medlemskab alene installerer intet af det.

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 anvender en anden dækningskontrol, som folk glemmer. WireGuard krypterer kun en pakke til en peer, hvis tilladte adresser omfatter destinationen, så en politikrute ind i grænsefladen er ikke nok, når peerens liste udelukker det præfiks. Hold listen under routingejerens kontrol i stedet for at stole på, hvilken ruteoprettelse manageren tilfældigvis udfører.

Mærker, tabeller og peerdækning

Mærker er et delt navnerum, så både værdien og masken skal aftales med alt andet, der bruger dem. En regel, der sender markeret trafik til en dedikeret tabel, kræver et defineret resultat, når tabellen ikke har nogen matchende rute, fordi et ubesvaret opslag kan fortsætte til den næste regel og sende pakken ud ad den fysiske grænseflade. En blackhole-standardrute inde i den dedikerede tabel gør den stille flugt til et synligt drop. Hvad designet stadig ikke kan, er at lukke ved fejl for en destination, der aldrig kom ind i sættet.

Tunnelens egne ydre pakker skal slippe uden om klassifikatoren. WireGuard-værktøjer giver et socketmærke netop til det formål, og brug af det forhindrer, at indkapslingen rutes tilbage i den grænseflade, den bygger.

Test hver levetid for sig

Tre lagre ældes efter tre tidsplaner: resolverens cache, sættets elementer og den sporede forbindelse. Test dem i den rækkefølge, og se, om hver enkelt flytter sig, når den skal. Kommandoerne nedenfor læser resolveren, sættet, forbindelsestabellen og politikreglerne uden at ændre noget.

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

Et frisk opslag, der tilføjer et element, beviser at fodringen virker, mens et forældet element, der overlever sit svar, er en levetidsuoverensstemmelse, der er værd at skrive ned. En ny forbindelse i forbindelsestabellen med det forventede mærke viser, at klassifikatoren kørte, og en gammel forbindelse, der beholder sit oprindelige mærke, er korrekt adfærd og ikke en fejl. Regellisten besvarer, om politikopslaget overhovedet findes, hvilket er et andet spørgsmål end, om det matchede. Læs de fire output i den rækkefølge, og den fejlende overdragelse afslører sig selv.

Hvor kravet er, at et bestemt navn altid bruger én vej, kan et DNS-fodret sæt ikke bevise det, fordi delte adresser også bærer andre navne. En proxy eller en mekanisme på programniveau er værktøjet til den garanti.