VPN менің DNS-імді өзгертті ме? Алдын және кейін салыстырыңыз
Профиль сұрауларыңызды әдейі жылжытуы мүмкін. VPN қосылуының алдында және кейін резолвер саясатын және нақты жауапты салыстырыңыз, бір айнымалыны ұстап тұрыңыз.
Туннельді қосасыз, жеке тақтаны ашасыз, және атау сіз ешқашан көрмеген мекенжайға шешіледі. Немесе керісінше болады: браузер жұмысын жалғастырады, ал командалық жол құралы кенеттен ештеңені шешпейді. Екі нәтиже де бір өзгерістен туындайды, және адамдар мұны әдетте VPN туралы «өз DNS-ін қолданады» деген бір сөйлеммен түсіндіреді, бұл жөндеуге немесе тексеруге жеткілікті дәл емес. Сол сөйлемде екі сұрақ жасырылған: бұл профиль қандай сұрауларды өзіне алуы керек, және машинаңыз оларды шынымен өзіне берілген резолверге жіберді ме? Оларды бөлек ұстау — бүкіл әдіс, өйткені оларды араластыратын тест екі бағытта да сенімді қате жауап береді.
Профиль неге мүлде резолвер береді
Туннель ішінде алыс ұшының артындағы атаулар әдетте тек сол желіде болатын мекенжайларға шешіледі. corp.internal сияқты жеке аймақтың жария делегациясы жоқ, сондықтан оған жауап беретін резолвер туннель ішінен қолжетімді болуы керек. Сол механизм екінші мақсатқа да қызмет етеді: сұраулар әйтпесе провайдеріңіз арқылы шығатын болса, алыс жақтағы резолвер сұрауды шифрланған жолдың ішінде ұстайды. Сондықтан DNS серверінің мекенжайы қосылым саясатының бөлігі ретінде келеді, машина үшін бір рет таңдаған жаһандық параметр ретінде емес.
Мекенжай өздігінен ештеңені шешпейді. Резолвер тек оған маршрут болған кезде ғана жауап бере алады, ал ең жиі кездесетін ақау — туннель тұрғанда ғана қолжетімді резолвер. Туннель құлап, саясат қалған кезде сұраулар жолы жоқ мекенжайға кетеді, ал белгісі таза қате емес, уақыттың бітуі. Бұл айырмашылық келесі тест нәтижесін оқығанда маңызды, өйткені уақыттың бітуі адамдарды ешқашан қатыспаған тасымал параметрлеріне жібереді.
Жауаптарды салыстырмас бұрын екі дизайнды салыстырыңыз
Толық туннель мен бөлінген DNS қарама-қарсы күтулер туғызады, және екеуі де ақау емес. Толық туннель астында әр сұрау провайдерге немесе корпоративтік резолверге ауысуы мүмкін, сондықтан қосылғаннан кейін жария атаулардың басқаша жауап беруі күтіледі. Бөлінген DNS астында тек тізімдегі домендер жеке резолверге барады, қалғаны жергілікті қалады; Windows-та домен тізімі Name Resolution Policy Table ішінде, macOS-та DNS параметрлерінің сәйкес домендерінде, ал systemd-resolved хостында әр қосылымның маршруттау домендерінде тұрады.
Бұл бірінші кезекте жасалатын салыстыру, өйткені ол ненің ақау саналатынын шешеді. Бөлінген DNS кезінде жаңа резолверден жауап беретін жария атау — зерттеуге тұрарлық нәрсе, ал дұрыс жауап беретін ішкі атау — жүйенің өз жұмысын істеп жатқаны. Толық туннель кезінде аномалия — әлі де провайдеріңіздің резолверінен жауап беретін жария атау. Microsoft-тың VPN атауларын шешу туралы құжаттамасы осы ережелердің Windows тәртібін, соның ішінде сәйкес саясат жазбасының адаптердің өз серверлерінен бұрын қалай қарастырылатынын сипаттайды.
Бөлмеде ұмытуға оңай үшінші резолвер де бар. Браузердің қауіпсіз DNS-і атауларды өзі шешеді және туннель операциялық жүйе саясатын өзгерткеннен кейін де жауап бере алады, сондықтан жүктелген бет браузер резолверінің жұмыс істегенін дәлелдейді, профильдің қолданылғанын емес. Егер тек браузер көрсететін нәрсені салыстырсаңыз, уақыттың жартысында қате қабатты тексересіз.
Тек бір айнымалымен бастапқы сызықты жазыңыз
Туннельді өзгертіңіз. Сол қадамда атауды, құралды немесе іздеу жұрнағын да өзгертпеңіз. Сұрауға рұқсатыңыз бар атауды таңдаңыз, қай қолданбаны қолданғаныңызды белгілеңіз және қайтарған мекенжайды немесе нақты қатені жазыңыз. Windows-та Get-DnsClientServerAddress -AddressFamily IPv4 әр адаптердің серверлерін, Get-DnsClientNrptPolicy саясат жазбаларын басып шығарады; systemd-resolved-пен Linux-та resolvectl status әр қосылымның DNS серверлері мен маршруттау домендерін көрсетеді; macOS-та scutil --dns жүйе шынымен ұстанатын резолвер тәртібін басып шығарады.
Содан кейін клиенттің әдеттегі басқару элементтері арқылы қосылып, дәл сол командаларды қайталаңыз. Бірінші шығысты есте сақтаудың орнына сақтап қойыңыз, өйткені салыстыру — бүкіл мәселе, ал кэшті тазартқаннан кейін алынған екінші оқу басқа өлшем. Егер бастапқы сызық браузер алдында тұрғанда алынса және қосылғаннан кейінгі іске қосу терминалда болса, сіз екі резолверді салыстырасыз, бір резолвердің екі күйін емес.
Айқын сұрау мен қолданба іздеуі — әртүрлі тесттер
Бір нақты серверден nslookup name 10.20.0.1 немесе dig @10.20.0.1 name арқылы сұрау бір нәрсені дәлелдейді: сіз атаған сервер оған жетуге болатын кезде жауап береді. Бұл таңдау логикасын толығымен айналып өтеді, сондықтан жүйе бұл атау үшін сол серверді таңдар ма еді, оны айта алмайды. Оны тағайындалған резолвердің қолжетімділігін тексеру үшін қолданыңыз, ал саясатты тексеру үшін қолданбаңыз.
Жергілікті резолвер арқылы іздеу шынымен таңдауды іске қосады. resolvectl query name сол маршруттау домені ережелерінен өтіп, қай протокол жауап бергенін хабарлайды, Windows-та Resolve-DnsName саясат кестесі мен клиент кэшінен өтеді, ал scutil --dns іздеу ұстанатын тәртіпті көрсетеді. Екі түрін де іске қосып, оларды жазбаларыңыздың бөлек бағандарында ұстаңыз. Сәтті айқын сұрау мен сәтсіз қолданба іздеуі қатар тұрса, бұл маршруттау немесе таңдау мәселесі, жұмыс істеуден бас тартқан резолвер емес.
Кэш сіз бен жауаптың арасында тұр. Операциялық жүйе, жергілікті stub резолвері, браузер және теріс кэш — барлығы нәтижелерді ұстайды, сондықтан бір пакет те машинадан шықпай-ақ іздеу сәтті болуы мүмкін. Нәтижені бірдеңені тазартпас бұрын жазыңыз: ipconfig /flushdns, resolvectl flush-caches немесе macOS-та sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Бұл кезеңде кең желі қалпына келтіруді өткізіп жіберіңіз, өйткені ол әлі жинап жатқан дәлелдеріңізді жояды.
Айырмашылық нені білдіреді
Жазған екі жолды салыстырыңыз және бір параметрге қол тигізбес бұрын өзгерісті жіктеңіз.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Бір жол ерекше назарға лайық. Шешілетін атау — жұмыс істейтін қызмет емес, ал DNS сәттілігі тек мекенжай табылғанын айтады. Ол қайта жіберу, өрт қабырғасы ережелері немесе тіркелгіңіздің қызметті мүлде пайдалана алатыны туралы ештеңе айтпайды, сондықтан ақау өзі кетті деп болжаудың орнына нақты қолданбаны тексерумен аяқтаңыз.
Бастапқы сызықты қалпына келтіріп, тексеріңіз
Процесті өлтірудің орнына клиенттің өз басқару элементтері арқылы ажыратыңыз, содан кейін сол үш команданы қайта оқыңыз. Әр қосылымның серверлері, саясат жазбалары және сынақ атауыңыздың жауабы бұрын жазған бастапқы сызыққа оралуы керек. Таза ажыратудан кейін қалған саясат жазбасы — жазып қоюға тұрарлық нақты ақау, және генерацияланған резолвер файлын қолмен өңдеу неге нашар әдет екені де сондықтан: файл қайта жазылады да өңдеу жоғалады, немесе өңдеу қалады да енді маршруты жоқ резолверді бекітіп қояды.
Бұл тізімді бір рет ретімен өтіңіз. Кез келген нәтижені бағаламас бұрын профиль қай дизайнды іске асыратынын шешіңіз. Екі іске қосуда атауды, құралды және жұрнақты бекітіп ұстаңыз. Айқын сұрауды қолданба іздеуінен бөлек қойыңыз. Тек жауапты емес, қолданыстағы саясатты оқыңыз. Кэштерді соңында, салыстыру жазылғаннан кейін тазартыңыз. Нақты қолданбамен тексеріңіз, содан кейін бір рет қайта жүктеп, ажыратылған күй әлі таза екенін растаңыз.