Azure жеке DNS VPN арқылы: resolver соңғы нүктесі немесе forwarder
Екі дизайн да жеке аймақтарға туннель арқылы жауап береді. Басқарылатын кіріс соңғы нүктесін forwarder VM-мен салыстырыңыз, содан кейін екі жағдайда да болуы керек жолды тексеріңіз.
Жергілікті желідегі сервер Azure VM-ге жеке мекенжай арқылы жетеді, бірақ оның жеке хост атауын шеше алмайды, бұл адамдарды бұзылған туннель іздеуге итермелейді. Туннель дұрыс. Жетіспейтіні — DNS шекарасы: жергілікті жақта нақты бір Azure жеке аймағына VNet ішіндегі resolver жауап беруі керектігін ешкім білмейді. Бұл олқылықты екі дизайн жабады және олар соңында нені басқаратыныңызбен ерекшеленеді, сұраулардың жұмыс істеуімен емес.
Туннель сұрауларды тасымалдайды, аймақ туралы білімді емес
Site-to-site қосылымы пакеттерге екі желі арасында маршрут береді. Ол жергілікті DNS серверіне қай атау кеңістігі Azure-ге тиесілі екенін немесе қай мекенжай жауап беруі керегін айтпайды, сондықтан сұрау не интернетке шығып бос қайтады, не жергілікті resolver-ден ешқашан шықпайды.
Түзетудің оңай бөлінетін екі жартысы бар. Бір жартысы — туннель арқылы келетін сұрауларды қабылдайтын VNet ішіндегі resolver. Екіншісі — дәл бір атау кеңістігін сол resolver-ге жіберетін жергілікті жақтағы шартты forwarder. Ешбір жарты жалғыз жұмыс істемейді.
Осы сипаттаманың қалғаны үшін аймақ cloud.corp.example деп есептеңіз және әр мекенжайды мысал ретінде қарастырыңыз.
A нұсқасы: басқарылатын кіріс соңғы нүктесі
Azure DNS Private Resolver VNet сыртынан келетін DNS сұрауларын қабылдайтын кіріс соңғы нүктесін ұсынады. Сіз оны арнайы делегацияланған қосымша желіге орналастырасыз, жеке аймақты сол VNet-ке қосасыз және қызмет беретін кіріс мекенжайын жазып аласыз.
Содан кейін жергілікті DNS серверінде нақты атау кеңістігі үшін сол мекенжайға бағытталған шартты forwarder жасайсыз:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-тың гибридті DNS процедурасы аймақты байланыстыруды да, forwarder қадамын да құжаттайды. Басқарылатын жол сізге жамайтын DNS бағдарламалық жасақтамасын қалдырмайды, ал соңғы нүктенің мекенжайы ресурстың бүкіл өмірі бойы тұрақты болып қалады.
Бағасы — енді сізде resolver ресурсы, оның қосымша желілік делегациясы және оның құны бар, бұл сұрау көлемі өте аз болса да нақты.
B нұсқасы: VNet ішіндегі forwarder VM
Ескі дизайн DNS бағдарламалық жасақтамасын VNet-тегі қарапайым VM-де іске қосады: Windows DNS, BIND немесе dnsmasq, жеке аймақ жергілікті түрде орналастырылады немесе 168.63.129.16 мекенжайындағы Azure resolver-іне жіберіледі. Жергілікті шартты forwarder сол VM-нің жеке мекенжайына сілтейді.
Бұл нұсқа DNS серверлерін әлдеқашан басқаратын командаларға таныс және журналдау немесе split-horizon жауаптары сияқты қосымша логиканы көтере алады. Ол сондай-ақ DNS серверінің барлық операциялық міндеттерін мұраға алады: жамау, қолжетімділік үшін екінші дана, мониторинг және VM ауыстырылып, оның мекенжайы өзгерген кезде қайта құру жолы.
Қарапайым VNet хосты қызмет орнатылып, сол клиенттерге жауап беруге рұқсат алынғанша DNS проксиі емес, ал VM клондау кезінде адамдар дәл осы қадамды өткізіп жібереді.
Қайсысы сіздің операцияңызға сәйкес
Салыстыру қай дизайн жылдамырақ дегенде емес. Ол DNS бағдарламалық жасақтамасын мүлде басқарғыңыз келе ме, және сұрау көлемі соңғы нүкте мен сұрау бойынша есептейтін басқарылатын ресурсты ақтай ма дегенде.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Қай жол шешсе де, жергілікті forwarder ережесі бірдей көрінеді. Дәл осы бөлік екі дизайнда да болуы керек және адам Azure ішінен шешу жұмыс істейтінін, ал кеңседен істемейтінін хабарлағанда ең жиі жетіспейтін бөлік те осы.
Жолды ретімен тексеріңіз
Аймақ resolver бар VNet-ке қосылғанын және жергілікті forwarder атау кеңістігін, ал ата-доменді емес, атайтынын растаңыз. corp.example үшін forwarder, resolver өзі делегацияламаса, cloud.corp.example-ке сәйкес келмейді, ал бұл сәйкессіздік жоғалған жазбаға ұқсайтын таза теріс жауап береді.
Содан кейін сұраудың соңғы нүктеге жететінін тексеріңіз: жергілікті көзге resolver мекенжайына маршрут және қайтару жолы қажет, ал 53 порты UDP және TCP бойынша саясат рұқсат ететін жерде ашық болуы керек. NSG жоғалған аймақ жазбасын бере алмайды, ал дұрыс аймақ ешқашан келмейтін сұрауға жауап бере алмайды.
Диагностика кезінде сұралған FQDN-ді таңдалған resolver-дің қасында ұстаңыз және тайм-аутты теріс жауаптан ажыратыңыз. Тайм-аут — жол немесе саясат мәселесі. Теріс жауап сұраудың келгенін және атау кеңістігінің сәйкес келмегенін білдіреді. Жұмыс тәртібі: аймақты қосыңыз, шартты forwarder қосыңыз, 53 портын екі бағытта ашыңыз, жергілікті жақтан бір атауды тексеріңіз, содан кейін ғана қолданбаның өз авторизациясына қараңыз.