VPN گھر میں جڑتا ہے مگر ہوٹل کے Wi-Fi پر وقت ختم ہو جاتا ہے

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

خرابی کے کوڈ کو فیصلہ نہیں، مرحلہ سمجھ کر پڑھیں

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

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

اگر کلائنٹ Windows نہیں ہے تو مناسب احتیاط کریں۔ تھرڈ پارٹی کلائنٹ اس کا زیادہ تر حصہ "کنکشن ناکام" میں سمیٹ دیتے ہیں، اسی لیے اگلے دو مراحل پیغام پر بالکل انحصار نہیں کرتے۔

سرنگ کو مورد الزام ٹھہرانے سے پہلے نام جانچیں

ہوٹل اور ہوائی اڈے کے نیٹ ورک مسلسل DNS کو روکتے ہیں، اور پورٹل پتے کے ساتھ جواب دینے والا حل کنندہ ایسی ناکامی پیدا کرتا ہے جو مردہ سرور جیسی بالکل لگتی ہے۔ مقامی حل کنندہ جو کہتا ہے اس کا موازنہ کسی عوامی حل کنندہ سے کریں:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

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

معلوم کریں کون سا بیرونی پیکٹ غائب ہوتا ہے

سرنگ میں ایک بیرونی بہاؤ ہے جو مکمل طور پر آپ اور سرور کے درمیان راستے کا ہے، اور اسی بہاؤ کو درمیانی بکس درجہ بند کر کے گرا دیتے ہیں۔ اسے کلائنٹ پر قید کریں، پھر کام کرنے والے نیٹ ورک کا موازنہ ناکام ہونے والے سے کریں۔ Windows پر پہلی نظر کے لیے اندرونی قید کافی ہے:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

ایک ٹرانسپورٹ بدلیں اور دوبارہ جانچیں

یہ جاننے کے بعد کہ بیرونی بہاؤ گرا دیا جاتا ہے، عملی سوال یہ ہے کہ نیٹ ورک کون سے بہاؤ کی اجازت دیتا ہے۔ بیشتر محدود نیٹ ورک باہر جانے والے TCP 443 کی اجازت دیتے ہیں کیونکہ ورنہ وہ کام نہیں کر سکتے، اس لیے سننے والے کو وہاں منتقل کرنا معمول کا جواب ہے۔ OpenVPN پر یہ سرور بدلنے تک کلائنٹ کی طرف کا سوئچ ہے:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec کلائنٹ کے اپنے ترتیبات پینل میں مساوی سوئچ ہوتا ہے، عام طور پر TCP پر IPsec یا NAT گزر کے طور پر بیان کیا جاتا ہے۔ اسے بدلنا بھی ایک تشخیص ہے: اگر سرنگ TCP پر اوپر آئے اور UDP پر مر جائے تو آپ نے ثابت کیا کہ نیٹ ورک UDP فلٹر کرتا ہے، اور وہ ترتیب بھی تلاش کر لی جو اس مقام کے ہر دورے میں درکار ہوگی۔

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

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

ٹکٹ بند کرنے سے پہلے ثابت کریں کہ تبدیلی عمارت چھوڑنے کے بعد بھی قائم رہی۔ اصل نیٹ ورک پر اصل ترتیبات کے ساتھ دوبارہ جڑیں، پہلے تیس سیکنڈ قید کریں، اور تصدیق کریں کہ کلائنٹ اسی حالت تک پہنچتا ہے جس تک ہاٹ اسپاٹ پر پہنچا تھا:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

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

پھر نتیجہ وہاں لکھیں جہاں اگلا شخص دیکھے گا۔ "اس مقام پر کارپوریٹ پروفائل کو TCP 443 درکار ہے؛ UDP 500 کو ہوٹل فلٹر کرتا ہے" ایسا جملہ ہے جس پر ساتھی عمل کر سکتا ہے۔ "ہوٹلوں میں VPN غیر مستحکم ہے" ایسا نہیں ہے، اور یہ یقینی بناتا ہے کہ اگلے مہینے وہی ایک گھنٹہ دوبارہ ضائع ہوگا۔