Waarom dnsmasq-navrae die VPN vryspring ná ’n DNS-omleiding

Die LAN-kliënt bereik sy VPN korrek, en tog verskyn sy DNS-navrae op die verkeerde opstroomverbinding. Dit is nie ’n lek in die gewone sin nie; dit is wat gebeur wanneer die router ophou om ’n navraag aan te stuur en dit self beantwoord. Onderskepping herskryf die bestemming na ’n plaaslike socket, en die resolver open dan ’n tweede, onverwante gesprek met sy eie bronadres en sy eie roetebesluit. Merktekens wat op die kliënt se vloei toegepas word, beskryf die eerste gesprek en glad niks oor die tweede nie.

Die merkteken reis nie saam met die navraag nie

Pakketmerke leef op ’n conntrack-inskrywing en op die pakket wat onderweg is. ’n REDIRECT-reël beëindig daardie vlug: die vrag word aan ’n plaaslike socket oorhandig, en die oorspronklike inskrywing het sy werk gedoen. Wat daarna die router verlaat, is ’n vars socket wat deur die resolver-proses geskep is, met die router se eie adres as bron.

Dis waarom ’n beleidsroete wat op die LAN-kliënt se adres gesleutel is, nooit die opstroom-navraag pas nie. Die nuwe socket behoort aan dnsmasq eerder as aan die kliënt, en die kernel evalueer die roete vir die router se eie verkeer. Bronreëls, koppelvlakreëls en merkreëls sien almal ’n ander tuple. Om aan te neem dat die merkteken voortgeplant word, is die mees algemene fout in hierdie opstelling, en dit is onsigbaar in ’n kliëntkant-opname.

Die twee gesprekke deel wel ’n naam en ’n tydsberekening, en dit is wat hulle soos een vloei laat lyk wanneer jy ’n opname vlugtig deurkyk.

Waar aansturing plaaslike resolusie word

Begin deur vas te stel of poort 53 herlei, na ’n ander gasheer vertaal of heeltemal alleen gelaat word, want die drie gevalle gedra hulle anders. ’n Omleiding na ’n plaaslike poort beëindig aansturing, terwyl ’n vertaling na ’n ander masjien die pakket aan die beweeg hou en die kliënt se tuple betekenisvol hou.

Kyk na albei protokolle. ’n Resolver wat oor UDP en TCP bereikbaar is, sal oor albei getoets word, en ’n reëlstel wat net UDP dek, laat ’n stil gat vir groot antwoorde. Reëls wat deur die router se eie konfigurasiebestuurder gegenereer word, tel ook, en om ’n gegenereerde lêer te wysig, verloor gewoonlik teen die volgende herlaai.

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'

Daardie uitsette beantwoord drie vrae in volgorde: wat die navraag herskryf, wat dit ontvang, en watter proses die luisterende socket besit. Sodra die eienaar bekend is, het die opstroombeleid ’n plek om te woon.

Gee die resolver sy eie uitgangsbeleid

’n Domeinspesifieke opstroom is die skoonste gereedskap wanneer net sommige name die tonnel nodig het. dnsmasq aanvaar ’n server-reël wat tot ’n domein beperk is, met ’n opsionele koppelvlak of bronadres wat die navraag uit ’n gekose toestel stuur. Daardie sturing is wat die tweede gesprek die VPN laat volg.

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

Die domein, adres en koppelvlak hierbo is plekhouers vir jou eie waardes. Domeinkeuse en uitgangsbeheer bly aparte besluite: die roete moet bestaan, die bronadres moet deur die opstroom-resolver toegelaat word, en die firewall moet die antwoord toelaat. Koppelvlaksturing alleen is nie fail-closed nie, want ’n tonnel wat verdwyn, kan die resolver op ’n ander pad laat terugval. Hou enige openbare terugval weg van ’n naamruimte wat privaat moet bly.

Sit die reël by die konfigurasie-eienaar wat die router ondersteun eerder as in ’n gegenereerde lêer, anders vee die volgende herlaai die regstelling uit.

Wat ’n gedeelde kas nie kan bewaar nie

Een aanstuurder met een kas bedien elke LAN-kliënt, en dit verpletter ’n onderskeid wat sommige netwerke nodig het. As twee kliënte dieselfde naam verskillend moet oplos, het die gedeelde socket geen manier om te herstel watter kliënt gevra het nie. Beleid per kliënt moet in aparte resolver-instanties woon of in ’n aanstuurfunksie wat die identiteit behou.

’n Gekaste antwoord is ook nie bewys oor die nuwe pad nie. Die antwoord kan uit die geheue kom terwyl die opstroomroete steeds stukkend is.

Poort-53-reëls sê niks oor programme wat DNS oor HTTPS of oor TLS praat nie. Daardie navrae bereik nooit die omleiding nie, dus beskryf ’n beleid wat net op poort 53 gebou is ’n deelversameling van die verkeer en moet as ’n deelversameling gedokumenteer word.

Verifieer die tweede gesprek, nie die eerste nie

Toets met een naam wat jy beheer en kyk na albei kante. ’n Kliëntkant-opname bewys die navraag het die LAN verlaat; net die routerkant bewys waarheen dit volgende gegaan het.

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

Leeg die kas voor elke poging, want ’n warm antwoord verberg ’n stukkende opstroom. Herhaal oor TCP, herhaal dan met die tonnel af om te sien wat die resolver doen wanneer sy voorkeurpad weg is. Daardie laaste gedrag besluit of die ontwerp fail-closed is of bloot gelukkig.