GCP HA VPN: BGP سیشن Waiting for peer پر رک جاتا ہے، پتے کی جوڑی کی تبدیلی

Cloud VPN ٹنل پر کبھی Established تک نہ پہنچنے والا BGP سیشن عام طور پر روٹنگ کا مسئلہ نہیں ہوتا۔ یہ وائرنگ کا مسئلہ ہے: دو پتے جنہیں ایک دوسرے کا عکس ہونا چاہیے غلط ترتیب میں درج ہوئے، یا پہلی ٹنل کی جوڑی دوسری پر دوبارہ استعمال ہوئی۔ ٹنل خود بالکل صحت مند ہو سکتی ہے جبکہ سیشن Waiting for peer پر کھڑا ہو، کیونکہ IPsec اور BGP ایک ہی دو آخری نکات کے درمیان الگ الگ مذاکرات ہیں۔ کچھ بھی دوبارہ بنانے سے پہلے فیصلہ کریں کہ ان دونوں میں کون خراب ہے۔

ایک سوال بیشتر معاملات طے کر دیتا ہے: کیا پیر آلہ Cloud Router کا پتہ بالکل دیکھتا ہے؟

ٹنل کی حالت اور سیشن کی حالت الگ الگ جانچ ہیں

پہلے IKE اور ESP آتے ہیں۔ اگر ٹنل قائم نہ ہو تو اس کے اندر کچھ بھی اہم نہیں اور BGP پتے کی بحث وقت سے پہلے ہے۔ ٹنل کی حالت اور تفصیلی حالت پڑھیں، پھر اسی ٹنل کے لیے روٹر کی BGP پیر حالت پڑھیں۔

ٹنل چل رہی ہو جبکہ اس کا BGP پیر بند ہو تو یہ خرابی کو سیشن تک محدود کرتا ہے: پیر کا پتہ، ASN یا اندرونی پتے پر آنے والا TCP 179۔ ٹنل چل رہی ہے، سیشن چل رہا ہے اور ابھی بھی VPC میں کوئی روٹ نہیں یہ تیسرا معاملہ ہے۔ پتے بدلنے سے وہاں فائدہ نہیں ہوگا، کیونکہ سیشن پہلے ہی کام کر رہا ہے اور سابقہ صرف اعلان نہیں ہو رہا یا ترجیح نہیں پا رہا۔ ان تینوں معاملات کو الگ رکھنا ہی کام کا بڑا حصہ ہے۔

ہر ٹنل کو اپنا /30 چاہیے، دونوں سرے بھرے ہوئے

ہر HA VPN ٹنل کو 169.254.0.0/16 میں سے link-local /30 ملتا ہے، ایک پتہ Cloud Router انٹرفیس پر اور دوسرا آپ کے پیر پر۔ پیر فیلڈ کو دور کا سرا بتانا چاہیے، کبھی خود روٹر کا پتہ نہیں۔

دو ٹنلیں یعنی Cloud Router پر دو انٹرفیس، ہر ایک مختلف /30 کے ساتھ۔ ٹنل 0 کی جوڑی ٹنل 1 پر دوبارہ استعمال کرنا وہ غلطی ہے جو خلاصہ جدول میں ستھری لگتی ہے اور OPEN پیکٹ میں مر جاتی ہے۔

جوڑی کنسول خلاصے سے نہیں، روٹر وسیلے سے پڑھیں۔ خلاصہ پیر کا پتہ ایسے کالم میں دکھاتا ہے جسے غلط پڑھنا آسان ہے، اور انٹرفیس کا 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 روٹ جدول میں نظر آتا ہے اور دونوں طرف ایک ایک ہوسٹ جواب دیتا ہے۔ پھر حتمی جوڑیاں ٹنل ناموں کے ساتھ درج کریں، تاکہ اگلی دوبارہ تعمیر کنسول خلاصے کی بجائے جانچے گئے جدول سے شروع ہو۔