DNS در Azure P2S شکست می‌خورد وقتی resolver در VNet همتا قرار دارد

به VM پینگ کنید و پاسخ می‌دهد؛ نامش را بپرسید و کلاینت می‌گوید میزبان ناشناخته است. وقتی resolver در یک شبکه مجازی همتا قرار دارد نه در شبکه‌ای که gateway VPN را دارد، این جفت نتیجه قابل انتظار است و هیچ مقدار عیب‌یابی resolver آن را تغییر نمی‌دهد. آنچه غایب است یک قرارداد مسیریابی است که peering به‌طور پیش‌فرض نگه می‌دارد. دو توپولوژی روی کاغذ تقریباً یکسان به نظر می‌رسند و فاصله میان کارکردن و خرابی یک جفت کلید peering است که در جهت درست تنظیم شده‌اند.

یک لپ‌تاپ را تصور کنید که به gateway در VNet2 تونل می‌زند، در حالی که کنترلر دامنه‌ای که DNS سرویس می‌دهد در VNet1 نشسته است.

دو توپولوژی، یک تفاوت

resolver را داخل شبکه مجازی خود gateway بگذارید و نام همان لحظه‌ای که تونل بالا می‌آید حل می‌شود. هیچ تنظیم peering در آن جست‌وجو شرکت نمی‌کند.

همان resolver را به آن سوی یک peering ببرید و کلاینت همچنان از VM پاسخ می‌گیرد در حالی که نام ناشناخته می‌ماند. گواهی، تونل و کلاینت تغییر نکرده‌اند. تنها چیزی که جابه‌جا شد این است که resolver کجا زندگی می‌کند. peering به آن مسیری به آن آدرس داد، نه اختیاری برای gateway تا ترافیک را به آنجا ببرد.

سمت A: عبور gateway را نزد مالک gateway مجاز کنید

peering دو شبکه مجازی را به هم می‌پیوندد، اما این پیوند برای ترافیکی که از طریق gateway می‌رسد تعدی نیست، و درخواست point-to-site دقیقاً همین‌گونه می‌رسد. بنابراین gateway در VNet2 اختیاری برای سپردن جست‌وجو به VNet1 ندارد تا طراحی آن را مجاز کند. مجوز یک کلید روی peering است که شبکه دارنده gateway مالک آن است.

Allow gateway transit را روی peering از VNet2 به سمت VNet1 تنظیم کنید. این ویژگی متعلق به شیء peering است نه منبع gateway، پس آن را در تیغه peering می‌خوانید و تغییر می‌دهید. تمام سمت A همین است.

سمت B: از gatewayهای راه دور روی همتا استفاده کنید

نیمه دیگر تصویر آینه‌ای است: روی peering از VNet1 به بازگشت به VNet2، Use remote gateways را فعال کنید. روشن کردن همان پرچم در هر دو سر، یا فقط در یک سر، مسیری نیمه‌ساخته و نشانه اصلی را دست‌نخورده می‌گذارد. فقط شبکه دارای gateway VPN عبور را مجاز می‌کند و همتا سمتی است که از آن استفاده می‌کند.

هر دو ویژگی را روی هر دو شبکه بخوانید، به جای اعتماد به تیغه پورتالی که آخرین بار باز کردید.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

دیدن این جفت کنار هم سریع‌ترین راه گرفتن یک تنظیم معکوس است. یک peering که در سمت gateway مقدار AllowGatewayTransit false گزارش می‌کند کل خرابی را بدون ضبط بسته توضیح می‌دهد.

آنچه کلاینت هنوز باید دریافت کند

مسیریابی لازم است و کافی نیست، چون پروفایل point-to-site باید نشانی DNS هم به کلاینت بدهد که وقتی عبور کار می‌کند پاسخ دهد. resolver پلتفرم آن نشانی نیست: به مناطق Azure Private DNS متصل به شبکه مجازی پاسخ می‌دهد، اما برای منطقه‌ای که روی سرورهای دایرکتوری خودتان میزبانی می‌شود چیزی ندارد، و این استقرار دقیقاً از آن استفاده می‌کند. کلاینتی را به آن نشانه بگیرید و نام‌های عمومی شادمانه حل می‌شوند در حالی که میزبان داخلی ناشناخته می‌ماند.

پیش از تغییر هر چیز دیگری، resolver را از لپ‌تاپ متصل پرس‌وجو کنید.

nslookup dc01.corp.example 10.1.0.4

یک وقفه زمانی می‌گوید مسیر هنوز غایب است. پاسخ معتبر مسئله را به کلاینت برمی‌گرداند، معمولاً پسوندی که هرگز افزوده نمی‌شود، پس نام‌های کوتاه به resolver عمومی می‌روند که شادمانه آن‌ها را شکست می‌دهد.

همان قرارداد را در سمت سایت به سایت مقایسه کنید

هیچ‌یک از این‌ها به‌طور خاص مربوط به لپ‌تاپ‌ها نیست. کلاینت را با یک شعبه در سایت به سایت عوض کنید و شرط دو طرفه برمی‌گردد: شعبه مستقیماً به شبکه gateway می‌رسد و سرویسی در فاصله دو شبکه هنوز پشت peering است.

عبور باید در هر دو peering اعطا شود و کلیدی که آن را اعطا می‌کند روی peering زندگی می‌کند نه روی نوع کلاینت.

پیش از سرزنش gateway

ویندوز برای هر آداپتور فهرستی از resolver نگه می‌دارد، پس پیش از سرزنش gateway تأیید کنید که رابط تونل واقعاً چه دریافت کرده است.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

پاسخ منفی در حافظه پنهان از اصلاح مسیریابی بیشتر عمر می‌کند و فهرست پسوند کهنه به فرستادن پرس‌وجوها به جایی ادامه می‌دهد که هرگز منطقه را میزبانی نکرده است. پاک کنید، دوباره بپرسید و یادداشت کنید کدام سرور پاسخ می‌دهد.

دو شرط کوچک‌تر تعیین می‌کند که مسیر می‌ماند یا نه: فضاهای نشانی نباید هم‌پوشانی داشته باشند، و گروه امنیتی شبکه در زیرشبکه resolver باید استخر کلاینت را بپذیرد، که فقط یک محدوده مبدأ دیگر است. این را با بررسی مسیرهای مؤثر از سمت VM به‌همراه یک پرس‌وجوی مستقیم از کلاینت اثبات کنید تا مشکل منطقه، مشکل پسوند یا فیلتر هرگز با فقدان عبور اشتباه نشود.