DNS-fôret nftables-sett til WireGuard: slik fungerer overleveringen
Et DNS-svar kan fôre et nftables-sett, men et sett ruter ingenting. Følg de fire overleveringene og de tre levetidene som avgjør om styringen virker.
Navn løses opp til adresser, og disse adressene kan havne i et brannmur-sett som senere påvirker ruting, noe som gjør navnebasert styring mulig uten en proxy. Haken er at fire komponenter må overlevere riktig: resolvere, settet, klassifisereren som markerer en ny flyt, og peeren som bærer den. Hver overlevering feiler forskjellig og hver holder sin egen tid.
Behandle designet som en kjede og ikke som en konfigurasjon. Spørsmålet ved hvert steg er hvilken komponent som eier beslutningen og hva som skjer når inndataene mangler.
Hva DNS-svaret kan og ikke kan
dnsmasq kan kopiere adresser fra svar inn i et nftables-sett, noe som er fôring og ikke en rutingsbeslutning. Det alternativet, dokumentert i dnsmasq-håndboken, angir familie, tabell og sett, og den ledende 4# velger bare A-poster, så v6-destinasjoner trenger sin egen ordning. Settet må allerede finnes, fordi resolversen legger til elementer i noe eieren av brannmuren har opprettet. Ingenting i det steget velger et grensesnitt, en tabell eller en peer.
Klienten må også bruke den resolversen for navnet. Et program med egen kryptert DNS, eller et bufret svar fra før policyen fantes, kobler til uten å opprette noen oppføring i settet.
Settet er inndata, ikke en rute
Et element i et sett er en samsvarsbetingelse. Noe må se på det, avgjøre at denne pakken starter en ny flyt, og anvende policyen som sender flyten gjennom tunnelen. På Linux betyr det vanligvis en rutevennlig utgangsvei som kan sette et merke, en regel som sender merkede pakker til en egen tabell, og en rute i den tabellen mot WireGuard-enheten. Bare medlemskap installerer ingenting av dette.
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 andre dekningskontroll som folk glemmer. WireGuard krypterer bare en pakke for en peer der de tillatte adressene omfatter målet, så en policyrute inn i grensesnittet er ikke nok når peerens liste utelukker det prefikset. Hold listen under rutingeierens kontroll i stedet for å stole på hvilken ruteoppretting administratoren tilfeldigvis gjør.
Merker, tabeller og peer-dekning
Merker er et delt navnerom, så både verdien og masken må avtales med alt annet som bruker dem. En regel som sender merket trafikk til en egen tabell trenger et definert resultat når tabellen ikke har noen samsvarende rute, fordi et ubesvart oppslag kan fortsette til neste regel og sende pakken ut gjennom det fysiske grensesnittet. En blackhole-standardrute inne i den egne tabellen gjør den stille flukten til et synlig tap. Det designet fortsatt ikke kan, er å lukke ved feil for en destinasjon som aldri kom inn i settet.
Tunnelens egne ytre pakker må slippe unna klassifisereren. WireGuard-verktøy gir et socketmerke nettopp for det formålet, og bruk av det hindrer at innkapslingen rutes tilbake til grensesnittet den bygger.
Test hver levetid for seg
Tre lagre eldes etter tre tidsplaner: resolversens buffer, settelementene og den sporede forbindelsen. Test dem i den rekkefølgen og se om hver enkelt flytter seg når den skal. Kommandoene nedenfor leser resolversen, settet, forbindelsestabellen og policyreglene uten å endre noe.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Et friskt oppslag som legger til et element beviser at fôringen virker, mens et utdatert element som overlever svaret sitt er et levetidsavvik som er verdt å skrive ned. En ny forbindelse i forbindelsestabellen med det forventede merket viser at klassifisereren kjørte, og en gammel forbindelse som beholder sitt opprinnelige merke er riktig oppførsel og ikke en feil. Regellisten svarer på om policyoppslaget i det hele tatt finnes, som er et annet spørsmål enn om det samsvarte. Les de fire utdataene i den rekkefølgen, og den feilende overleveringen avslører seg selv.
Der kravet er at et bestemt navn alltid bruker én vei, kan et DNS-fôret sett ikke bevise det, fordi delte adresser også bærer andre navn. En proxy eller en mekanisme på applikasjonsnivå er verktøyet for den garantien.