نشستی BGP که هرگز در یک تونل Cloud VPN به وضعیت Established نمی‌رسد معمولاً مشکل مسیریابی نیست. مشکل سیم‌کشی است: دو نشانی که باید آینه یکدیگر باشند با ترتیب اشتباه وارد شده‌اند، یا جفت تونل اول برای دومی دوباره استفاده شده است. خود تونل می‌تواند کاملاً سالم باشد در حالی که نشست در 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 می‌میرد.

TunnelRouter interfacePeer addressWhat a swap produces
tunnel 0169.254.1.1/30169.254.1.2OPEN sent to itself or to nothing; session waits
tunnel 1169.254.1.5/30169.254.1.6same failure on the second session
bothone pair reusedone address reusedone 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 ظاهر می‌شود و از هر طرف یک میزبان پاسخ می‌دهد. سپس جفت‌های نهایی را کنار نام تونل‌ها ثبت کنید تا بازسازی بعدی از یک جدول آزموده آغاز شود نه از خلاصه کنسول.

مقالات مرتبط