WireGuard DNS DNAT: mbajeni funksional shtegun e përgjigjes

Drejtimi i pyetjes DNS të një klienti WireGuard te një resolver tjetër duket si një rregull dhe sillet si tri vendime. Destinacioni duhet të rishkruhet, paketa duhet të përçohet, dhe përgjigja duhet të gjejë rrugën e kthimit përmes gjendjes së përkthimit që krijoi gateway. Kapërceni të tretën dhe pyetja del pastër ndërsa klienti pret përgjithmonë.

Merrni shembullin e klientëve të autorizuar në 10.77.0.0/24 që vijnë përmes wg0, pyesin adresën e shpallur 10.77.0.1 dhe kanë nevojë për një resolver në 203.0.113.53. Adresa e sipërme është një vendmbajtëse dokumentacioni, jo një shërbim që funksionon.

Ridrejtimi i një pyetje ndryshon vetëm destinacionin e saj

Një rregull NAT destinacioni në PREROUTING rishkruan adresën përpara se të merret vendimi i rrugëtimit, kështu që paketa më pas rrugëtohet drejt destinacionit të ri në vend të atij të vjetër. Adresa burimore e klientit mbetet e paprekur nga ai operacion. Kjo është arsyeja pse një rregull që duket i plotë mund të prodhojë ende heshtje: kërkesa tani udhëton drejt një resolveri që nuk ka dëgjuar kurrë për diapazonin privat të klientit. Gateway përktheu një fushë dhe trashëgoi një problem të dytë.

Të dy transportet DNS kanë nevojë për rregulla përputhëse, sepse një klient kthehet në TCP kur një përgjigje pritet.

Rregullat më poshtë zgjedhin një ndërfaqe hyrëse, një diapazon klientësh dhe një adresë destinacioni origjinale. Asgjë tjetër në gateway nuk preket, dhe një pyetje e vetë gateway nuk përputhet aspak.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Shtegu i përgjigjes është një vendim i veçantë

Dy rregullime lejojnë që përgjigja të kthehet, dhe zgjedhja e hershme e njërës kursen një sesion korrigjimi. Ose resolveri i sipërm ka një rrugë kthimi drejt 10.77.0.0/24 përmes këtij gateway, ose gateway përkthen burimin në dalje në mënyrë që përgjigja të arrijë në një adresë që pala e sipërme e njeh tashmë. Të dyja funksionojnë; vetëm njëra përputhet me kontrollin që keni mbi palën e sipërme.

Rrugëtimi e meriton provën e parë, sepse e mban adresën e klientit të dukshme për resolverin dhe shmang një shtresë të dytë përkthimi. Kur pala e sipërme është jashtë kontrollit tuaj, përkthimi i burimit në ndërfaqen specifike të daljes është zgjedhja praktike.

Kufizojeni atë përkthim po aq rreptësisht sa ridrejtimin, përndryshe rregulli bëhet një NAT për qëllim të përgjithshëm për çdo gjë që përputhet rastësisht me të:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

Ndjekja e lidhjeve e mban hartëzimin në çift, kështu që përgjigja rishkruhet përsëri në tuple-in origjinal të klientit në kthim. Pa rregullin e daljes, resolveri e dërgon përgjigjen e tij drejt një adrese private që nuk mund ta arrijë, dhe klienti sheh një skadim kohe në vend të një gabimi.

Shkruani rregullat më të ngushta sesa duket detyra

Leja e përcjelljes i përket të njëjtit fushëveprim. Lejoni rrjedhën nga klienti te resolveri dhe trafikun e kthimit që conntrack e njeh tashmë, në vend që të pranoni çdo lidhje DNAT në makinë. Një pranim i përgjithshëm autorizon gjithashtu përcjellje portash që nuk kanë asnjë lidhje me DNS.

Resolveri i vetë gateway është një shteg kodi tjetër. Një pyetje e lëshuar lokalisht kalon përmes OUTPUT, kështu që testimi nga shell-i i gateway nuk ushtron as rregullin PREROUTING as politikën e përcjelljes. Kjo është arsyeja pse një test lokal mund të kalojë ndërsa çdo klient dështon, dhe e kundërta është po aq e zakonshme.

Asgjë këtu nuk mbulon DNS mbi HTTPS në portën 443 ose DNS mbi TLS në portën 853, dhe asgjë nuk mbulon IPv6. Një klient me resolver IPv6 të konfiguruar do të injorojë me kënaqësi të gjithë rregullimin.

Çfarë provon një pyetje e re

Ndjekja e lidhjeve kujton hartëzimet e mëparshme, kështu që një pyetje e dërguar përpara një ndryshimi rregulli mund të marrë përgjigje nga gjendja e vjetër dhe ta bëjë rregullin e re të duket i prishur. Filloni me një portë të re burimore dhe, aty ku klienti ruajt përgjigjet në memorie, me një emër të ri.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

Komanda e parë tregon nëse shtegu i klientit zgjidhet fare, dhe e dyta tregon përkthimin që gateway instaloi vërtet, duke përfshirë të dy drejtimet e tuple-it. Një hartëzim që tregon resolverin e duhur me një numërues përgjigjesh të ngecur në zero është problem i shtegut të kthimit dhe jo i filtrimit.

Konfirmoni që resolveri i njeh emrat që prisni përpara se të ridrejtoni çdo gjë. Një zëvendësues që përgjigjet për emrat publikë por jo për zonën tuaj private e shndërron një kërkim funksional në NXDOMAIN që duket si tunel i prishur. Testoni resolverin drejtpërdrejt, nga gateway, përpara se shtegu i klientit të përfshihet. Dhe referenca e shtesave të iptables dokumenton semantikën e DNAT dhe masquerade nga e cila varen këto rregulla.