Wurdt de DNS fan jo VPN echt brûkt? Fang poarte 53 en sjoch

Freegje de measte minsken wat in VPN-klant mei DNS docht en se sille sizze dat er de resolver ynstelt, sadat fragen yn 'e tunnel reizgje. It drukken is echt; de oanname dat it in fraach wurdt, net. Tusken in trochdrukte opsje en in pakket op 'e tried steane trije stadia, en elk mislearret selsstannich op wizen dy't allegear op in stikken DNS-tsjinner lykje. Dêrom kinne in lektoets-side en in wurkjende browser it op itselde stuit oer deselde masine net iens wêze.

In trochdrukte opsje is gjin fraach

Stadium ien is dat de tsjinner ynstellingen oanbiedt, bygelyks in trochdrukte DNS-opsje dy't in resolver yn 'e tunnel neamt. Stadium twa is dat de klant dy ynstellingen op in ynterface tapast. Stadium trije is dat in programma wier in fraach nei dat adres stjoert. In falen yn stadium twa lit de opsje sichtber yn it ferbiningslog wylst de resolverlist ûnferoare bliuwt, en in falen yn stadium trije lit in folslein korrekte resolverlist ûnbrûkt.

It measte probleem sykjen smyt dy trije op ien bulte en jout de VPN-tsjinner de skuld, dy't meastentiids de iennige partij is dy't bewize kin dat er syn diel dien hat. Lês ynstee de echte resolverstân fan 'e klant, en sjoch dan ien fraach fuortgean. Dy twa waarnimmings skiede konfiguraasje fan rûtes en fan belied, en se kostje sawat fiif minuten. Bewarje de opnamen, want de folgjende yngenieur wol it foar en nei, net in beskriuwing derfan.

Kontrolearje wat de ynterface echt hâldt

Op Linux kin de systeemresolver it gewoane bestân, NetworkManager of systemd-resolved wêze, en hokker fan dy't it hat beslút wêr't in trochdrukte tsjinner telâne komt. In kommandorigel-OpenVPN-proses wurket de systeemresolver net sels by, dus de dokumintearre yntegraasje is in up/down-skript of in ferbiningsbehearder dy't al wit hoe't er de ynstellingen tapast. Beide draaie litte is in effisjinte manier om in race te meitsjen.

resolvectl status
cat /etc/resolv.conf

Op Windows is de list per adapter, dus de tunneladapter kin de ynterne tsjinners hâlde wylst de fysike adapter de lokale hâldt en foar guon nammen wint. Fergelykje beide adapters ynstee fan dy't jo aktyf tinke.

Folgje ien fraach fan 'e masine ôf

Fang beide ynterfaces tagelyk, en lost dan ien namme op dy't de ynterne resolver brûke moat. Dat pear opnamen beändert wat gjin konfiguraasje-útkomst beändert.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

In fraach dy't op 'e fysike ynterface ferskynt en nea yn 'e tunnel, betsjut dat de klant de ferkearde resolver keas. In fraach op gjin fan beide betsjut dat it programma út 'e cache antwurde, in stub frege dy't op loopback harket, of in fersifere resolver brûkte waans ferkear nea as poarte 53 ferskynt. Fang ek antwurden, net allinne fragen, want in fraach dy't troch de tunnel fuortgiet mei in antwurd fan in iepenbier adres is in oare flater as gjin antwurd dat oankomt.

De firewall dy't allinne syn eigen DNS akseptearret

Kommersjele klanten ynstallearje soms har eigen filterketens. Ien dokumintearre patroan lit DNS nei de eigen resolver fan 'e klant ta en smyt al it oerbleaune UDP-ferkear op poarte 53 fuort dat in net-loopback-ynterface ferlitte wol, ynklusyf ferkear dat de brûker bewust earne oars hinne rûte hat. Daemon-fragen ferdwine sûnder spoar, wat as in resolverflater lêzen wurdt ynstee fan as in filter.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

As in smytregel foar jo útsûndering evaluearre wurdt, wurdt in tafoege regel nea berikt, dus set dy op posysje ien en behein de bestimming ta de resolver dy't jo wier bedoele.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Dy útsûndering is diagnostysk ynstee fan belied. As de regel fan 'e leveransier bewust is, is de stipe reparaasje de klant konfigurearje om dy resolver ta te litten en it beslút fêst te lizzen, want in ynfoege regel oerlibbet de folgjende klantfernijing net.

Wêrom't in lek-side minder bewiist as't er liket

Wat in lektoets-side sjen lit, is de resolver dy't mei de testoperator praat hat, net dy't jo masine rieplachte. In lokale trochstjoerder dy't nei bûten rekursy docht set syn eigen útgongsadres op dy side, en fersifere fragen kinne de side hielendal leech litte. Beide resultaten wurde ferkeard lêzen, ien as lek en de oare as garânsje, en gjin fan 'e beide lêzingen folget út 'e waarnimming.

It ferdigenbere bewiis is de opname: ynterface, bestimmingsadres, antwurd en tiidstimpel. Nim ien foar't de tunnel omheech komt en ien dêrnei, en fergelykje se de folgjende kear as in namme mislearret. Dat pear fertelt de folgjende persoan ek oft de flater yn oplossing, rûtes of it eigen tagongsbelied fan 'e resolver siet.