Cloud VPN سے Cisco ASA تک: تجویز میں عدم مطابقت کے بعد دوبارہ تعمیر

دوسرے سرے پر Cisco ASA والے Cloud VPN ٹنل پر NEGOTIATION_FAILURE تقریباً ہمیشہ تجویز یا سلیکٹرز کی عدم مطابقت ہوتا ہے، اور پہلی مفید بات یہ ہے کہ کوئی ترمیم اسے درست نہیں کرے گی۔ Cloud VPN ٹنل آبجیکٹ بننے کے وقت IKE تجویز مقرر کر دیتا ہے۔ الگورتھم کو وہیں بدلنے کے لیے کوئی فیلڈ نہیں، اس لیے مرمت کا مطلب ہے مٹانا اور ریکارڈ شدہ نقطہ آغاز کے ساتھ دوبارہ بنانا۔ اسے دوبارہ تعمیر سمجھیں، پھر کام اندازوں سے بھری دوپہر کے بجائے ایک چیک لسٹ بن جاتا ہے۔

کچھ مٹانے سے پہلے ناکامی پڑھیں

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

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

دونوں ترتیبیں ابھی موجود ہوں تو ریکارڈ کریں

ٹنل مٹانے میں آدھا منٹ لگتا ہے اور آپ کے پاس موجود واحد ثبوت ختم ہو جاتا ہے۔ اس سے پہلے مقامی اور دور کے سلیکٹرز، ساتھی کا پتہ، مشترکہ راز کس کے پاس ہے، اور ASA کا crypto map یا IKEv2 پروفائل لکھیں۔ ASA دو الگ سوالوں کا جواب دیتا ہے: کیا ترتیب دیا گیا ہے اور اس وقت کیا اوپر ہے:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

گوگل کی طرف کنسول خلاصے کے بجائے ٹنل آبجیکٹ پڑھیں، کیونکہ ساتھی کا پتہ اور سلیکٹر فیلڈز وہی اقدار ہیں جنہیں آپ کو بالکل دہرانا ہے:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

وہ اقدار پہلی بار مٹانے سے پہلے ٹکٹ میں لکھیں۔ نیچے کی دوبارہ تعمیر صرف اس لیے کام کرتی ہے کہ آپ وہی آبجیکٹ ایک دانستہ فرق کے ساتھ دوبارہ بنا سکتے ہیں۔

وہ الگورتھم جن پر ایک فریق بات چیت سے انکار کرتا ہے

Cloud VPN روایتی ساتھی کی طرح IKEv1 الگورتھم کی رینج سے انتخاب نہیں کرتا۔ جو ساتھی سیٹنگز وہ توقع کرتا ہے وہ مقرر ہیں: انکرپشن کے لیے aes-cbc-128، سالمیت اور PRF دونوں کے لیے sha1-96، Diffie-Hellman گروپ 2، مرحلہ 1 کے لیے 36,600 سیکنڈ اور مرحلہ 2 کے لیے 10,800 سیکنڈ۔ ASA پالیسی کو بالکل یہی مجموعہ پیش کرنا ہوگا۔ ASA پر دوسری تجویز نقصان دہ نہیں، جب تک ملتی جلتی تجویز بھی فہرست میں ہو۔

IKEv2 دونوں فریقوں کو زیادہ جگہ دیتا ہے، لیکن قواعد وہی شکل رکھتے ہیں: PFS فعال کریں، وہ DH گروپ منتخب کریں جس کی ٹنل حمایت کرتی ہے، اور تجاویز کی فہرست اتنی مختصر رکھیں کہ عدم مطابقت واضح ہو۔ Cloud VPN پر ASA ساتھی کا مطلب جامد روٹنگ بھی ہے، اس لیے محفوظ سابقے BGP کے حوالے کرنے کے بجائے منصوبہ بندی اور فہرست کے ساتھ لکھنے ہوں گے۔

کسی دوسرے بنانے والے کے ٹیمپلیٹ سے نقل کیا گیا دورانیہ یہاں عام غلط موڑ ہے۔ Google ان اقدار کو لازمی ساتھی سیٹنگز کے طور پر شائع کرتا ہے، اس لیے انہیں مقرر کریں؛ چھوٹی قدر ASA کی مطلوبہ حد تک اوپر بات چیت نہیں کرتی۔

مٹائیں، دوبارہ بنائیں اور پرانی حالت صاف کریں

گیٹ وے نہیں، ٹنل مٹائیں، اور وہ نام لکھیں جو Cloud VPN متبادل کو دیتا ہے، کیونکہ نام تفویض کیے جاتے ہیں، دوبارہ استعمال نہیں ہوتے۔ ریکارڈ شدہ اقدار اور اسی ساتھی پتے کے ساتھ اسے دوبارہ بنائیں، پھر ملتی جلتی تجویز ASA پالیسی فہرست میں شامل کریں۔

ASA تبدیلی کے بعد اور نتیجہ پڑھنے سے پہلے سکیورٹی ایسوسی ایشنز صاف کریں۔ ASA موجودہ SA ختم ہونے تک پرانی پالیسی پیش کرتا رہ سکتا ہے، اس لیے درست ترتیب پوری پرانی مدت میں ٹوٹی ہوئی دکھتی ہے اور ناظر یہ نتیجہ نکالتا ہے کہ دوبارہ تعمیر ناکام ہوئی جبکہ وہ شروع بھی نہیں ہوئی تھی:

clear crypto ikev2 sa
clear crypto ipsec sa

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

سلیکٹر آئینے کی طرح ملتے ہیں، پھر شمار کنندہ فیصلہ کرتے ہیں

مرحلہ 2 صرف اس وقت کام کرتا ہے جب دونوں سرے محفوظ پتوں پر متفق ہوں، اور یہ اتفاق مشترک نہیں بلکہ آئینے جیسا ہے۔ Google کا مقامی سلیکٹر اس سلیکٹر سے ملنا چاہیے جسے ASA دور کہتا ہے، اور Google کا دور کا سلیکٹر اس سے جسے ASA مقامی کہتا ہے۔ ایک طرف 0.0.0.0/0 اور دوسری طرف ایک ہی سب نیٹ والی ٹنل مرحلہ 1 پار کرتی ہے اور پھر اسی بنیادی خرابی کے ساتھ مرحلہ 2 میں ناکام ہوتی ہے۔ کوئی فریق دوسرے کی فہرست کو وسیع نہیں کر سکتا۔

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

ایک میزبان سے میزبان بہاؤ کے ساتھ ختم کریں اور دونوں طرف بائٹ شمار کنندہ پڑھیں۔ ASA پر بڑھنے اور Google پر یکساں رہنے والے شمار کنندہ عام طور پر بتاتے ہیں کہ جواب کسی دوسرے انٹرفیس سے نکلتا ہے، یا سلیکٹر واپسی کا سابقہ نہیں ڈھانپتا۔ الگورتھم، مدتیں، سلیکٹرز اور نئی ٹنل کا نام ریکارڈ کریں، کیونکہ اگلی تجویز کی تبدیلی یہی دوبارہ تعمیر دہراتی ہے اور وہ اقدار اسے مختصر کام بنا دیتی ہیں۔