چرا یک مسیر زیرشبکه AWS VGW نمی‌تواند یک تونل VPN را انتخاب کند

دو اتصال Site-to-Site VPN روی یک دروازه خصوصی مجازی پایان می‌یابند و همان پیشوند شعبه را اعلام می‌کنند. جدول مسیرهای زیرشبکه یک ورودی برای آن پیشوند دارد که به دروازه اشاره می‌کند و هیچ فیلدی که تونل را نام ببرد ندارد. بنابراین ترجیح میان اتصال‌ها جایی رخ می‌دهد که کنسول آن را مسیریابی نمی‌نامد. دانستن اینکه کدام لایه صاحب تصمیم است، تفاوت میان یک آماده‌به‌کار درست و تغییری است که هیچ کاری نمی‌کند.

دو لایه در بازی است: مسیر VPC که می‌گوید کدام دروازه، و انتخاب خود دروازه برای تونل. اشتباه گرفتن این دو، تغییراتی می‌سازد که در جدول مسیرها درست به نظر می‌رسند و هرگز بسته‌ای را جابه‌جا نمی‌کنند.

دو لایه که مانند یکی به نظر می‌رسند

مسیر زیرشبکه به یک پرسش پاسخ می‌دهد: برای این مقصد، کدام اتصال؟ هدفش دروازه خصوصی مجازی است و معیارش فقط با سایر مسیرهای همان جدول رقابت می‌کند. هیچ چیز در آن ورودی تونل یک را از تونل دو یا اتصال A را از اتصال B جدا نمی‌کند. پیشوند مشخص‌تر یک تطابق مقصد دیگر است، نه انتخابی دقیق‌تر برای مسیر.

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

VGW در واقع چه چیزی را مقایسه می‌کند

سلامت اول می‌آید. تونلی که قطع است، یا نشست BGP که بالا نیامده، پیش از بررسی هر ویژگی شکست می‌خورد. به همین دلیل افزودن مسیر به ابتدا روی اتصالی که از پیش ناموفق است چیزی را تغییر نمی‌دهد.

میان مسیرهای واجد شرایط برای همان پیشوند، AWS مسیر AS_PATH کوتاه‌تر را ترجیح می‌دهد. وقتی دو مسیر هم‌طول باشند، MED را مقایسه می‌کند، مشروط به شرط مستند درباره نخستین AS در مسیر. ترتیب منتشرشده را بخوانید نه نسخه شفاهی را، چون روایت شفاهی معمولاً مرحله سلامت و استثنای مسیر ایستا را حذف می‌کند. یک پیامد: سه بار افزودن به ابتدا روی اتصال پشتیبان، اتصال اصلی را کاملاً کوتاه‌تر می‌کند و این روش معمول بیان ترجیح است.

افزودن به ابتدا، و زمانی که هیچ کاری نمی‌کند

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

پس از تغییر، مسیر دریافت‌شده را در سمت AWS بررسی کنید. افزودنی که هرگز دستگاه مشتری را ترک نکرده، درست مانند افزودنی است که AWS نادیده گرفته است.

مسیرهای ایستا کل استدلال را نادیده می‌گیرند

اگر اتصال از مسیریابی ایستا استفاده کند، هیچ AS_PATH برای بلند کردن وجود ندارد. AWS مسیرهای ایستای VPN را برای همان پیشوند بر مسیرهای آموخته‌شده از BGP مقدم می‌داند، پس یک طراحی مختلط مانند یک طراحی کاملاً پویا رفتار نمی‌کند. نخست نوع مسیریابی را تعیین کنید، سپس سازوکار ترجیحی را که برای آن وجود دارد انتخاب کنید.

با دو اتصال ایستا که همان پیشوند را اعلام می‌کنند، اهرم مفید خود پیشوند است: در اتصالی که می‌خواهید استفاده شود محدوده مشخص‌تری اعلام کنید و بپذیرید که این مقصد منطبق را تغییر داده‌اید نه مسیر برنده را.

چرا دروازه گذرگاه پاسخ دیگری است

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

مدل را پیش از سازوکار انتخاب کنید: فعال و آماده‌به‌کار با ترجیح ثابت، یا فعال و فعال با ECMP.

پس از تنظیم چه چیزی را بررسی کنید

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

سپس آزمون جابه‌جایی تأییدشده را اجرا کنید و ببینید مسیر باقی‌مانده سرویس را حمل می‌کند. ترجیحی که تنها در تفاوت پیکربندی وجود دارد هنوز ترجیح نیست.