NAT در Azure VPN آدرس‌های VNet هم‌پوشان را حل نمی‌کند
دو VNet با یک محدوده خصوصی یکسان فقط به خاطر وجود NAT به هم وصل نمی‌شوند. ابتدا نوع اتصال را بررسی کنید، سپس دوباره شماره‌گذاری کنید یا صاحب یک نام مستعار ترجمه باشید.
هر دو VNet از 10.40.1.0/24 استفاده می‌کنند، تونل‌ها بالا می‌آیند و هیچ چیز کار نمی‌کند. افزودن یک دروازه VPN دوم این را تغییر نمی‌دهد، و نه معیار مسیر کم‌تر، چون مشکل انتخاب مسیر نیست. دو بار کاری که به یک آدرس خصوصی پاسخ می‌دهند، هر بسته را با مقصدی مبهم و مسیر بازگشتی غیرقابل بررسی رها می‌کنند. پیش از برنامه‌ریزی هر ترجمه‌ای، دریابید که در واقع کدام نوع اتصال را ساخته‌اید، چون همان یک انتخاب تعیین می‌کند که آیا قابلیت NAT در Azure اصلاً در دسترس است یا نه.
این نشانه در واقع چه چیزی به شما می‌گوید
وقتی میزبان در VNet A به 10.40.1.10 می‌فرستد، جدول مسیریابی فقط می‌تواند آن را جایی نشان دهد. اگر VNet B هم 10.40.1.10 را داشته باشد، آن آدرس مقصدی نیست که مسیر بتواند تشخیص دهد؛ یک آدرس با دو مالک است.
دروازه دومی که معمولاً مستقر می‌شود کمکی نمی‌کند. تونل دیگری به شما می‌دهد، نه آدرس دیگری، و محدوده تکراری بدون تغییر داخل تونل سفر می‌کند. همچنین پیکربندی‌ای را که باید سازگار نگه دارید دو برابر می‌کند. کاری که نمی‌تواند بکند این است که یک آدرس به معنای دو میزبان باشد.
تغییر آدرس‌های عمومی همتایان VPN هم کاری نمی‌کند. آن آدرس‌ها نقاط انتهایی تونل را مشخص می‌کنند، در حالی که برخورد در محدوده خصوصی نهفته است که داخل آن حمل می‌شود.
نوع اتصال تعیین می‌کند که NAT در دسترس است یا نه
Azure VPN Gateway واقعاً قابلیت NAT دارد و برای اتصالات IPsec بین‌سایتی مبتنی بر مسیر روی SKUهای مشخص دروازه مستند شده است. همان مستندات اتصالات VNet-to-VNet و point-to-site را حذف می‌کند، پس این ویژگی یک کادر انتخاب نیست که در هر رابطه دروازه ظاهر شود.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
VNet-to-VNet بومی هم از ابتدا مستلزم آن است که محدوده‌های VNet و شبکه محلی هم‌پوشانی نداشته باشند، که با این استثنا سازگار است. همتاسازی VNet هم به همان دلیل راه‌حل هم‌پوشانی نیست.
جایگزین پشتیبانی‌شده‌ای وجود دارد که مردم آن را با نوع بومی اشتباه می‌گیرند: VNet دیگر را به عنوان شبکه محلی مدل کنید و آن را به صورت اتصال سایت به سایت وصل کنید. این منبع متفاوت و طراحی متفاوتی است، پس با اتصال تغییرنام‌یافته به عنوان تغییری که باید اعتبارسنجی شود رفتار کنید، نه به عنوان یک تغییر نام ساده.
دوباره شماره‌گذاری کنید، یا با چیزی ترجمه کنید که مالک نام مستعار است
اگر هر دو VNet مال شما هستند، شماره‌گذاری مجدد برنامه‌ریزی‌شده را با هزینه مستمر ترجمه مقایسه کنید. شماره‌گذاری مجدد پیکربندی برنامه‌ها، رکوردهای DNS، قواعد امنیتی و هر اتصال موجود را لمس می‌کند، اما شبکه‌ای بر جای می‌گذارد که پس از آن به طور عادی خوانده می‌شود. آن را یک زیرشبکه در یک زمان انجام دهید و تغییر DNS را آخر بگذارید. محدوده نیمه‌شماره‌گذاری‌شده از هر دو گزینه بدتر است، چون آنگاه هر دو پیشوند برای کسی که دفعه بعد جدول را می‌خواند معتبر به نظر می‌رسند.
جایی که شماره‌گذاری مجدد عملی نیست، از طراحی ترجمه‌شده با مالک واقعی برای نام مستعار استفاده کنید. فراخوانندگان در VNet A ممکن است به 10.40.1.10 در VNet B به صورت 10.140.1.10 برسند، اما آن نام مستعار به دستگاهی نیاز دارد که ترجمه کند، مسیری به سوی آن، و رفتار منطبق برای پاسخ. آدرسی که فقط به DNS افزوده شود ترجمه نیست.
هر دو محدوده را در هر دو جهت ثبت کنید: آنچه فراخواننده شماره‌گیری می‌کند، آنچه مقصد به عنوان منبع می‌بیند، و کدام طرف می‌تواند آغازگر باشد. قواعد NAT خود Azure ترجمه معکوس را برای نگاشت‌های SNAT خود شامل می‌شوند، پس شما یک قاعده DNAT منطبق را دستی نمی‌نویسید، اما این راحتی در همان انواع اتصالی متوقف می‌شود که این ویژگی پشتیبانی می‌کند.
چه چیزی کار نخواهد کرد
یک مسیر تعریف‌شده توسط کاربر یا معیار مسیر نمی‌تواند تمایز آدرس از دست رفته را ایجاد کند. هر دو روی مقصدی کار می‌کنند که هنوز مبهم است، و بسته به هر گام بعدی که جدول ترجیح دهد می‌رسد.
افزودن محدوده تکراری به جدول مسیریابی به عنوان پیشوندی مشخص‌تر، ابهام را فقط یک قدم جابه‌جا می‌کند. همچنین تمایل دارد جهت دیگر را بشکند، جایی که پاسخ اکنون دو منبع محتمل دارد.
طراحی را با ترافیک در هر دو جهت بپذیرید
طراحی را با یک عملیات مجاز تازه از هر طرف اثبات کنید، نه با وضعیت تونل. یک تونل IPsec متصل می‌گوید همتایان درباره رمزنگاری توافق دارند؛ هیچ چیز درباره اینکه آیا مقصدها قابل تشخیص شده‌اند نمی‌گوید.
سپس مسیرهای رد شده را اجرا کنید: آدرسی که باید غیرقابل دسترس بماند، و سرویسی که سیاست باید مسدود کند. اگر هر دو هنوز موفق شوند، ترجمه از آنچه طراحی در نظر داشت گسترده‌تر است.
با حقایقی که بعداً این راه‌اندازی را توضیح می‌دهند ببندید: محدوده اصلی، محدوده ارائه‌شده، دستگاهی که ترجمه می‌کند، و جهتی که هر طرف می‌تواند در آن آغازگر باشد. اگر هر یک از این‌ها غایب باشد، مهندس بعدی شبکه‌ای را به ارث می‌برد که در آن دو میزبان یک نام را شریک‌اند و هیچ‌کس به یاد نمی‌آورد چرا یکی از آن‌ها پاسخ می‌دهد.