VPN منتقل ہو گیا: آپ کا OpenVPN کلائنٹ اب بھی پرانے IP پر کیوں کال کرتا ہے

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

دیکھیں کہ پروفائل کس کو کال کرتا ہے، یہ نہیں کہ DNS کیا کہتا ہے

وہ کنکشن کھولیں جو آپ واقعی استعمال کرتے ہیں اور remote لائن پڑھیں۔ وہاں کا عددی پتہ کبھی hostname کی اپ ڈیٹ کی پیروی نہیں کرتا، ریکارڈ کتنا ہی درست ہو جائے۔

پھر جانچیں کہ آپ نے جو پروفائل ایڈٹ کی وہی ہے جو کلائنٹ نے لوڈ کی۔ درآمد شدہ پروفائل عام ہیں: منتظم نے مہینوں پہلے نقل لی اور اپنا ورژن رکھا ہو سکتا ہے، اس لیے آپ کے ڈاؤن لوڈ فولڈر کی فائل اور ایپ میں اندراج مختلف ہو سکتے ہیں۔ DNS کی جانچ شروع کرنے سے پہلے کلائنٹ کی اپنی کنکشن تفصیلات میں endpoint کا موازنہ کریں۔

دو فائلیں، ایک endpoint — یہاں عام طور پر یہی ملتا ہے۔

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

کلائنٹ کی اگلی کنکشن کوشش پڑھیں

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

resolver کا cache پچھلا جواب رکھ سکتا ہے، اور کچھ نیٹ ورک اسے ریکارڈ کے TTL کی طلب سے زیادہ عرصہ رکھتے ہیں۔ کسی اور جگہ آزمائے گئے عوامی resolver سے نہیں، اسی resolver سے پوچھیں جو کلائنٹ واقعی استعمال کرتا ہے۔

اگر لاگ نیا پتہ دکھاتا ہے اور کنکشن پھر بھی ناکام ہوتا ہے، تو مسئلہ آگے بڑھ گیا: پیکٹ کہیں جا رہا ہے اور کوئی جواب نہیں دے رہا۔ یہ listener، فائر وال یا پورٹ فارورڈنگ کا سوال ہے، اور یہ کلائنٹ کے حل کے راستے میں نہیں بلکہ سرور کی طرف ہے۔ ان دو ناکامیوں کو الگ رکھیں، کیونکہ ناقابل رسائی listener کو DNS مسئلہ سمجھنا آپ کو اسی لوپ میں دو بار گھماتا ہے۔

جانیں آپ کون سا ری اسٹارٹ کر رہے ہیں

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

استحکام کی ترتیبات بھی اہم ہیں، کیونکہ وہ نئے پتوں کے پیچھے بھاگنے کے لیے نہیں بلکہ جو مصدقہ ہوا اسے رکھنے کے لیے بنائی گئی ہیں۔

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

چار اختیارات اور ان کے الگ کام

hostname کے ساتھ remote وہ ترتیب ہے جو دوبارہ حل کرنا ممکن بناتی ہے؛ اس لائن پر لفظی پتہ اسے خارج کر دیتا ہے۔ resolv-retry کنٹرول کرتا ہے کہ تلاش ناکام ہونے پر کیا ہو، اور 2.6 اسے پہلے ہی بطور ڈیفالٹ لامحدود رکھتا ہے۔ اس لیے اسے شامل کرنا کچھ نہیں بدلتا، اور یہ کبھی مختلف جواب کے لیے وقفہ وقفہ سے جانچ کا وقت نہیں رکھتا۔ جو کہتا ہے کہ یہ نئے پتوں کی نگرانی کرتا ہے، اس نے بحالی اور تازگی کو ملا دیا ہے۔

persist-remote-ip تازگی نہیں بلکہ تسلسل کا معاملہ ہے: یہ آخری بار مصدقہ ہونے والے endpoint کو، اپنے معاون نرم ری اسٹارٹس کے دوران دوبارہ استعمال کرتا ہے۔ جب آپ منتقلی جانچ رہے ہوں تو یہ آپ کی خواہش کے خلاف ہے۔ اگر آپ کا بلڈ اسے فعال کرتا ہے تو آزمائش کے لیے بند کریں، اور نیا endpoint ثابت ہونے پر بحال کریں۔ فعال چھوڑنے پر، کامیاب دوبارہ کنکشن DNS کے بارے میں آپ کو کچھ نہیں بتا سکتا۔

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

کلائنٹ کو قصوروار ٹھہرانے سے پہلے نیا endpoint تصدیق کریں

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

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

اپنی انتظامی رسائی لے جانے والی ٹنل دوبارہ شروع کرنے سے پہلے سرور تک بینڈ سے باہر راستہ رکھیں۔ صرف وہی ایک احتیاط اس منظرنامے سے پیدا ہونے والے زیادہ تر واقعات روک دیتی ہے۔