Cloud VPN اسٹیٹس: IKE لاگ سے پہلے وسیلے کی حالت پڑھیں

ایک Cloud VPN ٹنل بیک وقت دو زندگی کے چکر چلاتا ہے، اور وہ ایک ہی گھڑی پر نہیں ہیں۔ وسیلے کو پہلے مختص اور ترتیب دیا جانا ضروری ہے، تب ہی یہ گفت و شنید کر سکتا ہے، اور اس کے بعد پروٹوکول کا IKE پیغامات کی اپنی ترتیب ہوتی ہے۔ اسٹیٹس فیلڈ پہلے کے بارے میں بتا سکتا ہے جبکہ دوسرے کے بارے میں کچھ بھی مفید نہ کہے۔ دونوں کو ایک چیز کے طور پر پڑھنا ہی وہ طریقہ ہے جس میں کلید کی عدم مطابقت پر فراہمی کی تاخیر کا الزام لگتا ہے۔

ایک ٹنل آبجیکٹ اور ایک وقت کی ونڈو سے شروع کریں۔

دو زندگی کے چکر، ایک ٹنل آبجیکٹ

وسیلے کی زندگی کا چکر یعنی فراہم کنندہ ٹنل تیار کرتا ہے: پتے، ترتیب، گنجائش۔ پروٹوکول کی زندگی کا چکر اس وقت شروع ہوتا ہے جب دونوں فریقوں کے پاس IKE_SA_INIT، پھر IKE_AUTH، پھر چائلڈ سیکیورٹی ایسوسی ایشنز کے تبادلے کے لیے کافی ترتیب ہوتی ہے۔ پہلے مرحلے میں موجود ٹنل تصدیق میں ناکام نہیں ہوا، کیونکہ تصدیق ابھی آزمائی نہیں گئی۔

یہی فرق پورا مسئلہ ہے۔ باقی سب اس بارے میں ہے کہ غیر متعلقہ پیغامات کو ملائے بغیر اس کا مشاہدہ کیسے کیا جائے۔

آبجیکٹ پڑھیں، کنسول کا خلاصہ نہیں

API سے صرف وہ دو فیلڈز مانگیں جو اہم ہیں اور کچھ نہیں، تاکہ جواب رات تین بجے پڑھنے کے قابل حد تک چھوٹا رہے: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status فیلڈ زندگی کے چکر کا مرحلہ بتاتی ہے، اور detailedStatus اس سے منسلک پڑھنے کے قابل وجہ لے کر چلتی ہے۔ مکمل ترتیب کا ڈمپ دوسرے سوالات کا جواب دیتا ہے اور ٹکٹ میں چپکانا مشکل ہوتا ہے۔ ایسی صرف پڑھنے والی کالیں ٹنل کو تبدیل نہیں کر سکتیں، جو واقعے کے ابھی فعال رہنے کے دوران اہم ہے۔

کال کا ٹائم اسٹیمپ اقدار کے ساتھ لکھیں، کیونکہ دونوں فیلڈز حرکت کرتی ہیں۔

ALLOCATING_RESOURCES کلید کی عدم مطابقت نہیں ہے

جب ٹنل ALLOCATING_RESOURCES بتاتا ہے، فراہم کنندہ ابھی آبجیکٹ جوڑ رہا ہوتا ہے۔ اس مرحلے میں پہلے سے شیئر کی گئی کلید کی عدم مطابقت کا مشاہدہ نہیں کیا جا سکتا، اور بند پیر پورٹ بھی اتنا ہی غیر مصدقہ ہے۔ جو آپ جانچ سکتے ہیں وہ تفصیلی پیغام ہے، کیا منصوبہ اور سروس صحت مند دکھتے ہیں، اور کیا ٹنل کی ترتیب پیر سے رابطہ کرنے کے لیے کافی مکمل ہے۔ اب راز بدلنا ایسی قدر بدلتا ہے جو کبھی آزمائی نہیں گئی۔

ترتیب کے بارے میں نتیجہ اخذ کرنے سے پہلے حالت کے بدلنے کا انتظار کریں۔

ESTABLISHED رسائی کی جانچ کا آغاز ہے

قائم شدہ ٹنل کا مطلب ہے IKE مکمل ہوا، یہ نہیں کہ ٹریفک بہہ رہی ہے۔ ٹنل کے اٹھائے ہوئے راستوں کی تصدیق کریں اور جہاں Cloud Router شامل ہو، BGP سیشن اور اس کے سیکھے ہوئے سابقوں کی تصدیق کریں۔ پھر اجازت شدہ ایپلیکیشن کے تبادلے کی جانچ کریں، کیونکہ فائر وال کا قاعدہ یا غائب راستہ مکمل طور پر صحت مند ٹنل سے گزرنے والی ٹریفک کو روک سکتا ہے۔ ان میں سے ہر ایک الگ مشاہدہ اور الگ اصلاح ہے۔

اسٹیٹس آپ کو بتاتا ہے کہ اگلا کون سا سوال پوچھنا ہے۔ یہ کبھی آپ کی جگہ رسائی کے سوال کا جواب نہیں دیتا۔

ایک آبجیکٹ اور ایک وقت کی ونڈو کو باہم منسلک کریں

لاگ میں پرانی تصدیق کی ناکامی پچھلی کوشش کی ہے، جب تک کہ اس کا ٹائم اسٹیمپ اس ونڈو کے اندر نہ آئے جس کی آپ تحقیق کر رہے ہیں۔ اسی منٹوں کے لیے ٹنل وسیلے کے لاگز نکالیں جن میں آپ نے اسٹیٹس درج کیا تھا، اور شناخت کنندگان کو ساتھ رکھیں۔ بعد کا IKE واقعہ دکھا سکتا ہے کہ گفت و شنید شروع ہو گئی ہے، جبکہ آپ جو کنسول پیغام دیکھ رہے ہیں وہ پہلے ہی پرانا ہو چکا ہے۔

اگر کچھ جمع کرنے سے پہلے ٹنل بحال ہو جائے تو یہ بتا دیں۔ غیر متعین وجہ غیر متعلقہ سطروں سے بنی پراعتماد کہانی سے بہتر ریکارڈ ہے۔

اگلا قدم ہمیشہ ایک ہی شکل کا ہوتا ہے: ایک آبجیکٹ، ایک ونڈو، ایک مرحلہ۔ اس سے زیادہ وسیع کوئی چیز خلاصہ ہے، تشخیص نہیں۔