Word jou VPN se DNS werklik gebruik? Vang poort 53 en sien self

Vra die meeste mense wat 'n VPN-kliënt met DNS doen, en hulle sal sê dit stel die oplosser in, so navrae reis binne die tonnel. Die stoot is werklik; die aanname dat dit 'n navraag word, is nie. Tussen 'n gestuurde opsie en 'n pakket op die draad lê drie fases, en elkeen faal onafhanklik op maniere wat almal soos 'n stukkende DNS-bediener lyk. Daarom kan 'n lektoets-bladsy en 'n werkende blaaier op dieselfde oomblik oor dieselfde masjien verskil.

'n Gestuurde opsie is nie 'n navraag nie

Fase een is die bediener wat instellings aanbied, byvoorbeeld 'n gestuurde DNS-opsie wat 'n oplosser binne die tonnel noem. Fase twee is die kliënt wat daardie instellings op 'n koppelvlak toepas. Fase drie is 'n toepassing wat werklik 'n navraag na daardie adres stuur. 'n Faling in fase twee laat die opsie sigbaar in die verbindingslog terwyl die oplosserlys onveranderd bly, en 'n faling in fase drie laat 'n heeltemal korrekte oplosserlys ongebruik.

Die meeste foutopsporing val daardie drie saam in een en blameer die VPN-bediener, wat die enigste party is wat gewoonlik kan bewys hy het sy deel gedoen. Lees eerder die kliënt se werklike oplosserstand, en kyk dan hoe een navraag vertrek. Daardie twee waarnemings skei konfigurasie van roetering van beleid, en hulle kos omtrent vyf minute. Hou die opnames, want die volgende ingenieur wil die voor en na hê, nie 'n beskrywing daarvan nie.

Kyk wat die koppelvlak werklik hou

Op Linux kan die stelseloplosser die gewone lêer, NetworkManager of systemd-resolved wees, en watter een daarvan dit besit, bepaal waar 'n gestuurde bediener beland. 'n Opdragreël-OpenVPN-proses werk nie vanself die stelseloplosser by nie, so die gedokumenteerde integrasie is 'n op/af-skrip of 'n verbindingsbestuurder wat al weet hoe om die instellings toe te pas. Om albei te laat loop is 'n doeltreffende manier om 'n resies te skep.

resolvectl status
cat /etc/resolv.conf

Op Windows is die lys per adaptor, so die tonneladaptor kan die interne bedieners hou terwyl die fisiese adaptor die plaaslike s'n hou en vir sommige name wen. Vergelyk albei adaptors eerder as die een wat jy aanneem aktief is.

Volg een navraag van die masjien af

Vang albei koppelvlakke gelyktydig, en los dan een naam op wat die interne oplosser behoort te gebruik. Daardie paar opnames beantwoord wat geen konfigurasie-uitset kan nie.

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

'n Navraag wat op die fisiese koppelvlak verskyn en nooit in die tonnel nie, beteken die kliënt het die verkeerde oplosser gekies. 'n Navraag op geen van albei nie beteken die toepassing het uit die kas geantwoord, 'n stub op loopback gevra, of 'n versleutelde oplosser gebruik wie se verkeer glad nie as poort 53 verskyn nie. Vang antwoorde sowel as navrae, want 'n navraag wat deur die tonnel vertrek met 'n antwoord van 'n openbare adres is 'n ander fout as geen antwoord wat aankom nie.

Die vuurmuur wat net sy eie DNS aanvaar

Kommersiële kliënte installeer soms hul eie filterkettings. Een gedokumenteerde patroon laat DNS na die kliënt se eie oplosser toe en gooi alle oorblywende UDP-poort 53-verkeer weg wat probeer om 'n nie-loopback-koppelvlak te verlaat, insluitend verkeer wat die gebruiker doelbewus elders heen gerig het. Daemon-navrae verdwyn sonder 'n spoor, wat as 'n oplosserfout eerder as 'n filter gelees word.

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

As 'n wegdoenreël voor jou uitsondering geëvalueer word, word 'n bygevoegde reël nooit bereik nie, so voeg op posisie een in en beperk die bestemming tot die oplosser wat jy werklik bedoel.

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

Daardie uitsondering is diagnosties eerder as beleid. As die verskaffer se reël doelbewus is, is die ondersteunde herstel om die kliënt te konfigureer om daardie oplosser toe te laat en die besluit op te teken, want 'n ingevoegde reël sal nie die volgende kliëntopgradering oorleef nie.

Waarom 'n lekbladsy minder bewys as wat dit lyk

Wat 'n lektoets-bladsy wys, is die oplosser wat met die toetsoperateur gepraat het, nie die een wat jou masjien geraadpleeg het nie. 'n Plaaslike deurstuurder wat na buite rekursie doen, sit sy eie uitgangsadres op daardie bladsy, en versleutelde navrae kan die bladsy heeltemal leeg laat. Albei resultate word verkeerd gelees, die een as 'n lek en die ander as 'n waarborg, en geen van die twee lesings volg uit die waarneming nie.

Die verdedigbare bewyse is die opname: koppelvlak, bestemmingsadres, antwoord en tydstempel. Neem een voordat die tonnel opkom en een daarna, en vergelyk hulle die volgende keer as 'n naam faal. Daardie paar sê ook vir die volgende persoon of die fout oplossing, roetering of die oplosser se eie toegangsbeleid was.