Снимање на 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 одговор од врската со услугата што следи: решената приватна адреса и понатаму бара маршрута и дозвола од апликацијата.