Kvifor dnsmasq-spurnader slepp ut av VPN-en etter ei DNS-omdirigering

LAN-klienten når VPN-en sin rett, og likevel dukkar DNS-spurnadene opp på feil oppstraumslenke. Det er ikkje ein lekkasje i vanleg forstand; det er det som skjer når rutaren sluttar å videresende ein spurnad og svarar på han sjølv. Avskjeringa skriv om målet til ein lokal socket, og deretter opnar resolvaren ein ny, urelatert samtale med si eiga kjeldeadresse og sitt eige rutingsval. Merka som er sette på klientflyten, skildrar den første samtalen og absolutt ingenting om den andre.

Merket reiser ikkje med spurnaden

Pakkemerke lever på ein conntrack-oppføring og på pakken undervegs. Ein REDIRECT-regel avsluttar den ferda: nyttelasta vert overlevert til ein lokal socket, og den opphavlege oppføringa har gjort jobben sin. Det som deretter forlèt rutaren, er ein fersk socket laga av resolverprosessen, med adressa til rutaren sjølv som kjelde.

Derfor treff ein policy-rute knytt til adressa til LAN-klienten aldri oppstraumsspurnaden. Den nye socketen høyrer til dnsmasq og ikkje til klienten, og kjernen vurderer ruta for trafikken til rutaren sjølv. Kjelderreglar, grensesnittreglar og merkereglar ser alle ein annan tuppel. Å tru at merket forplantar seg er den vanlegaste feilen i denne oppsetjinga, og han er usynleg i eit opptak på klientsida.

Dei to samtalene deler faktisk eit namn og ei timing, og det er det som får dei til å sjå ut som éin flyt når du skummar gjennom eit opptak.

Kvar videresending vert lokal oppslag

Byrja med å finne ut om port 53 vert omdirigert, omsett til ein annan vert eller får vere i fred, fordi dei tre tilfella oppfører seg ulikt. Ei omdirigering til ein lokal port avsluttar videresendinga, medan ei omsetjing til ein annan maskin held pakken i rørsle og held tuppelen til klienten meiningsfull.

Sjå på begge protokollane. Ein resolver som er tilgjengeleg over UDP og TCP, vil verte testa over begge, og eit regelsett som berre dekkjer UDP, lèt att eit stille hol for store svar. Reglar som vert genererte av konfigurasjonshandsamaren til rutaren sjølv, tel òg, og å redigere ei generert fil taper vanlegvis mot neste innlasting.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Desse utdataene svarar på tre spørsmål i rekkjefølgje: kva som skriv om spurnaden, kva som tek imot han, og kva prosess som eig den lyttande socketen. Når eigaren er kjend, har oppstraumspolicyen ein stad å bu.

Gje resolvaren sin eigen utgangspolicy

Ein domenespesifikk oppstraum er det reinaste verktyet når berre nokre namn treng tunnelen. dnsmasq godtek ei server-linje avgrensa til eit domene, med eit valfritt grensesnitt eller kjeldeadresse som styrer spurnaden ut av ein vald eining. Det er denne styringa som får den andre samtalen til å følgje VPN-en.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domenet, adressa og grensesnittet ovanfor er plasshaldarar for dine eigne verdiar. Domeval og utgangskontroll er framleis separate avgjerder: ruta må finnast, kjeldeadressa må vere tillaten av oppstraumsresolvaren, og brannmuren må tillate svaret. Berre grensesnittstyring er ikkje fail-closed, fordi ein tunnel som forsvinn kan la resolvaren falle tilbake på ein annan veg. Hald kvar offentleg reservesløysing langt unna eit namnerom som må halde fram med å vere privat.

Set linja hos konfigurasjonseigaren rutaren støttar i staden for i ei generert fil, elles slettar neste innlasting rettinga.

Kva ein delt hurtigbuffer ikkje kan ta vare på

Éin videresendar med éin hurtigbuffer tener kvar LAN-klient, og det får ein skilnad som nokre nettverk treng til å falle saman. Viss to klientar må slå opp det same namnet ulikt, har den delte socketen ingen måte å finne ut kven klient som spurde. Policy per klient må bu i separate resolverinstansar eller i ein videresendingsfunksjon som held på identiteten.

Eit bufra svar er heller ikkje prov om den nye vegen. Svaret kan kome frå minnet medan oppstraumsruta er framleis broten.

Reglar for port 53 seier ingenting om program som talar DNS over HTTPS eller over TLS. Desse spurnadene når aldri omdirigeringa, så ein policy bygd berre på port 53 skildrar ei delmengd av trafikken og bør dokumenterast som ei delmengd.

Stadfest den andre samtalen, ikkje den første

Test med eitt namn du kontrollerer, og sjå på begge sider. Eit opptak på klientsida provar at spurnaden forlét LAN-et; berre rutarsida provar kvar han gjekk vidare.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Tøm hurtigbufferen før kvart forsøk, fordi eit varmt svar gøymer ein broten oppstraum. Gjenta over TCP, og gjenta deretter med tunnelen nede for å sjå kva resolvaren gjer når den føretrekte vegen hans er borte. Den siste åtferda avgjer om designet er fail-closed eller berre heldig.