DNS خصوصی Azure روی VPN: نقطه پایانی resolver یا forwarder
هر دو طراحی به مناطق خصوصی از طریق تونل پاسخ می‌دهند. نقطه پایانی ورودی مدیریت‌شده را با ماشین مجازی forwarder مقایسه کنید، سپس مسیری را که در هر دو حالت باید وجود داشته باشد بررسی کنید.
یک سرور در محل از طریق نشانی خصوصی به ماشین مجازی Azure می‌رسد و باز هم نمی‌تواند نام میزبان خصوصی آن را حل کند، که افراد را به دنبال تونل خراب می‌فرستد. تونل سالم است. چیزی که نیست یک مرز 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روش DNS هیبریدی مایکروسافت هم پیوند منطقه و هم مرحله forwarder را مستند می‌کند. مسیر مدیریت‌شده هیچ نرم‌افزار DNS برای وصله کردن باقی نمی‌گذارد و نشانی نقطه پایانی در طول عمر منبع پایدار می‌ماند.
بهای آن این است که اکنون یک منبع resolver، تفویض زیرشبکه آن و هزینه‌اش را در اختیار دارید، که حتی وقتی حجم پرس‌وجو بسیار کم است واقعی است.
گزینه B: ماشین مجازی forwarder داخل VNet
طراحی قدیمی‌تر نرم‌افزار DNS را روی یک ماشین مجازی معمولی داخل VNet اجرا می‌کند: Windows DNS، BIND یا dnsmasq، با منطقه خصوصی که یا محلی میزبانی می‌شود یا به resolver ارائه‌شده Azure در 168.63.129.16 فرستاده می‌شود. forwarder شرطی محل به نشانی خصوصی آن ماشین اشاره می‌کند.
این گزینه برای تیم‌هایی که از قبل سرورهای DNS را اداره می‌کنند آشناست و می‌تواند منطق اضافی مثل ثبت لاگ یا پاسخ‌های split-horizon را حمل کند. همچنین هر وظیفه عملیاتی یک سرور DNS را به ارث می‌برد: وصله کردن، نمونه دوم برای دسترس‌پذیری، پایش و مسیر بازسازی وقتی ماشین مجازی جایگزین می‌شود و نشانی‌اش تغییر می‌کند.
یک میزبان معمولی VNet تا زمانی که سرویس نصب نشده و اجازه پاسخ دادن به آن کلاینت‌ها را نگرفته، پروکسی DNS نیست و همین مرحله است که مردم هنگام کلون کردن ماشین مجازی از آن می‌گذرند.
کدام به عملیات شما می‌خورد
مقایسه درباره این نیست که کدام طراحی سریع‌تر است. درباره این است که آیا اصلاً می‌خواهید نرم‌افزار 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 را در هر دو جهت باز کنید، یک نام را از محل آزمایش کنید و تنها بعد به مجوز خود برنامه نگاه کنید.