VPN-нің DNS-і шын мәнінде қолданыла ма? 53-портты ұстап көріңіз

Көпшіліктен VPN клиенті DNS-пен не істейді деп сұрасаңыз, олар шешушіні орнатады, сондықтан сұраулар туннель ішінде жүреді дейді. Итеру шынайы; оның сұрауға айналады деген болжам жоқ. Итерілген опция мен сымдағы пакеттің арасында үш кезең бар, және әрқайсысы дербес сәтсіздікке ұшырайды, олардың бәрі бүлінген DNS серверіне ұқсайды. Сондықтан ағу тестінің беті мен жұмыс істеп тұрған браузер бір мезетте бір машина туралы келіспей қалуы мүмкін.

Итерілген опция сұрау емес

Бірінші кезең — сервер баптауларды ұсынады, мысалы туннель ішіндегі шешушіні атайтын итерілген DNS опциясы. Екінші кезең — клиент сол баптауларды интерфейске қолданады. Үшінші кезең — қолданба шынымен сол мекенжайға сұрау жібереді. Екінші кезеңдегі сәтсіздік опцияны қосылым журналында көрінетін күйде қалдырады, ал шешушілер тізімі өзгеріссіз қалады, үшінші кезеңдегі сәтсіздік толық дұрыс шешушілер тізімін пайдаланылмай қалдырады.

Ақаулықтарды жоюдың көбі осы үшеуін біріктіріп, VPN серверін кінәлайды, ал әдетте өз үлесін орындағанын дәлелдей алатын жалғыз тарап сол. Оның орнына клиенттің нақты шешуші күйін оқып, содан кейін бір сұраудың шығуын бақылаңыз. Осы екі байқау конфигурацияны маршруттаудан және саясаттан ажыратады, және оларға шамамен бес минут кетеді. Түсірілімдерді сақтап қойыңыз, өйткені келесі инженер олардың сипаттамасын емес, алдыңғы мен кейінгі күйді қалайды.

Интерфейс шын мәнінде немен ұстайтынын тексеріңіз

Linux-та жүйелік шешуші қарапайым файл, NetworkManager немесе systemd-resolved болуы мүмкін, және оның қайсысы иеленетіні итерілген сервердің қайда қонатынын анықтайды. Пәрмен жолындағы OpenVPN процесі жүйелік шешушіні өзі жаңартпайды, сондықтан құжатталған интеграция — up/down скрипті немесе баптауларды қолдануды білетін қосылым менеджері. Екеуін бірге жүргізу жарыс жасаудың тиімді жолы.

resolvectl status
cat /etc/resolv.conf

Windows-та тізім әр адаптер үшін жеке, сондықтан туннель адаптері ішкі серверлерді ұстай алады, ал физикалық адаптер жергіліктілерді сақтап, кейбір атаулар үшін жеңеді. Белсенді деп ойлаған адаптерді емес, екеуін де салыстырыңыз.

Бір сұрауды машинадан тысқары шығарып бақылаңыз

Екі интерфейсті де бір уақытта түсіріңіз, содан кейін ішкі шешушіні қолдануы тиіс бір атауды шешіңіз. Сол жұп түсірілім кез келген конфигурация шығысы жауап бере алмайтын нәрсеге жауап береді.

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

Физикалық интерфейсте пайда болып, туннельде ешқашан көрінбейтін сұрау клиенттің дұрыс емес шешуші таңдағанын білдіреді. Екеуінен де көрінбейтін сұрау қолданбаның кэштен жауап бергенін, loopback-те тыңдайтын stub-тан сұрағанын немесе трафигі 53-порт ретінде ешқашан көрінбейтін шифрланған шешушіні қолданғанын білдіреді. Тек сұрауларды емес, жауаптарды да түсіріңіз, өйткені туннель арқылы шыққан сұрауға ашық мекенжайдан жауап келуі жауаптың мүлде келмеуінен басқа ақау.

Тек өз DNS-ін қабылдайтын желілік қалқан

Коммерциялық клиенттер кейде өз сүзгі тізбектерін орнатады. Бір құжатталған үлгі DNS-ке клиенттің өз шешушісіне рұқсат береді және loopback емес интерфейстен шығуға тырысатын барлық қалған UDP 53-порт трафигін тастайды, оның ішінде пайдаланушы әдейі басқа жаққа бағыттаған трафик те бар. Демон сұраулары ізсіз жоғалады, бұл сүзгі емес, шешуші ақауы ретінде оқылады.

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

Егер тастау ережесі сіздің ерекшелігіңізден бұрын бағаланса, қосылған ережеге ешқашан жетпейді, сондықтан оны бірінші орынға қойып, межені шын мәнінде көздеген шешушімен шектеңіз.

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

Бұл ерекшелік саясат емес, диагностика. Егер жеткізуші ережесі әдейі болса, қолдау көрсетілетін жөндеу — клиентті сол шешушіге рұқсат беретіндей баптау және шешімді жазу, өйткені қосылған ереже келесі клиент жаңартуынан аман қалмайды.

Неге ағу беті көрінгеннен аз дәлелдейді

Ағу тестінің беті көрсететін нәрсе — тест операторымен сөйлескен шешуші, сіздің машинаңыз жүгінген шешуші емес. Сыртқа рекурсия жасайтын жергілікті жіберуші өз шығу мекенжайын сол бетке қояды, ал шифрланған сұраулар бетті мүлде бос қалдыруы мүмкін. Екі нәтиже де дұрыс оқылмайды, біреуі ағу, екіншісі кепілдік ретінде, және екі оқылымның ешқайсысы байқаудан туындамайды.

Қорғауға болатын дәлел — түсірілім: интерфейс, межелік мекенжай, жауап және уақыт белгісі. Туннель көтерілмес бұрын біреуін, кейін біреуін алыңыз, және келесі жолы атау сәтсіз болғанда оларды салыстырыңыз. Бұл жұп келесі адамға ақау шешуде, маршруттауда әлде шешушінің өз қатынас саясатында болғанын да айтады.