VPN سایت‌به‌سایت از AWS به Azure: اول مسیر بازگشت را بنویسید
یک تونل متصل میان دو ابر تا زمانی که هر زیرشبکه بار کاری به پیشوند دور مسیریابی نکند چیزی را اثبات نمی‌کند. طرح را به ترتیب اجرا کنید و سپس سرویس را بیازمایید.
تونل بالا می‌آید. معمولاً همین‌طور است، چون IKE فقط به پیشنهادهای همسان و نشانی همتایی که در دسترس باشد نیاز دارد. آنچه بعداً شکست می‌خورد مسیر بازگشت است: بار کاری در AWS بسته‌ها را به تونل می‌فرستد، اما هیچ‌چیز در سمت Azure نمی‌داند چگونه به 10.10.0.0/16 پاسخ دهد، یا مسیر Azure در جدولی است که زیرشبکه بار کاری از آن استفاده نمی‌کند. پیش از دست زدن به هر کنسولی طرح مسیرها را بنویسید تا تونل کم‌جالب‌ترین بخش کار شود.
گام 1: طرح نشانی‌ها را ثابت کنید
با مقادیر مشخص کار کنید. یک بار کاری در AWS روی 10.10.1.20 درون 10.10.0.0/16 قرار دارد و به TCP 443 به سرویس Azure روی 10.20.1.30 درون 10.20.0.0/16 نیاز دارد. دو بازه نباید همپوشانی داشته باشند، و آزمون پذیرش جفت سرویس است، نه تونل.
این چهار واقعیت را پیش از هر چیز دیگری بنویسید، چون هر گام بعدی در برابر آن‌ها بررسی می‌شود.
گام 2: دروازه‌ای را نام ببرید که مالک هر انتهاست
AWS Site-to-Site VPN می‌تواند روی یک دروازه خصوصی مجازی یا یک دروازه ترانزیت پایان یابد، و این‌ها مالکان مسیریابی متفاوتی هستند. Azure دروازه VPN مدیریت‌شده خود و به‌طور جداگانه تجهیزاتی مبتنی بر VM را که مشتریان خودشان اجرا می‌کنند عرضه می‌کند. ثبت کنید کدام جفت را دارید، چون گام بعدی در هر ترکیب متفاوت است.
برای دروازه مدیریت‌شده، مسیری را که به نشانی حدسی یک تجهیز خصوصی اشاره می‌کند کپی نکنید. برای یک تجهیز، فرض نکنید که انتشار مسیر در ابر سیستم‌عامل مهمان را پیکربندی می‌کند، چون این کار را نمی‌کند.
اشتباه در اینجا طرحی می‌سازد که کامل به نظر می‌رسد و بسته‌ها را به نشانی می‌فرستد که هرگز پاسخ نمی‌دهد.
گام 3: مسیری را بنویسید که هر بار کاری واقعاً استفاده می‌کند
هر مرز در پایین یک جستجوی جداست، و مسیر در یکی از آن‌ها مسیر بسته نیست. پیش از فعال شدن تونل جدول را با مقادیر خودتان پر کنید.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
در AWS، به‌روزرسانی جدول مسیرهای زیرشبکه بار کاری با شماست، حتی پس از آنکه BGP یا تونل سالم شد؛ نمای کلی مسیریابی آن را بخشی از اتصال می‌داند. در Azure، جدول مسیرهای تعریف‌شده توسط کاربر به یک زیرشبکه مرتبط می‌شود نه به شبکه مجازی، پس مسیر مؤثر را روی NIC بار کاری بررسی کنید نه در تیغه VNet.
دروازه مدیریت‌شده Azure می‌تواند پیشوند دور را از طریق انتشار دروازه بیاموزد، و یک UDR می‌تواند آن تصمیم را باطل کند. UDR را وقتی دلیل دارید اضافه کنید، نه از روی عادت. اگر اضافه کردید، آن را به گام بعدی که دروازه برای مسیر VPN منتشر می‌کند نشانه بگیرید، نه اینکه نشانی تجهیز بسازید. سپس مسیرهای مؤثر روی NIC را دوباره بخوانید، چون تصمیم واقعاً همان‌جا گرفته می‌شود.
گام 4: دامنه را هم‌تراز کنید
برای BGP، آنچه هر طرف اعلام می‌کند را با آنچه طرف دیگر واقعاً آموخته مقایسه کنید، پیشوند به پیشوند. برای مسیریابی ایستا، بازه‌های دور پیکربندی‌شده را با مسیرهای بار کاری که در گام 3 نوشتید مقایسه کنید.
رابطه IKE که بر رمزنگاری توافق دارد اثبات نمی‌کند که هیچ طرفی 10.10.0.0/16 یا 10.20.0.0/16 را آموخته است. دو تونل می‌توانند بالا باشند در حالی که یک طرف یک /24 تنها را به‌جای /16 که برنامه‌ریزی کرده بودید اعلام می‌کند. پیشوند را در جدول مسیریابی بررسی کنید، نه در وضعیت تونل. ناهمخوانی بعداً به‌صورت یک زیرشبکه کارکن و یکی که هرگز پاسخ نمی‌دهد ظاهر می‌شود.
گام 5: سرویس را از منبع واقعی بیازمایید
جریان موردنظر را در گروه‌های امنیتی و ACLهای شبکه AWS، در NSGهای Azure و در هر فیلتر تجهیز در مسیر مجاز کنید. سپس یک اتصال از 10.10.1.20 به نشانی و درگاه تأییدشده سرویس باز کنید و تأیید کنید که پاسخ به همان منبع برمی‌گردد.
هم گروه‌های امنیتی ابر و هم NSGها حالت‌دار هستند، پس بسته بازگشتی ردشده نشانه مسیریابی است، نه قاعده‌ای که نوشتن آن در جهت معکوس را فراموش کرده‌اید.
ping از هر دروازه‌ای چیزی را روشن نمی‌کند. ICMP به نشانی دروازه مسیر صفحه کنترل را تمرین می‌دهد، نه سرویس TCP ارسال‌شده‌ای را که بار کاری نیاز دارد.
بازگردانی و سوابق
مالکان مسیر را کنار شناسه‌های تونل ثبت کنید و جدول‌های مسیر پیش از تغییر را نگه دارید. اگر تغییر باید برداشته شود، پیش از برچیدن تونل مسیرهای بار کاری را حذف کنید تا هیچ زیرشبکه‌ای به گام بعدی که دیگر وجود ندارد اشاره نکند.
آن‌گاه جابه‌جایی بعدی زیرشبکه یا اتصال spoke یک جای مشخص برای به‌روزرسانی دارد، به‌جای تونلی کارکن که تقصیر مسیری را می‌کشد که هرگز مالک آن نبوده است.