Прихващане на 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 отговор от връзката към услугата, която следва: разрешеният частен адрес все още се нуждае от маршрут и разрешение от приложението.