VPN سایت به سایت Azure با همتا در پشت NAT: فهرست بررسی

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

گام 1: تأیید کنید که همتا اصلاً پشت NAT است

نشانی روی رابط WAN دستگاه را با نشانی‌ای که Azure برای آن می‌بیند مقایسه کنید. اگر متفاوت باشند، چیزی در حال ترجمه است و آن مترجم اکنون بخشی از طراحی VPN شماست. از ارائه‌دهنده بپرسید که نگاشت ثابت است یا مشترک، چون نگاشت مشترک تغییر می‌دهد که به چه چیزی می‌توانید تکیه کنید. دستگاهی با نشانی WAN خصوصی و بدون ارسال، موردی متفاوت از دستگاهی پشت NAT سطح اپراتور با نگاشت عمومی پایدار است.

اگر دو نشانی یکی باشند، اینجا بایستید: NAT مشکل شما نیست و بقیه این فهرست کمکی نمی‌کند.

هر دو نشانی و مدل مترجم را در تیکت ثبت کنید. همان یک خط از دور بعدی پرسش‌ها درباره اینکه چرا همتای پیکربندی‌شده پاسخ نمی‌دهد جلوگیری می‌کند.

گام 2: توافق کنید چه کسی آغاز می‌کند

پرسش‌های متداول دروازه VPN Azure پشتیبانی از NAT-T را ذکر می‌کند و می‌افزاید که دستگاه محلی باید تونل IPsec را هنگامی که پشت NAT است آغاز کند. این با نحوه کار ترجمه حالت‌دار می‌خواند، چون مترجم نگاشت را نگه می‌دارد زیرا دستگاه درونی نخستین بسته را فرستاده است. اگر انتظار می‌رود Azure آغاز کند و چیزی نمی‌رسد که آن نگاشت را بسازد، تونل هرگز آغاز نمی‌شود.

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

در طول آغاز دستی، تبادل IKE را روی دستگاه ببینید؛ سکوت در آنجا پاسخ مسیریابی یا دیوار آتش است، نه پاسخ Azure.

گام 3: نشانی همتا را درست کنید

Azure در شیء دروازه شبکه محلی خود به نشانی عمومی قابل‌دسترسی برای همتا نیاز دارد، معمولاً نشانی عمومی مترجم نه نشانی درونی دستگاه. هویتی که دستگاه با آن احراز هویت می‌کند فیلدی جداگانه است و می‌تواند به‌طور مشروع با نشانی‌ای که Azure به آن زنگ می‌زند متفاوت باشد. آن دو را از هم جدا نگه دارید، چون جابه‌جا کردنشان خطای احراز هویتی می‌سازد که دقیقاً شبیه مشکل NAT است.

اگر نشانی عمومی تغییر کند، آن شیء هم باید با آن تغییر کند. نامی که به نشانی کهنه تبدیل می‌شود از یک نشانی ثابت که باید دستی به‌روز کنید بدتر است.

هر سه مقدار را بنویسید: نشانی محلی دستگاه، نشانی عمومی ترجمه‌شده، هویت همتای پیکربندی‌شده.

گام 4: فقط درگاه‌هایی را باز کنید که NAT-T لازم دارد

NAT-T بسته‌های ESP را درون UDP حمل می‌کند و RFC 3948 آن کپسوله‌سازی را توصیف می‌کند با درگاه 4500 که پس از مذاکره اولیه روی درگاه 500 استفاده می‌شود. دیوار آتش و مترجم شما هر دو باید تبادل و ترافیک بازگشتی آن را مجاز کنند. مجاز کردن یک درگاه TCP بی‌ربط چیزی درباره این مسیر اثبات نمی‌کند، و قاعده‌ای که خروج را مجاز کند ولی پاسخ را نه، همچنان شکست می‌خورد.

ارسال درگاه ورودی ثابت به‌طور خودکار لازم نیست وقتی همتا آغاز می‌کند و مترجم حالت را نگه می‌دارد. زمانی ضروری می‌شود که نگاشت ناپایدار است یا چیزی در مسیر حالت را تهاجمی منقضی می‌کند.

یک بار در دو طرف مترجم ثبت کنید؛ تفاوت کپسوله‌سازی بی‌درنگ دیده می‌شود.

گام 5: انتقال بیرونی را از مسیریابی درونی جدا کنید

تونلی که برقرار می‌شود و چیزی حمل نمی‌کند مشکل مسیریابی است، نه مشکل NAT-T. سایت‌ها هنوز به انتخابگرهای ترافیک سازگار، فضاهای نشانی منطبق، قواعد دسترسی و مسیر بازگشت برای شبکه‌های برنامه نیاز دارند. هیچ‌کدام از این‌ها با تبادل IKE موفق فراهم نمی‌شود.

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

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