Wêrom dnsmasq-fersiken nei in DNS-oerpleatsing bûten de VPN reitsje

De LAN-klint berikt syn VPN goed en dochs ferskine syn DNS-fersiken op de ferkearde omheechlink. Dat is gjin lek yn de gewoane sin; it is wat der bart as de router ophâldt in fersyk troch te stjoeren en it sels beantwurdet. It ûnderskeppen skriuwt it bestimming oer nei in lokale socket, en dan iepenet de resolver in twadde, net besibbe petear mei syn eigen boarneadres en syn eigen routingbeslút. Markearrings dy’t op de klintstream tapast wurde, beskriuwe it earste petear en hielendal neat oer it twadde.

De markearring reizget net mei it fersyk

Pakketmarkearrings libje op in conntrack-ynskriuwing en op it pakket ûnderweis. In REDIRECT-regel einiget dy flecht: de lading wurdt oerdroegen oan in lokale socket, en de oarspronklike yndriuwing hat syn wurk dien. Wat dêrnei de router ferlit, is in nije socket makke troch it resolverproses, mei it adres fan de router sels as boarne.

Dêrom past in beliedsrûte dy’t op it adres fan de LAN-klint basearre is, nea by it omheech-fersyk. De nije socket heart by dnsmasq yn plak fan by de klint, en de kernel beoardielet de rûte foar it eigen ferkear fan de router. Boarneregels, ynterface-regels en markearringsregels sjogge allegear in oare tuple. Oannimme dat de markearring him fuortplantaat is de meast foarkommende flater yn dizze opset, en hy is ûnsichtber yn in opname oan klintkant.

De beide petearen diele wol in namme en in timing, en dat is wat se op ien stream lykje lit as jo in opname fluch trochsjogge.

Wêr’t trochstjoeren lokale oplossing wurdt

Begjin mei te finen oft poarte 53 omlaat, oerset nei in oare host of gewoan mei rêst litten wurdt, want de trije gefallen gedrage har oars. In omlieding nei in lokale poarte einiget it trochstjoeren, wylst in oersetting nei in oare masine it pakket bewegend hâldt en de tuple fan de klint betsjuttingsfol hâldt.

Sjoch nei beide protokollen. In resolver dy’t oer UDP en TCP berikber is, sil oer beide test wurde, en in regelset dy’t allinnich UDP dekt lit in stil gat foar grutte antwurden. Regels dy’t troch de eigen konfiguraasjemanager fan de router makke wurde, telle ek, en it bewurkjen fan in makke triem ferliest meastentiids fan de folgjende werlading.

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'

Dy útfieringen beantwurdzje trije fragen yn folchoarder: wat it fersyk oerskriuwt, wat it ûntfangt, en hokker proses de harkjende socket besit. Sadree’t de eigner bekend is, hat it upstream-belied in plak om te libjen.

Jou de resolver syn eigen útgongsbelied

In domeinspezifike upstream is it skjinste ark as allinnich guon nammen de tunnel nedich hawwe. dnsmasq akseptearret in server-rigel beheind ta in domein, mei in opsjonele ynterface of boarneadres dy’t it fersyk út in keazen apparaat stjoert. Dy stjoering is wat it twadde petear de VPN folgje lit.

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

It domein, it adres en de ynterface hjirboppe binne plakhâlders foar jo eigen wearden. Domeinkeazen en útgongskontrôle bliuwe aparte besluten: de rûte moat bestean, it boarneadres moat troch de upstream-resolver tastien wurde, en de firewall moat it antwurd tastean. Allinnich ynterfacestjoering is net fail-closed, want in ferdwûne tunnel kin de resolver op in oar paad weromfalle litte. Hâld elke iepenbiere weromfal fuort fan in nammeromte dy’t partikulier bliuwe moat.

Set de rigel by de konfiguraasjeeigner dy’t de router stipet ynplak fan yn in makke triem, oars wisket de folgjende werlading de repaasje út.

Wat in dielde cache net bewarje kin

Ien trochstjoerder mei ien cache betsjinnet elke LAN-klint, en dat ferpletteret in ûnderskie dat guon netwurken nedich hawwe. As twa klinten deselde namme oars oplosse moatte, hat de dielde socket gjin manier om werom te heljen hokker klint frege hat. Belied per klint moat libje yn aparte resolver-eksimplaren of yn in trochstjoerfunksje dy’t de identiteit hâldt.

In cache-antwurd is ek gjin bewiis oer it nije paad. It antwurd kin út it ûnthâld komme wylst de upstream-rûte ferbrutsen bliuwt.

Regels foar poarte 53 sizze neat oer tapassingen dy’t DNS oer HTTPS of oer TLS prate. Dy fersiken berikke de omlieding nea, dus beskriuwt in belied dat allinnich op poarte 53 boud is in dielferzameling fan it ferkear en moat as in dielferzameling dokumintearre wurde.

Ferifiearje it twadde petear, net it earste

Test mei ien namme dy’t jo behearskje en sjoch nei beide kanten. In opname oan klintkant bewiist dat it fersyk it LAN ferlitten hat; allinnich de routerkant bewiist wêr’t it dêrnei hinne gie.

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

Leegje de cache foar elke poging, want in waarm antwurd ferberget in ferbrutsen upstream. Werhelje oer TCP, werhelje dan mei de tunnel del om te sjen wat de resolver docht as syn foarkarpaad fuort is. Dat lêste gedrach beslútmint oft it ûntwerp fail-closed is of gewoan gelokkich.