WAN کا IP بدل گیا اور ٹنل گر گئی: جانچ ترتیب سے

ٹنل گر جاتی ہے، راؤٹر دوبارہ کنکشن درج کرتا ہے، اور LAN پر کچھ نہیں ہلا۔ نیا WAN پتہ اندر کچھ بدلے بغیر بیرونی کنکشن کو باطل کر دیتا ہے: کلائنٹ کا ماخذ پتہ بدل گیا، پرانی NAT حالت ایسے ماخذ کی طرف اشارہ کرتی ہے جو اب نہیں ہے، اور دور کا ساتھی شاید اب بھی پچھلے پتے پر بھیج رہا ہے۔ بحالی عام رویہ ہے، اور مفید سوال یہ ہے کہ کون سی حالت اپ ڈیٹ نہیں ہوئی۔

لاگ پڑھنے سے پہلے واقعہ کا نام رکھیں

دیکھیں کہ رسائی پرت پر واقعی کیا ہوا۔ ISP لیز کی تجدید ایک واقعہ ہے۔ دوبارہ جڑا PPPoE سیشن دوسرا ہے۔ ری بوٹ ہوا فائبر موڈیم، یا ایک اپ لنک سے دوسرے پر WAN فیل اوور، بیرونی پتہ یا اس کا راستہ تیسرے طریقے سے بدلتا ہے۔ یہ ایک ہی واقعہ نہیں ہیں اور ایک جیسا باقی نہیں چھوڑتے۔

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

رومنگ اور دوبارہ کنکشن الگ پروٹوکول ہیں

WireGuard میں تصدیق شدہ رومنگ پروٹوکول میں ہی شامل ہے: جب ساتھی کو نئے ماخذ پتے سے درست طریقے سے تصدیق شدہ پیکٹ ملتا ہے، تو وہ اس ساتھی کے اختتامی نقطے کو اپ ڈیٹ کرتا ہے۔ WireGuard کی فوری شروعات وہ ساتھی ترتیب بیان کرتی ہے جو یہ ممکن بناتی ہے، اسی لیے بدلتے پتے والا کلائنٹ اکثر دکھائی دینے والے ری اسٹارٹ کے بغیر بحال ہو جاتا ہے۔

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

دونوں برتاؤ اندر کی ایپلیکیشنوں کے بارے میں کچھ نہیں کہتے۔ بحال شدہ ٹنل اس TCP سیشن کو بحال نہیں کرتی جسے ساتھی پہلے ہی مردہ سمجھ چکا تھا۔

وہ حالت جس کا ٹنل مالک نہیں

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

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

جانچ کو باہر سے اندر کے ترتیب میں رکھیں

نیچے کا ترتیب بیرونی کنکشن سے اندر کی طرف جاتا ہے، اور پہلے ناکام مرحلے پر رکنا ہی اسے مفید بناتا ہے: ہر جانچ اوپر کی پرت کو خارج کرتی ہے۔ خرابی واضح دکھنے پر بھی یہی ترتیب رکھیں۔

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

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

پھر راؤٹر سے نہیں، LAN کلائنٹ سے جانچیں۔ جو خود راؤٹر نے بھیجا پنگ آگے بھیجے گئے ٹریفک سے الگ راستہ استعمال کرتا ہے، اس لیے کامیاب راؤٹر پنگ ثابت کرتا ہے کہ ٹنل موجود ہے، اور کلائنٹ کی رسائی کے بارے میں کچھ نہیں۔

متوقع رویہ طے کریں اور لکھیں

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

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