Split-DNS жазуы: әр бақылау қай жерде алынғанын айтыңыз

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

Бір іздеу, бірнеше бақылау нүктесі

Бір ішкі атау үшін қарауға кемінде бес орын бар: қолданба және ол шақыратын resolver API, клиенттегі қолданыстағы домен саясаты, адаптерде немесе сүзгіде жазу, бақыланатын шлюз шекарасы және сұранысты шын мәнінде қабылдайтын resolver.

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

Адаптердегі жазу пакеттерді көрсетеді, ниетті емес. Ол клиент қай resolver таңдағанын айтпайды, ал бос жазу пакеттің тасталғанын емес, кэштелген жауапты немесе басқа resolver API-ін білдіруі мүмкін. Әр бақылауды бір кезең туралы дәлел ретінде қарастырыңыз. Содан кейін кезеңдерді жолға біріктіріңіз.

Клиент сүзгісі қолданба мен сым арасында тұр

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

Cisco-ның Secure Client Split-DNS нұсқаулығы домен сәйкестігі мен Windows сүзгісін қамтиды және қолданбаның жергілікті resolver API-ін пайдаланған кезде көретінін nslookup сияқты құрал көретіннен бөледі. Дәл осы айырмашылықтар маңызды.

Қолданыстағы профильден және қолданбаның бір қарапайым іздеуінен бастаңыз. Нақты серверді атайтын кез келген тест — әдейі жасалған айналма жол; оны клиенттің өз диагностикасымен түсіндіріңіз және қабылдау критерийіне айналуына жол бермеңіз.

nslookup қолданбадан өзге жолмен жүреді

nslookup өзінің DNS сұранысын құрады және операциялық жүйенің resolver саясатын айналып өте алады. Бұл оны нақты серверге нақты сұрақ қою үшін пайдалы құрал етеді, ал қолданбаның не сезінетінін тексеру үшін жаңылыстыратын құрал етеді.

Windows-та атауларды шешу саясаты кестесі қай суффикстің қай серверді пайдаланатынын шешеді. Оны оқу қолданба ұстанатын саясатты көрсетеді, және көбінесе дәл сол жетіспейтін бөлік болады.

Саясатты оқып, содан кейін сол сұрақты кәдімгі resolver арқылы қойыңыз:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Шифрланған resolver-лер сұранысты жасырады, байланысты емес

Өзінің DNS-over-HTTPS resolver-і бар браузер мүлде басқа жағдай. Сұраныс TLS ішінде шығады, сондықтан пакет жазу resolver мекенжайына байланысты көрсетеді, бірақ сұралған атауды көрсетпейді.

Алдымен браузердің басқарылатын саясатын анықтаңыз, содан кейін оны операциялық жүйе іздеуімен салыстырыңыз. Өз resolver-ін таңдауға рұқсат берілген браузер Split-DNS саясатын мүлде көрмеуі мүмкін.

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

Белгіленген тестімен салыстырыңыз

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

Рұқсат етілген жерлерде resolver-дің қабылдауын клиенттің немесе шлюздің бір тар бақылауымен салыстырыңыз:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Тек салыстыру жасау үшін жеке атауларды байланыссыз жария resolver-лерге ешқашан жібермеңіз және бөлісетіннің бәрін редакциялаңыз. Соңында, дұрыс DNS жауабын одан кейін келетін қызмет байланысынан бөліңіз: шешілген жеке мекенжай әлі де маршрут пен қолданба рұқсатын қажет етеді.