Захоп Split-DNS: пакажыце, дзе зроблена кожнае назіранне

Два чалавекі займаюцца адной і той жа праблемай Split-DNS і атрымліваюць розныя адрасы рэзалвера. Адзін карыстаўся інструментам пошуку, другі захапіў пакеты на адаптары, а трэці прачытаў уласную дыягностыку кліента. Ніхто з іх не хлусіць, і ніхто з іх не апісвае адзін і той жа этап. Назва пункту назірання ператварае супярэчнасць у карту.

Адзін пошук, некалькі пунктаў назірання

Для аднаго ўнутранага імені ёсць прынамсі пяць месцаў, дзе варта глядзець: праграма і API рэзалвера, якое яна выклікае, дзейная палітыка даменаў на кліенце, захоп на адаптары або фільтры, кантраляваная мяжа шлюза і рэзалвер, які фактычна атрымлівае запыт.

Кожнае з іх адказвае на іншае пытанне, і ні адно само па сабе не даказвае, куды пайшоў запыт.

Захоп на адаптары паказвае пакеты, а не намер. Ён не кажа, які рэзалвер выбраў кліент, а пусты захоп можа азначаць закэшаваны адказ ці іншае API рэзалвера, а не адкінуты пакет. Разглядайце кожнае назіранне як доказ пра адзін этап. Затым збярыце этапы ў шлях.

Фільтр кліента стаіць паміж праграмай і сеткай

VPN-кліент з Split-DNS ужывае супастаўленне даменаў перш чым пакет пакідае машыну. Імёны ў суфіксе тунеля ідуць да ўнутранага рэзалвера; усё астатняе ідзе да лакальнага. Фільтр — гэта палітыка, і палітыка можа адрознівацца ў залежнасці ад платформы і версіі кліента.

Указанні Secure Client па Split-DNS ад Cisco ахопліваюць супастаўленне даменаў і фільтр Windows, і яны аддзяляюць тое, што бачыць праграма, калі выкарыстоўвае роднае API рэзалвера, ад таго, што бачыць такі інструмент, як nslookup. Менавіта гэтыя адрозненні і важныя.

Пачніце з дзейнага профілю і аднаго звычайнага пошуку праграмы. Любы тэст, які называе пэўны сервер, — гэта наўмысны аб’езд; выкарыстоўвайце ўласную дыягностыку кліента, каб патлумачыць яго, і не дазваляйце яму стаць крытэрыем прыёмкі.

nslookup ідзе іншым шляхам, чым праграма

nslookup будуе ўласны DNS-запыт і можа абыйсці палітыку рэзалвера аперацыйнай сістэмы. Гэта робіць яго карысным інструментам, каб задаць пэўнаму серверу пэўнае пытанне, і падманным інструментам для праверкі таго, што адчуе праграма.

У Windows табліца палітыкі развязання імёнаў вызначае, які суфікс выкарыстоўвае які сервер. Яе чытанне паказвае палітыку, якой будзе ісці праграма, і часта гэта і ёсць адсутная частка.

Прачытайце палітыку і затым задайце тое ж пытанне праз звычайны рэзалвер:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Зашыфраваныя рэзалверы хаваюць запыт, а не злучэнне

Браўзер з уласным рэзалверам DNS-over-HTTPS — зусім іншы выпадак. Запыт выходзіць унутры TLS, таму захоп пакетаў паказвае злучэнне з адрасам рэзалвера, але не імя, пра якое пытаюцца.

Спачатку высветліце кіраваную палітыку браўзера, затым параўнайце яе з пошукам праз аперацыйную сістэму. Браўзер, якому дазволена выбіраць уласны рэзалвер, можа наогул не бачыць палітыку Split-DNS.

Тая ж перасцярога датычыцца любога кліента, які пастаўляе ўласны рэзалвер. Захоп, які вызначае выдаленае злучэнне, не з’яўляецца доказам пра імя запыту. Калі вам патрэбна імя, вазьміце яго з уласных журналаў рэзалвера або з дыягностыкі праграмы, з улікам прымяняльных правіл прыватнасці.

Параўнайце з пазначаным тэстам

Выберыце ўзгодненае ўнутранае імя для тэставання, а таксама публічнае імя, якое не нясе ніякага адчувальнага сэнсу. Для кожнага запішыце час, тып запісу, адказ і палітыку, якую вы чакалі.

Дзе гэта дазволена, параўнайце атрыманне рэзалвера з адным вузкім назіраннем кліента або шлюза:

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

Ніколі не адпраўляйце прыватныя імёны на незвязаныя публічныя рэзалверы проста каб стварыць параўнанне, і выдаляйце ўсё, чым дзеліцеся. Нарэшце, аддзяліце правільны адказ DNS ад злучэння з сэрвісам, якое ідзе следам: развязаны прыватны адрас усё яшчэ патрабуе маршруту і дазволу праграмы.