Azure özəl DNS-i VPN üzərində: resolver endpoint, yoxsa forwarder
Hər iki dizayn tunel üzərindən özəl zonalara cavab verir. İdarə olunan giriş endpointini forwarder VM ilə müqayisə edin, sonra hər halda mövcud olmalı olan yolu yoxlayın.
Şəbəkə daxilindəki server Azure VM-ə özəl ünvanla çatır, amma yenə də onun özəl host adını həll edə bilmir; bu isə insanları xarab tunel axtarmağa vadar edir. Tunel qaydasındadır. Çatışmayan DNS sərhədidir: şəbəkə daxilində heç nə bilmir ki, müəyyən bir Azure özəl zonasına VNet içindəki resolver cavab verməlidir. Bu boşluğu iki dizayn bağlayır və onlar sorğuların işləyib-işləməməsi ilə deyil, sonda nəyi idarə etdiyinlə fərqlənir.
Tunel zonanın biliyini deyil, sorğuları daşıyır
Sayt-sayt bağlantı paketlərə iki şəbəkə arasında marşrut verir. Lakin o, şəbəkədaxili DNS serverinə hansı ad məkanının Azure-a aid olduğunu və hansı ünvanın cavab verməli olduğunu demir, ona görə sorğu ya internetə gedib boş qayıdır, ya da yerli resolverdən heç vaxt çıxmır.
Həllin asanlıqla ayrılan iki yarısı var. Bir yarısı tunel üzərindən gələn sorğuları qəbul edən, VNet içindəki resolverdir. Digər yarısı isə dəqiq bir ad məkanını həmin resolverə göndərən, şəbəkə daxilindəki şərti forwarderdir. Heç bir yarısı tək işləmir.
Bu izahın qalanı üçün zonanın cloud.corp.example olduğunu fərz edin və hər ünvanı nümunəvi sayın.
Variant A: idarə olunan giriş endpointi
Azure DNS Private Resolver VNet-dən kənardan gələn DNS sorğularını qəbul edən giriş endpointi təqdim edir. Onu ayrılmış delegasiya edilmiş subnetə yerləşdirir, özəl zonanı həmin VNet-ə bağlayır və xidmətin təyin etdiyi giriş ünvanını qeyd edirsiniz.
Sonra şəbəkədaxili DNS serverində dəqiq ad məkanı üçün həmin ünvana istiqamətlənən şərti forwarder yaradırsınız:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-un hibrid DNS proseduru həm zona bağlantısını, həm də forwarder addımını sənədləşdirir. İdarə olunan yol sizdə yamaqlanacaq DNS proqramı qoymur və endpoint ünvanı resursun ömrü boyu sabit qalır.
Bunun qarşılığı odur ki, artıq bir resolver resursu, onun subnet delegasiyası və xərci sizin üzərinizdədir; bu xərc sorğu həcmi çox az olsa belə realdır.
Variant B: VNet içində forwarder VM
Köhnə dizayn VNet-dəki adi VM-də DNS proqramı işlədir: Windows DNS, BIND və ya dnsmasq; özəl zona ya yerli olaraq saxlanılır, ya da 168.63.129.16 ünvanındakı Azure resolverinə yönləndirilir. Şəbəkədaxili şərti forwarder həmin VM-in özəl ünvanına baxır.
Bu variant artıq DNS serverləri işlədən komandalara tanışdır və loglama və ya split-horizon cavabları kimi əlavə məntiq daşıya bilər. O, həm də DNS serverinin bütün əməliyyat vəzifələrini miras alır: yamaqlama, əlçatanlıq üçün ikinci instans, monitorinq və VM dəyişdirilib ünvanı dəyişdikdə yenidən qurma yolu.
Adi VNet hostu, xidmət quraşdırılmayana və həmin müştərilərə cavab verməyə icazə verilməyənə qədər DNS proxy deyil; VM kopyalayarkən insanların atladığı addım elə budur.
Hansı sizin əməliyyatınıza uyğundur
Müqayisə hansı dizaynın daha sürətli olması ilə bağlı deyil. Söhbət DNS proqramını ümumiyyətlə işlətmək istəyib-istəməməyinizdən və sorğu həcminin endpointə və sorğuya görə hesablaşan idarə olunan resursu doğruldub-doğrultmamasından gedir.
| 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 |
Hansı sətir qərar verirsə versin, şəbəkə daxilindəki forwarder qaydası eyni görünür. Məhz bu hissə hər iki dizaynda olmalıdır və insanlar Azure daxilində həllin işlədiyini, ofisdən işləmədiyini bildirdikdə ən çox çatışmayan hissə də budur.
Yolu sıra ilə yoxlayın
Zonanın resolveri saxlayan VNet-ə bağlı olduğunu və şəbəkədaxili forwarderin ana domeni deyil, ad məkanını göstərdiyini təsdiqləyin. corp.example üçün forwarder, resolver özü delegasiya etmirsə, cloud.corp.example ilə uyğunlaşmayacaq və uyğunsuzluq itkin qeyd kimi görünən təmiz mənfi cavab yaradır.
Sonra sorğunun endpointə çatdığını yoxlayın: şəbəkədaxili mənbəyə resolver ünvanına marşrut və geri yol lazımdır, siyasət icazə verdiyi yerdə həm UDP, həm də TCP portu 53 açıq olmalıdır. NSG itkin zona qeydini verə bilməz və düzgün zona heç vaxt çatmayan sorğuya cavab verə bilməz.
Diaqnostika edərkən tələb olunan FQDN-i seçdiyiniz resolverin yanında saxlayın və timeout-u mənfi cavabdan ayırın. Timeout yol və ya siyasət problemidir. Mənfi cavab sorğunun çatdığını və ad məkanının uyğun gəlmədiyini bildirir. İş sırası: zonanı bağlayın, şərti forwarder əlavə edin, portu 53 hər iki istiqamətdə açın, şəbəkə daxilindən bir ad sınayın və yalnız bundan sonra tətbiqin öz avtorizasiyasına baxın.