Cloud VPN کی وہ حدیں جو آپ ٹیون نہیں کر سکتے: IKE عمر اور پیر NAT

ریموٹ ڈیوائس کو 24 گھنٹے کی فیز 1 عمر دیں اور Cloud VPN ٹنل نیچے ہی رہے گا، چاہے Google کی طرف سب کچھ درست طریقے سے کنفیگر ہو۔ پیر ایسی قدر تجویز کر رہا ہے جو جواب دہندہ قبول نہیں کرے گا، اس لیے مذاکرات یا مکمل ناکام ہوتے ہیں یا بے حد دوبارہ شروع ہوتے ہیں۔ Cloud VPN فیز 1 کو 36,000 سیکنڈ یعنی دس گھنٹے تک محدود کرتا ہے، اور یہ حد ایسی سیٹنگ نہیں جسے آپ بڑھا سکیں۔ تبدیلی ریموٹ ڈیوائس پر ہی ہونی چاہیے۔

پیر پوچھتا ہے، جواب دہندہ فیصلہ کرتا ہے

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

کیس کھولنے سے پہلے خود ٹنل کی حالت پڑھیں، کیونکہ تفصیلی حالت عام طور پر اُس مرحلے کا نام لیتی ہے جو ناکام ہوا:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

جو واپس آتا ہے اُس کا موازنہ اپنے گیٹ وے کی قسم اور IKE ورژن کے لیے معاون مجموعے سے کریں، اور وہاں رہتے ہوئے دونوں ٹریفک سلیکٹر درج کریں۔ سلیکٹر کا عدمِ مطابق وہی ٹنل نیچے ہونے کی علامت دیتا ہے جو الگورتھم کا عدمِ مطابق دیتا ہے، اور الگورتھم کے برعکس یہ آپ کو خود درست کرنا ہے۔

36,000 سیکنڈ ہی بالائی حد ہے

فیز 1 36,000 سیکنڈ پر رک جاتا ہے۔ 86,400 پر سیٹ ڈیوائس ایسی چیز مانگ رہی ہے جس پر جواب دہندہ کبھی راضی نہیں ہوگا، اور دوبارہ کوشش کرنے سے اُس کا خیال نہیں بدلتا۔ ریموٹ تجویز کو حد کے اندر واپس لائیں اور وہی ترتیب قائم ہو جائے گی؛ یہی عدمِ توازن پورا سبق ہے، کیونکہ آپ اپنی قدر گھٹا سکتے ہیں مگر Google کی قدر نہیں بڑھا سکتے۔

منتخب قدر ڈیزائن نوٹس میں لکھیں۔ ورنہ اگلا انجینئر 24 گھنٹے کا تجربہ دہرائے گا اور اُسی دیوار پر پہنچے گا۔

معاون مجموعہ ہر گیٹ وے قسم اور IKE ورژن کے لیے یہاں شائع ہوتا ہے: Cloud VPN کا جائزہمیں، اس لیے عمومی IKE گائیڈ کے بجائے اپنی ٹوپولوجی والا حصہ پڑھیں۔

وہ ٹنل جو شیڈول کے مطابق گرتا ہے

فیز 2 مختلف برتاؤ کرتا ہے: جب دونوں سرے متفق نہ ہوں تو کلید کی تجدید مختصر وقفے کی پیروی کرتی ہے۔ جو پیر عدمِ مطابق کو مہلک سمجھتا ہے وہ ٹنل گرا دیتا ہے، اس لیے ایک عدمِ مطابق دو غیر متعلق خرابیوں کی طرح دکھ سکتا ہے۔ صرف پہلا کنکشن نہیں، کلید کی تجدید کی تال بھی دیکھیں۔ جو ٹنل باقاعدہ تال میں اوپر آ کر گرتا ہے وہ روٹنگ نقص سے زیادہ عمر کے عدمِ مطابق کی صورت ہوتا ہے۔

کچھ بھی بدلنے سے پہلے اُن گرنے کے وقت کی مہروں کو پیر کے اپنے لاگز سے منسلک کریں، کیونکہ سلیکٹر یا راستے کی تبدیلی وہی تال نقل کر سکتی ہے۔ اگر تال فیز 2 کے ٹائمر سے میل کھائے تو کسی تجویز کو چھوئے بغیر وجہ مل گئی۔

مجموعے گیٹ وے کی قسم سے آتے ہیں

سائفر اور سالمیت کے مجموعے strongSwan کی طرح ترمیم کرنے والے فی ٹنل پروفائل نہیں ہیں۔ آپ اُنہیں گیٹ وے کی قسم اور IKE ورژن سے منتخب کرتے ہیں، اور نہ موجود پروفائل ڈھونڈنا ایک دوپہر ضائع کرتا ہے۔

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

فی ڈیوائس ایک بیرونی پتہ

پیر کا بیرونی پتہ اُس کے اندرونی پتے سے ایک-سے-ایک مماثل ہونا چاہیے۔ حد سے زیادہ بوجھ والا PAT پول کام نہیں کر سکتا، کیونکہ ایک ہی عوامی پتے کے پیچھے کئی میزبان جواب دہندہ کو اُنہیں الگ کرنے کا کوئی طریقہ نہیں دیتے۔ جہاں کئی میزبانوں کو پتہ بانٹنا پڑے، وہاں ٹنل کو ایسی جگہ ختم ہونا چاہیے جو اُنہیں پہچان سکے۔

اُس بیرونی پتے کو بھی مستحکم رکھیں۔ ڈیوائس کو کسی اور NAT کے پیچھے لے جائیں اور تعلق ٹوٹ جاتا ہے حالانکہ ہر تجویز اب بھی میل کھاتی ہے۔ یہ لکھنا مفید ہے کہ کون سی قدریں Google کی ہیں اور کون سی آپ کی: عمریں، مجموعے اور ایک-سے-ایک NAT اُن کی طرف مستحکم ہیں، جبکہ تجاویز، سلیکٹر، روٹنگ اور BGP ترجیحات آپ کی ہیں۔