چرا BGP روی VPN مسیر لایه زیرین شما را کنترل نمی‌کند
BGP روی VPN دسترسی‌پذیری را مبادله می‌کند و سیاست مسیر را اعمال می‌کند، اما لایه زیرین هنوز مسیر بیرونی را انتخاب می‌کند. نشست واقعاً چه چیزی را کنترل می‌کند.
دو سایت BGP را از طریق یک تونل IPsec همتا می‌کنند، پیشوندهای یکدیگر را یاد می‌گیرند، و نمودار به کنترل مسیر تغییر برچسب می‌دهد. همین برچسب آغاز سردرگمی است. نشست واقعاً دسترسی‌پذیری را مبادله می‌کند و واقعاً سیاست را اعمال می‌کند، اما در این که کدام ارائه‌دهنده، کابل یا مسیریاب بسته‌های رمزنگاری‌شده را حمل می‌کند حرفی ندارد. دیده‌ام تیمی تونلی را که کار می‌کرد از نو ساخت، چون انتظار داشتند تغییر مسیر BGP ترافیک را به مسیر فیبر دیگری منتقل کند که نشست هرگز نمی‌توانست بر آن اثر بگذارد.
آنچه مردم فکر می‌کنند یک نشست می‌خرد
بیشتر انتظار از این می‌آید که تغییر مسیر در آزمایشگاه چگونه به نظر می‌رسد. یک پیشوند را از تونل اعلام می‌کنید، طرف دور آن را نصب می‌کند و ترافیک حرکت می‌کند. همین توالی روی مسیریابی رخ می‌دهد که واقعاً اهرم‌های مهندسی ترافیک دارد، بنابراین این دو با هم اشتباه گرفته می‌شوند. در آزمایشگاه هر دو سایت معمولاً یک لینک دسترسی را شریک می‌شوند، و دقیقاً به همین دلیل تفاوت هرگز آنجا ظاهر نمی‌شود.
BGP یک پروتکل دسترسی‌پذیری است. به یک همتا می‌گوید که می‌توانید بسته‌ها را برای یک پیشوند تحویل دهید و به هر طرف اجازه می‌دهد پیشنهادهای دریافتی را رتبه‌بندی کند. این از طریق تونل واقعاً مفید است: پیشوندها با آمدن و رفتن سایت‌ها ظاهر و ناپدید می‌شوند، و می‌توانید یک محدوده را رد کنید بدون نوشتن مسیر ایستا روی هر دستگاه لبه. کاری که نمی‌کند این است که مسیریاب‌های یک ارائه‌دهنده را تحت کنترل شما بگذارد.
لایه زیرین سرآیند بیرونی را حمل می‌کند. نقطه پایانی تونل شما بسته‌های رمزنگاری‌شده را به نشانی همتا می‌فرستد، و شبکه میان آن دو نشانی آن‌ها را با مسیرهایی که اپراتورهایش نصب کرده‌اند هدایت می‌کند. هیچ چیز در نشست BGP آن تصمیم را تغییر نمی‌دهد، مگر این که همان ارائه‌دهنده سرویس پشتیبانی‌شده‌ای ارائه دهد که این کار را بکند.
آنچه نشست واقعاً حمل می‌کند
گوینده BGP یک اتصال TCP به پورت 179 همتای خود باز می‌کند و از قالب‌های پیام و ویژگی‌های مسیر تعریف‌شده در RFC 4271 استفاده می‌کند. وقتی نشانی همتا درون تونل است، تونل باید بالا باشد و آن نشانی پیش از آغاز نشست قابل دسترسی باشد. تبادل IKE کامل‌شده همسایه BGP نیست. پیاده‌سازی‌های IPsec مبتنی بر مسیر تنها زمانی ترافیک را عبور می‌دهند که مسیر تونل منطبقی وجود داشته باشد، و نوع مبتنی بر سیاست به نشانی همتا درون انتخابگر محافظت‌شده نیاز دارد. برعکس انجام دادن این کار وضعیت کلاسیک را می‌سازد که تونل سبز است و نشست بیکار می‌ماند.
وقتی نشست بالا آمد، سیاست تعیین می‌کند چه چیزی از آن عبور کند. فهرست‌های پیشوند، فیلترهای مسیر AS، سقف حداکثر پیشوند و تصمیم صریح درباره مسیرهای پیش‌فرض حداقل لازم است و در هر دو جهت اعمال می‌شود. همتایی که هر چه دریافت می‌کند بپذیرد می‌تواند مسیر پیش‌فرضی به شما بدهد که بی‌صدا دسترسی اینترنت محلی را جایگزین می‌کند. دو جهت به فهرست‌های جداگانه نیاز دارند، چون آنچه از همتا می‌پذیرید و آنچه به او اعلام می‌کنید دو تصمیم متفاوت‌اند.
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
بعد نوبت MTU است. کپسوله‌سازی بار مفید را کوچک می‌کند، بنابراین یک به‌روزرسانی بزرگ می‌تواند نشستی را که کاملاً برقرار به نظر می‌رسد متوقف کند: همتا بالا می‌ماند، پیشوندها هرگز نمی‌رسند و چیز آشکاری در گزارش ثبت نمی‌شود. پیش از متهم کردن فیلترها، MSS مربوط به TCP را روی واسط تونل محدود کنید یا MTU تونل را با فضای کافی برای سربار تنظیم کنید.
بسته‌های بیرونی هنوز کجا می‌روند
بسته‌های رمزنگاری‌شده از یک سایت به سایت دیگر از مسیری خارج می‌شوند که مسیریاب محلی برای نشانی عمومی همتا انتخاب می‌کند. اگر هر دو سایت ترانزیت را از یک ارائه‌دهنده بخرند، از یک تأسیسات شهری بگذرند یا یک طرف پشت NAT سطح اپراتور باشد، تونل از خرابی ارائه‌دهنده فقط تصادفی جان سالم به در می‌برد. شمردن نمادهای تونل در ابزار پایش هیچ چیزی درباره این به شما نمی‌گوید.
انتخاب مسیر و نصب هدایت نیز رویدادهای جداگانه‌اند. یک پیشوند می‌تواند در جدول BGP به‌عنوان بهترین بنشیند و باز هم در جدول هدایت نباشد، چون گام بعدی قابل حل نیست یا مسیر مشخص‌تری برنده می‌شود. وقتی کسی گزارش می‌دهد که BGP پیشوند را یاد گرفته اما ترافیک جریان ندارد، پرسش مفید این است که آیا نصب شده و به کدام گام بعدی اشاره می‌کند.
پاسخ صادقانه برای بازبینی طراحی فهرستی از وابستگی‌های مشترک است: مدار دسترسی، ارائه‌دهنده بالادست، تأسیسات و هر دستگاه حالت‌دار در مسیر بازگشت. نشستی از طریق تونل نمی‌تواند وابستگی‌ای را که بر فرازش نیست حذف کند.
سه تصمیم که ارزش جدا کردن دارند
وقتی طراحی این‌ها را با هم قاطی می‌کند، هر گفت‌وگو درباره قطعی دور خودش می‌چرخد. ابتدا آن‌ها را روی کاغذ جدا کنید، سپس هر یک را به دستگاهی که واقعاً آن را اعمال می‌کند نسبت دهید.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
هر ردیف صاحب متفاوتی دارد. اولی مذاکره است، دومی پیکربندی روی دستگاه‌های شما، سومی بیشتر شبکه کس دیگری است. درخواست تغییری که ردیف مورد اشاره‌اش را نام می‌برد بسیار آسان‌تر از درخواستی تصویب می‌شود که می‌گوید مشکل BGP.
حالت‌های خرابی که ارزش برنامه‌ریزی دارند
پذیرفتن مسیر خلاصه یک همتا شایع‌ترین زخم خودساخته است. کسی یک تجمیع کوتاه اعلام می‌کند تا تبادل را ساده کند، طرف دور آن را می‌پذیرد و ترافیک محدوده‌هایی که پشت تونل نیستند از تونل پیروی می‌کند و می‌میرد. بر اساس پیشوندهای دقیقاً مورد انتظار فیلتر کنید یا از فهرست پیشوند با مرزهای درست استفاده کنید و هرگز تجمیع برهنه را نپذیرید چون نشست را مرتب نشان می‌دهد.
زمان‌بندی پس‌گیری دومی است. تشخیص به تایمرهای نگه‌داشت، BFD اگر فعال کرده باشید، تشخیص همتای مرده تونل و سرعت توقف اعلام طرف دور بستگی دارد. نشست‌های موجود مسئله‌ای جدا هستند: مسیر جدید ممکن است اتصال‌های تازه را بازگرداند در حالی که نشست‌های TCP برقرار همچنان از نشانی‌های کهنه استفاده می‌کنند، و دیوارهای آتش حالت‌دار یا NAT در مسیر ممکن است ورودی‌هایی نگه دارند که دیگر منطبق نیستند. بازیابی برنامه را در معیارهای پذیرش بگذارید به جای این که فرض کنید تغییر مسیر همه چیز را حل می‌کند.
سومی عدم تقارن مسیر بازگشت است. ترافیک می‌تواند از تونل برسد و از لینک ارائه‌دهنده‌ای بازگردد که هرگز برای حمل آن در نظر گرفته نشده بود، که به‌صورت صدای یک‌طرفه، دست‌دهی‌های ناموفق یا دیوار آتشی که پاسخ‌ها را دور می‌ریزد ظاهر می‌شود. هر دو جهت را جداگانه بررسی کنید.
چه چیزی در قرارداد بنویسیم و چگونه آن را تأیید کنیم
پیشوندهای مجاز را کتبی بخواهید: چه کسی مجاز است هر محدوده را ایجاد کند، آیا مسیر پیش‌فرض مجاز است و سرویس تونل از کدام خانواده‌های نشانی پشتیبانی می‌کند. RFC 8212 سیاست صریح واردات و صادرات را به انتظار برای eBGP در پیاده‌سازی‌هایی که از آن پیروی می‌کنند تبدیل کرد، بنابراین همتایی که هنوز به رفتار ضمنی پذیرش همه چیز تکیه می‌کند ارزش پرسیدن دارد.
سپس از دستگاه تأیید کنید نه از نمودار. فرمان‌های مفید روی مسیریاب‌های سبک FRR:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
دو مشاهده اضافه کنید که جدول مسیریابی نمی‌تواند به شما بدهد. روی واسط بیرونی ثبت کنید تا تأیید شود بسته‌های کپسوله واقعاً کدام نشانی را هدف می‌گیرند، مثلاً tcpdump -ni eth0 udp port 51820 برای تونل WireGuard، یا فیلتر ESP برای IPsec. سپس به سمت نشانی عمومی همتا ردیابی کنید و گام‌ها را با یک ردیابی درون تونل مقایسه کنید؛ اگر هر دو زنجیره ارائه‌دهنده یکسانی را دنبال کنند، افزونگی شما در سیاست مسیریابی زندگی می‌کند نه در شبکه.
در پایان، عمداً یک پس‌گیری را آزمایش کنید. تونل را در پنجره نگهداری پایین بیاورید، ثبت کنید پیشوند چه مدت نصب می‌ماند، بر نشست‌های موجود چه می‌آید و آیا طرف دور به مسیری برمی‌گردد که واقعاً می‌پذیرفتید. آن تمرین درباره طراحی بیشتر از هر نموداری می‌گوید.
مسیر مجوز نیست. پیشوندهایی که توافق می‌کنید مبادله شوند هیچ چیزی درباره این که کدام کاربران می‌توانند به کدام سرویس پشت تونل برسند نمی‌گویند، بنابراین احراز هویت، سرویس‌های مجاز و دیوارهای آتش میزبان را دقیقاً همان‌جا که بودند نگه دارید. همتای قابل دسترس هم مجوز ترانزیت نامحدود یا ایجاد نشانی‌های دلخواه نیست، و این نوع اختیار به‌عنوان یک پرسش تجاری به قرارداد تعلق دارد، نه به یک خط سیاست BGP.
- پیشوندهایی را که هر طرف می‌تواند ایجاد کند و آن‌هایی را که هرگز نباید بپذیرد نام ببرید.
- MSS را روی تونل محدود کنید و تأیید کنید به‌روزرسانی‌های بزرگ واقعاً می‌رسند.
- وابستگی‌های مشترک لایه زیرین را فهرست کنید، نه تعداد تونل‌ها را.
- یک پس‌گیری واقعی را زمان‌بندی کنید و یادداشت کنید برنامه چه می‌کند.