DNS-fôra nftables-sett til WireGuard: korleis overleveringa fungerer
Eit DNS-svar kan fôra eit nftables-sett, men eit sett rutar ingenting. Følg dei fire overleveringane og dei tre levetidene som avgjer om styringa verkar.
Namn blir løyste til adresser, og desse adressene kan hamne i eit brannmur-sett som seinare påverkar ruting, noko som gjer namnebasert styring mogleg utan ein proxy. Haken er at fire komponentar må overlevere rett: resolvaren, settet, klassifiseraren som merkjer ein ny flyt, og peeren som ber han. Kvar overlevering feilar ulikt og kvar held si eiga tid.
Behandle designet som ei kjede og ikkje som ein konfigurasjon. Spørsmålet ved kvart steg er kva komponent som eig avgjerda og kva som skjer når inndata manglar.
Kva DNS-svaret kan og ikkje kan
dnsmasq kan kopiere adresser frå svar inn i eit nftables-sett, noko som er fôring og ikkje ei rutingsavgjerd. Det alternativet, dokumentert i dnsmasq-handboka, oppgir familie, tabell og sett, og den leiande 4# vel berre A-poster, så v6-destinasjonar treng si eiga ordning. Settet må alt finnast, fordi resolvaren legg til element i noko eigaren av brannmuren har oppretta. Ingenting i det steget vel eit grensesnitt, ein tabell eller ein peer.
Klienten må òg bruke den resolvaren for namnet. Eit program med eigen kryptert DNS, eller eit bufra svar frå før politikken fanst, koplar til utan å opprette nokon oppføring i settet.
Settet er inndata, ikkje ei rute
Eit element i eit sett er ein samsvarsbetingelse. Noko må sjå på det, avgjere at denne pakken startar ein ny flyt, og bruke politikken som sender flyten gjennom tunnelen. På Linux tyder det vanlegvis ein rutevennleg utveg som kan setje eit merke, ein regel som sender merkte pakkar til ein eigen tabell, og ei rute i den tabellen mot WireGuard-eininga. Berre 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 brukar ein andre dekningskontroll som folk gløymer. WireGuard krypterer berre ein pakke for ein peer der dei tillatne adressene omfattar målet, så ei politikroute inn i grensesnittet er ikkje nok når lista til peeren utelukkar det prefikset. Hald lista under kontroll av rutingeigaren i staden for å stole på kva ruteoppretting administratoren tilfeldigvis gjer.
Merkje, tabellar og peer-dekning
Merkje er eit delt namnerom, så både verdien og maska må avtalast med alt anna som brukar dei. Ein regel som sender merkt trafikk til ein eigen tabell treng eit definert resultat når tabellen ikkje har noka samsvarande rute, fordi eit ubesvart oppslag kan halde fram til neste regel og sende pakken ut gjennom det fysiske grensesnittet. Ei blackhole-standardrute inne i den eigene tabellen gjer den stille flukta til eit synleg tap. Det designet framleis ikkje kan, er å lukke ved feil for ein destinasjon som aldri kom inn i settet.
Dei eigne ytre pakkane til tunnelen må sleppe unna klassifiseraren. WireGuard-verktøy gir eit socketmerke nettopp for det føremålet, og bruk av det hindrar at innkapslinga blir ruta tilbake til grensesnittet ho byggjer.
Test kvar levetid for seg
Tre lager eldast etter tre tidsplanar: bufferen til resolvaren, settelementa og den spora sambandet. Test dei i den rekkjefølgja og sjå om kvar einskild flyttar seg når han skal. Kommandoane nedanfor les resolvaren, settet, sambandstabellen og politikreglane utan å endre noko.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Eit friskt oppslag som legg til eit element beviser at fôringa verkar, medan eit utdatert element som overlever svaret sitt er eit levetidsavvik som er verdt å skrive ned. Ei ny sambinding i sambandstabellen med det venta merket viser at klassifiseraren køyrde, og ei gammal sambinding som held på det opphavlege merket er rett åtferd og ikkje ein feil. Regellista svarar på om politikoppslaget i det heile finst, som er eit anna spørsmål enn om det samsvarte. Les dei fire utdata i den rekkjefølgja, og den feilande overleveringa avslører seg sjølv.
Der kravet er at eit bestemt namn alltid brukar éin veg, kan eit DNS-fôra sett ikkje bevise det, fordi delte adresser òg ber andre namn. Ein proxy eller ein mekanisme på applikasjonsnivå er verktøyet for den garantien.