GCP HA VPN: جلسة BGP عالقة عند Waiting for peer وتبديل زوج العناوين
جلسة BGP في Cloud VPN عالقة عند Waiting for peer تكون عادة قد بدلت عنوان النفق وعنوان النظير. تحقق من الزوج قبل أن تعيد بناء أي شيء.
جلسة BGP لا تصل أبدا إلى Established على نفق Cloud VPN ليست عادة مشكلة توجيه. إنها مشكلة توصيل: عنوانان يجب أن يتقابلا تم إدخالهما بترتيب معكوس، أو أعيد استخدام زوج النفق الأول على النفق الثاني. قد يكون النفق نفسه سليما تماما بينما تبقى الجلسة عند Waiting for peer، لأن IPsec وBGP تفاوضان منفصلان بين الطرفين نفسيهما. حدد أي الاثنين معطوب قبل أن تعيد بناء أي شيء.
سؤال واحد يحسم معظم الحالات: هل يرى جهاز النظير عنوان Cloud Router أصلا؟
حالة النفق وحالة الجلسة فحصان مختلفان
يأتي IKE وESP أولا. إذا لم يكن النفق قائما فليس لما داخله أهمية، والحديث عن عنوان BGP سابق لأوانه. اقرأ حالة النفق وحالته المفصلة، ثم اقرأ حالة نظير BGP في الموجه للنفق نفسه.
نفق قائم بينما نظير BGP الخاص به متوقف يضيق الخلل إلى الجلسة: عنوان النظير، أو ASN، أو TCP 179 الواصل إلى العنوان الداخلي. نفق قائم وجلسة قائمة ولا مسارات بعد في VPC حالة ثالثة. تغيير العناوين لن يفيد هنا، لأن الجلسة تعمل بالفعل والبادئة ببساطة لا يعلن عنها أو لا تفضل. إبقاء هذه الحالات الثلاث منفصلة هو معظم العمل.
كل نفق يحتاج /30 خاصا به مع ملء الطرفين
كل نفق HA VPN يحصل على /30 link-local من 169.254.0.0/16، بعنوان على واجهة Cloud Router والآخر على النظير الخاص بك. يجب أن يسمي حقل النظير الطرف البعيد، ولا يسمي أبدا عنوان الموجه نفسه.
نفقان يعنيان واجهتين على Cloud Router، لكل منهما /30 مختلف. إعادة استخدام زوج النفق 0 على النفق 1 هي الخطأ الذي يبدو مرتبا في جدول موجز ويموت في حزمة OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
اقرأ الزوج من مورد الموجه لا من موجز وحدة التحكم. يعرض الموجز عنوان النظير في عمود يسهل قراءته خطأ، ويجب أن يصف ipRange للواجهة مع peerIpAddress للنظير طرفين متقابلين من /30 واحد.
التبديل يحدث عادة أثناء إعادة البناء
عند إعادة بناء النفق تتقاطع الأزواج. ينسخ عنوان نظير النفق القديم إلى حقل الواجهة في النفق الجديد، أو توجه الجلسة الجديدة إلى نظير الجلسة السابقة. في الحالتين يرسل Cloud Router حزم OPEN إلى عنوان صار هو نفسه أو إلى عنوان لا نفق خلفه.
اكتب الأزواج قبل فتح وحدة التحكم: اسم النفق، الواجهة، عنوان الموجه، عنوان النظير، ASN النظير. ثم أنشئ النفقين في تمريرة واحدة، حتى لا يملأ الثاني من بقايا الأول.
ثلاثة أسباب أخرى لانتظار الجلسة
ASN النظير هو الأول: يجب تهيئة كل طرف بـ ASN الطرف الآخر، وعدم التطابق يصل إلى النظير لكنه لا يؤسس أبدا. الثاني هو جدار الحماية الخاص بالنظير، الذي يجب أن يسمح بـ TCP 179 على واجهة النفق؛ وقاعدة IKE أو ESP لا تغطي ذلك. الثالث هو نظير يرد من عنوان مصدر مختلف عن العنوان المهيأ كجار له.
سجل النظير نفسه هو الفيصل. إذا لم يسرد موجز BGP لديه أي جار لذلك العنوان، فالحزم لا تصل والزوج أو المسار خطأ. وإذا كان الجار في Active أو Connect، فالحزم تصل ومعايير الجلسة غير متوافقة.
تحقق بالترتيب الذي تسلكه الحزم
اعمل من الداخل إلى الخارج: حالة النفق، ثم حالة نظير BGP في الموجه، ثم موجز BGP للنظير، ثم المسارات. إذا كان الأولان سليمين، فتوقف عن تعديل جانب Cloud VPN واعمل على جهاز النظير. وإذا أبلغ الموجه أن النظير متوقف ولم يكن لجهازك أي جار، فالزوج خطأ أو أن منفذ BGP مفلتر. التقاط الحزم على واجهة نفق النظير يحسم الأمر بنظرة واحدة، لأن حزم OPEN إما تصل إلى هناك أو لا تصل أبدا.
يعرض الأمر gcloud compute routers get-status ROUTER --region=REGION حالة النظير بجانب العنوان الذي يستخدمه، وهو بالضبط الزوج الذي تحتاج إلى مقارنته.
بعد أن تؤسس الجلسة، تأكد من ظهور البادئة المكتسبة في جدول مسارات VPC ومن استجابة مضيف واحد على كل جانب. ثم سجل الأزواج النهائية بجانب أسماء الأنفاق، كي تبدأ إعادة البناء التالية من جدول معروف السلامة لا من موجز وحدة التحكم.