چرا نشست BGP شما در جدول مسیر VPC ظاهر نمی‌شود

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

دو چیز متفاوت اینجا قاطی می‌شود: همتا شدن با یک سرور مسیر، و نصب مسیرها در یک جدول.

افسانه: BGP را بالا بیاور و VPC پیشوندها را یاد می‌گیرد

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

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

Route Server یک صفحه کنترل است، نه یک تونل

Route Server حتی یک بسته را رمزنگاری، ارسال یا بازرسی نمی‌کند. وجودش برای تبادل BGP با دستگاه و سپردن پیشوندهای حاصل به جدول‌های مسیری است که برای دریافت آن‌ها پیکربندی شده‌اند. صفحه داده تغییری نکرده: بسته‌ها همچنان از رابط شبکه دستگاه خارج می‌شوند، از VPN آن عبور می‌کنند و از همان راه برمی‌گردند.

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

گروه‌های امنیتی و کنترل‌های زیرشبکه هم روی جریان ارسال‌شده اعمال می‌شوند. Route Server دستگاهی را که ترافیک را دور می‌ریزد مجبور به ارسال آن نمی‌کند، و مسیر بازگشت گمشده در سمت دور را هم تعمیر نمی‌کند.

انتشار برای هر جدول مسیر است، نه برای کل VPC

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

جدول مؤثر همان زیرشبکه مشخص را بررسی کنید، نه فهرست پیشوندهایی که دستگاه اعلام می‌کند. API مستقیماً به این پرسش پاسخ می‌دهد: aws ec2 associate-route-server و aws ec2 enable-route-server-propagation --route-table-id <id> همان دو مرحله‌ای هستند که مردم فراموش می‌کنند، و aws ec2 describe-route-tables --route-table-ids <id> نشان می‌دهد که آیا پیشوند اصلاً به‌عنوان یک ورودی route server رسیده است یا نه.

دستگاه هنوز هر بسته را حمل می‌کند

اعلام دسترس‌پذیری با داشتن آن یکی نیست. یک نشست BGP می‌تواند برقرار بماند در حالی که VPN دستگاه پایین است، و یک اعلام ایستا که هرگز تغییر نمی‌کند ترافیک را به سمت مسیری مرده می‌کشد. Route Server از تشخیص خرابی مانند BFD پشتیبانی می‌کند، اما آن زنده بودن همتا را می‌آزماید، نه سلامت همه‌چیز پشت همتا را.

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

یک پیشوند را پس بگیرید و ببینید چه می‌شود

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

جابه‌جا کردن یک مسیر به دستگاه دوم، نشست‌هایی را که حمل می‌کرد جابه‌جا نمی‌کند، چون وضعیت NAT و دیوار آتش روی دستگاه اول می‌ماند.

برای مجموعه‌ای ثابت از حدود دوازده پیشوند، مسیرهای ایستا در جدول‌های VPC همچنان پاسخ ارزان‌تر هستند. Route Server جای خود را وقتی به دست می‌آورد که فهرست پیشوندها واقعاً تغییر می‌کند و سیاست پس‌گیری چیزی است که می‌توانید برای فرد کشیک توضیح دهید.