Приватни DNS у Azure-у преко VPN-а: крајња тачка resolver-а или forwarder
Оба дизајна одговарају на приватне зоне кроз тунел. Упоредите управљану улазну крајњу тачку са VM 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.4Microsoft-ов поступак хибридног DNS-а документује и повезивање зоне и корак са forwarder-ом. Управљана путања не оставља DNS софтвер за крпљење, а адреса крајње тачке остаје стабилна током целог века ресурса.
Цена је да сада поседујете resolver ресурс, његово делегирање подмреже и његов трошак, који је стваран чак и када је обим упита веома мали.
Опција B: forwarder VM унутар VNet-а
Старији дизајн покреће DNS софтвер на обичној VM у VNet-у: Windows DNS, BIND или dnsmasq, при чему је приватна зона или локално хостована или прослеђена resolver-у Azure на 168.63.129.16. Локални условни 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-а, али не из канцеларије.
Проверите путању редом
Потврдите да је зона повезана са VNet-ом који држи resolver и да локални forwarder наводи простор имена, а не родитељски домен. Forwarder за corp.example неће се поклопити са cloud.corp.example ако сам resolver не делегира, а неслагање даје чист негативан одговор који изгледа као запис који недостаје.
Затим проверите да ли упит стиже до крајње тачке: локални извор треба руту до адресе resolver-а и повратну путању, а порт 53 треба да буде дозвољен и за UDP и за TCP тамо где политика дозвољава. NSG не може да обезбеди запис зоне који недостаје, а исправна зона не може да одговори на упит који никада не пристигне.
Када дијагностикујете, држите тражени FQDN поред изабраног resolver-а и одвојите истек времена од негативног одговора. Истек времена је проблем путање или политике. Негативан одговор значи да је упит стигао и да се простор имена није поклопио. Редослед рада: повежите зону, додајте условни forwarder, отворите порт 53 у оба смера, тестирајте једно име из локалне мреже и тек онда погледајте сопствену ауторизацију апликације.