لماذا لا يتحكم 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 على النفق وأكّد أن التحديثات الكبيرة تصل فعلاً.
- اسرد تبعيات الطبقة السفلية المشتركة، لا عدد الأنفاق.
- قِس سحباً حقيقياً ولاحظ ما يفعله التطبيق.