د VPN له لارې د Azure شخصي DNS: د resolver پای ټکی که forwarder
دواړه ډیزاینونه د تونل له لارې شخصي زونونو ته ځواب وایي. مدیریت شوی دننه راتلونکی پای ټکی له forwarder VM سره پرتله کړئ، بیا هغه لاره وګورئ چې په دواړو حالتونو کې باید وي.
په سیمه کې یو سرور د شخصي پتې له لارې Azure VM ته رسېږي او بیا هم د هغې شخصي کوربه نوم حل نه شي کولی، چې خلک د مات شوي تونل په لټه کې کوي. تونل سم دی. کموالی د DNS پوله ده: په سیمه کې هیڅوک نه پوهېږي چې یوه ټاکلې شخصي Azure زون باید د VNet دننه resolver ځواب کړي. دوه ډیزاینونه دا تشه ډکوي، او دوی په دې توپیر لري چې تاسو په پای کې څه مدیریت کوئ، نه په دې چې پوښتنې کار کوي که نه.
تونل پوښتنې وړي، د زون پوهه نه
سایټ تر سایټ اړیکه بستې د دوو شبکو ترمنځ لاره ورکوي. دا سیمه ایز DNS سرور ته نه وایي چې کوم نوم ځای Azure پورې اړه لري یا کوم پته باید ځواب ووایي، نو پوښتنه یا انټرنېټ ته ځي او خالي راګرځي، یا هېڅکله سیمه ایز resolver نه پرېږدي.
د حل دوه نیمې برخې دي چې په اسانۍ سره جلا کېدای شي. یوه نیمه د VNet دننه resolver ده چې د تونل له لارې راغلې پوښتنې مني. بله نیمه په سیمه ایزه خوا کې شرطي forwarder ده چې په دقیق ډول یو نوم ځای هغه resolver ته لېږي. هیڅ نیمه یې یوازې کار نه کوي.
د دې تشریح پاتې برخې لپاره فرض کړئ چې زون cloud.corp.example دی، او هر پته د بېلګې په توګه وګڼئ.
اختیار A: مدیریت شوی دننه راتلونکی پای ټکی
Azure DNS Private Resolver یو دننه راتلونکی پای ټکی برابروي چې د VNet له باندې راتلونکې DNS پوښتنې مني. تاسو دا په ځانګړي تفویض شوي فرعي شبکه کې ځای پرځای کوئ، شخصي زون له هغې VNet سره نښلوئ، او هغه دننه راتلونکې پته یادښت کوئ چې خدمت ټاکي.
بیا په سیمه ایز DNS سرور کې د دقیق نوم ځای لپاره هغې پتې ته شرطي forwarder جوړوئ:
Namespace: cloud.corp.example
Forward to: 10.20.2.4د Microsoft هایبرډ DNS پروسه هم د زون نښلول او هم د forwarder ګام مستند کوي. مدیریت شوې لاره تاسو ته د ترمیم کولو لپاره DNS سافټویر نه پرېږدي، او د پای ټکي پته د سرچینې په ټول ژوند کې ثابته پاتې کېږي.
بيه دا ده چې اوس تاسو یو resolver سرچینه، د هغې فرعي شبکې تفویض او لګښت لرئ، کوم چې د پوښتنو حجم ډېر کم وي هم ریښتینی دی.
اختیار B: په VNet دننه forwarder VM
زړه ډیزاین په VNet کې په عادي VM باندې DNS سافټویر چلوي: 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 دننه کار کوي خو له دفتر نه.
لاره په ترتیب سره وګورئ
ډاډ ترلاسه کړئ چې زون له هغې VNet سره نښلول شوې ده چې resolver لري، او سیمه ایز forwarder د پلار ډومین نه بلکې د نوم ځای نوم اخلي. د corp.example لپاره forwarder له cloud.corp.example سره سمون نه خوري پرته له دې چې resolver پخپله تفویض وکړي، او دا ناسمون د یو پاک منفي ځواب لامل کېږي چې د ورک ریکارډ په څېر ښکاري.
بیا وګورئ چې پوښتنه پای ټکي ته رسېږي: سیمه ایز سرچینه ته د resolver پتې ته لاره او د بېرته راګرځېدو لاره ورته ده، او 53 پورټ باید د UDP او TCP دواړو لپاره هغه ځای کې پرانیستل شي چې پالیسي اجازه ورکوي. NSG نشي کولی د زون ورک ریکارډ برابر کړي، او سم زون نشي کولی هغې پوښتنې ته ځواب ووایي چې هېڅکله نه رسېږي.
کله چې تشخیص کوئ د غوښتل شوې FQDN تر څنګ د غوره شوي resolver سره وساتئ، او د وخت پای له منفي ځواب څخه جلا کړئ. د وخت پای د لارې یا پالیسي ستونزه ده. منفي ځواب معنا دا ده چې پوښتنه ورسېده او نوم ځای سمون ونه خوړ. د کار ترتیب: زون ونښلوئ، شرطي forwarder ورزیات کړئ، 53 پورټ په دواړو خواوو پرانیزئ، له سیمې څخه یو نوم وآزموئ، او بیا وروسته د اپلیکیشن خپله اجازه وګورئ.