Приватен DNS во Azure преку VPN: крајна точка на resolver или forwarder

Сервер во локалната мрежа достигнува Azure VM преку приватна адреса и сепак не може да го реши неговото приватно име на домаќин, што ги тера луѓето да бараат расипан тунел. Тунелот е во ред. Недостасува DNS граница: ништо на локалната страна не знае дека на одредена приватна зона на Azure треба да одговори resolver внатре во VNet. Два дизајни ја затвораат таа празнина и тие се разликуваат по тоа што на крајот управувате, а не по тоа дали барањата работат.

Тунелот пренесува барања, не знаење за зоните

Врската од локација до локација им дава на пакетите маршрута помеѓу двете мрежи. Таа не му кажува на локалниот DNS сервер кој простор од имиња припаѓа на Azure или која адреса треба да одговори, па барањето или оди на интернет и се враќа празно, или никогаш не го напушта локалниот resolver.

Поправката има две половини што лесно се одделуваат. Едната половина е resolver внатре во VNet што прима барања што пристигнуваат преку тунелот. Другата е условен forwarder на локалната страна што испраќа точно еден простор од имиња до тој resolver. Ниту една половина не работи сама.

Претпоставете дека зоната е cloud.corp.example за остатокот од овој опис и третирајте ја секоја адреса како илустративна.

Опција A: управуваната влезна крајна точка

Azure DNS Private Resolver обезбедува влезна крајна точка што прима DNS барања од надвор од VNet. Ја распоредувате во посветена делегирана подмрежа, ја поврзувате приватната зона со таа VNet и ја запишувате влезната адреса што ја доделува услугата.

Потоа на локалниот DNS сервер создавате условен forwarder за точниот простор од имиња кон таа адреса:

Namespace: cloud.corp.example
Forward to: 10.20.2.4

Microsoft постапката за хибриден DNS документира и поврзувањето на зоната и чекорот со forwarder. Управуваниот пат не ви остава DNS софтвер за крпење, а адресата на крајната точка останува стабилна во целиот животен век на ресурсот.

Цената е што сега поседувате resolver ресурс, неговото делегирање на подмрежа и неговиот трошок, што е реално дури и кога обемот на барања е мал.

Опција B: forwarder VM внатре во VNet

Постариот дизајн извршува DNS софтвер на обичен VM во VNet: Windows DNS, BIND или dnsmasq, при што приватната зона е или локално хостирана или препратена до Azure resolver на 168.63.129.16. Локалниот условен forwarder покажува кон приватната адреса на тој VM.

Оваа опција им е позната на тимови што веќе управуваат DNS сервери и може да носи дополнителна логика како евидентирање или split-horizon одговори. Таа ги наследува и сите оперативни обврски на DNS сервер: крпење, втор примерок за достапност, следење и пат за повторна изградба кога VM се заменува и неговата адреса се менува.

Обичен VNet домаќин не е DNS прокси додека услугата не се инсталира и не добие дозвола да им одговара на тие клиенти, а тоа е чекорот што луѓето го прескокнуваат при клонирање на VM.

Кој одговара на вашето работење

Споредбата не е за тоа кој дизајн е побрз. Таа е за тоа дали воопшто сакате да управувате со DNS софтвер и дали обемот на барања го оправдува управуваниот ресурс што се наплатува по крајна точка и по барање.

Кој ред и да одлучи, правилото за forwarder на локалната страна изгледа исто. Тоа е делот што мора да постои во двата дизајна и тоа е делот што најчесто недостасува кога некој известува дека решавањето работи од внатре во Azure, но не од канцеларија.

Проверете го патот по ред

Потврдете дека зоната е поврзана со VNet што го содржи resolver и дека локалниот forwarder го именува просторот од имиња, а не родителски домен. Forwarder за corp.example нема да се совпадне со cloud.corp.example освен ако самиот resolver не делегира, а несовпаѓањето дава чист негативен одговор што изгледа како запис што недостасува.

Потоа проверете дали барањето стигнува до крајната точка: локалниот извор бара маршрута до адресата на resolver и повратен пат, а портата 53 треба да биде дозволена и за UDP и за TCP каде што политиката го дозволува. NSG не може да обезбеди запис за зона што недостасува, а точната зона не може да одговори на барање што никогаш не пристигнува.

Кога дијагностицирате, држете го бараното FQDN до избраниот resolver и одделете го истекот на времето од негативниот одговор. Истекот на времето е проблем со патот или политиката. Негативниот одговор значи дека барањето пристигнало и просторот од имиња не се совпаднал. Ред на работа: поврзете ја зоната, додајте условен forwarder, отворете порта 53 во двете насоки, тестирајте едно име од локалната страна и само потоа погледнете ја сопствената авторизација на апликацијата.