VPN کنکشن کا وقت ختم ہونا: DNS، نقل و حمل، مذاکرات یا لاگ ان
وقت ختم ہونے کا مطلب صرف یہ ہے کہ ایک آخری مدت گزر گئی۔ چار مراحل، نام کا حل، نقل و حمل، مذاکرات اور لاگ ان، کا موازنہ کریں کہ کون آخر میں مکمل ہوا۔
«کنکشن کا وقت ختم ہو گیا» وہ سب سے غیر واضح خرابی ہے جو VPN کلائنٹ چھاپ سکتا ہے۔ اس کا مطلب ہے کہ ایک عمل اپنی آخری مدت سے محروم ہو گیا، اور نام کے حل سے لاگ ان کے جواب تک ہر مرحلے کی ایک آخری مدت ہے۔ جو کلائنٹ صرف آخری پیغام دکھاتے ہیں وہ مراحل کو یکساں دکھاتے ہیں، اسی لیے لوگ وقت بڑھاتے ہیں، پورٹ بدلتے ہیں اور پروفائل دوبارہ نصب کرتے ہیں، اسی ترتیب سے، کچھ سیکھے بغیر۔ مراحل کا موازنہ کرنا تیز ہے: ہر ایک مختلف جگہ پر ناکام ہوتا ہے، اور ہر ناکامی مختلف قسم کا ثبوت چھوڑتی ہے۔
چار مراحل، چار مختلف ناکامیاں
ترتیب مقرر ہے چاہے کلائنٹ اسے چھپائے: نام حل ہونا چاہیے، حاصل شدہ پتے تک نقل و حمل قائم ہونا چاہیے، پروٹوکول کو اپنے پیرامیٹرز اور چابیاں طے کرنی چاہییں، اور اکاؤنٹ کی تصدیق ہونی چاہیے۔ OpenVPN کی کنیکٹیوٹی مسئلہ حل کرنے کی گائیڈ اپنے کلائنٹ کے لیے یہی ترتیب اپناتی ہے، اور باقی اس کی قریب سے پیروی کرتے ہیں۔ دوسرے مرحلے میں وقت ختم ہونا اور چوتھے مرحلے میں وقت ختم ہونا اسکرین پر لکھے لفظ کے سوا کچھ مشترک نہیں رکھتے۔
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
لاگ میں خرابی سے پہلے کی آخری سطر نہیں، بلکہ پیش رفت ظاہر کرنے والی آخری سطر پڑھیں۔ زیادہ تر کلائنٹ حل شدہ پتہ، قائم شدہ ساکٹ، شروع شدہ ہینڈ شیک یا تصدیق کی درخواست جیسی کوئی چیز چھاپتے ہیں، اور اس سطر کے بعد والا مرحلہ ہی وقت ختم ہونے والا مرحلہ ہے۔
کسی بھی رابطے سے پہلے نام کا حل ناکام ہوتا ہے
اگر اینڈ پوائنٹ کبھی حل نہ ہو، تو کلائنٹ کے پاس جڑنے کے لیے کچھ نہیں ہوتا اور کوئی نقل و حمل کا کام نہیں ہوا۔ یہ ناکامی عام طور پر پورے وقت ختم ہونے کی بجائے فوری ہوتی ہے، اور یہی اسے باقیوں سے الگ کرنے کا سستا ترین طریقہ ہے۔ نام کو سسٹم ریزولور اور دوسرے ریزولور سے جانچیں، اور سرور بند ہونے کا نتیجہ نکالنے سے پہلے دونوں جوابات کا موازنہ کریں۔
فورم پوسٹ سے کاپی کیا گیا پرانا پتہ سرور کے مسئلے جیسا لگنے والے وقت ختم ہونے کی عام وجہ ہے، کیونکہ پتہ اب کسی اور چیز کا ہے یا کسی کا نہیں۔ پہلے کام کرنے والے پتے کو بدلنے کی بجائے آپریٹر کا موجودہ پروفائل استعمال کریں۔ ping کا جواب نہ آنا کسی بھی طرف ثبوت نہیں ہے: بہت سے اینڈ پوائنٹ ICMP پھینک دیتے ہیں اور پھر بھی بہت اچھی خدمت دیتے ہیں۔
نقل و حمل کی ترتیب ایسے پیکٹ کا انتظار کرتی ہے جو نہیں آئے گا
جب DNS ٹھیک ہو اور کلائنٹ پھر بھی پوری مدت جلا دے، تو نقل و حمل کی تہہ مشکوک ہے۔ TCP پر آپ پورٹ کو براہ راست جانچ سکتے ہیں؛ Test-NetConnection Windows پر یا nc -vz Linux پر بتاتا ہے کہ کوئی چیز کنکشن قبول کرتی ہے یا نہیں، اور یہ ping سے زیادہ مفید ہے۔ UDP پر اسی طرح جانچ نہیں سکتے، کیونکہ اس تہہ میں مکمل کرنے کے لیے کوئی ہینڈ شیک نہیں، اور یہ عدم مساوات بہت سے غلط نتائج پیدا کرتی ہے۔
TCP جانچ جو ثابت کرتی ہے وہ محدود ہے: 443 پورٹ قبول کرنے والی خدمت ضروری نہیں کہ VPN سننے والا ہو، اور صرف-UDP اینڈ پوائنٹ کے پاس کچھ بھی قبول کرنے کے لیے TCP پورٹ نہیں۔ پروفائل کو UDP سے TCP میں دوبارہ لکھنا دوسری طرف سننے والا نہیں بناتا؛ یہ صرف بدلتا ہے کہ آپ کا کلائنٹ کس چیز کا انتظار کرتا ہے۔ اگر نیٹ ورک پروٹوکول فلٹر کرے، تو تبدیلی اسی مرحلے پر مختلف وقت ختم ہونا پیدا کرتی ہے۔
کیپٹیو پورٹل اس مرحلے پر اپنی الگ جانچ کے حقدار ہیں۔ جب تک پورٹل ڈیوائس کو اختیار نہ دے، باہر جانے والی ٹریفک پورٹل کی طرف جاتی ہے اور ٹنل کی کوشش بس لٹکی رہتی ہے۔ پہلے براؤزر میں پورٹل مکمل کریں، پھر دوبارہ کوشش کریں، اور جب تک پورٹل زیر التوا ہے پروفائل نہ بدلیں۔
مذاکرات اور لاگ ان کا مطلب ہے کہ سرور نے جواب دیا
جیسے ہی ٹنل سرور تک پہنچتی ہے، کلائنٹ ہینڈ شیک شروع کرتا ہے اور خرابی کی نوعیت بدل جاتی ہے۔ یہاں رکنا پہنچنے کے بارے میں نہیں، مطابقت کے بارے میں ہے: غیر مطابق پروٹوکول ورژن، دوسری طرف سے قبول نہ ہونے والی سائفر یا ڈیٹا چینل سیٹنگ، یا ایسا پروفائل جو سرور کی پیش نہ کردہ خصوصیت کی توقع کرے۔ OpenVPN نے اپنے مذاکراتی طے شدہ اقدار بڑے ورژنوں کے درمیان اتنی بار بدلے کہ ایک نسل کے لیے لکھا گیا پروفائل سرور تک پہنچ کر بھی اوپر نہ آ سکے۔
تصدیق آخری مرحلہ ہے اور غلط پڑھنا سب سے آسان۔ واضح انکار ایک جواب ہے، یعنی راستہ کام کرتا ہے اور مسئلہ شناخت، سرٹیفکیٹ یا اکاؤنٹ کی حالت میں ہے۔ براؤزر پر مبنی سنگل سائن آن بہاؤ تیسرا معاملہ ہے: کلائنٹ ایسی کارروائی کا انتظار کر رہا ہے جو آپ نے نہیں کی، یا ایسے براؤزر کا جو وہ شروع نہیں کر سکتا، اور جب تک آپ وہ مرحلہ مکمل نہ کریں کچھ نہیں آئے گا۔
دوبارہ کوشش بدلنے سے پہلے ثبوت کا موازنہ کریں
ڈیوائس اور پروفائل کو مستقل رکھیں اور ایک وقت میں ایک چیز بدلیں، نیٹ ورک سے شروع کرتے ہوئے۔ اگر وہی پروفائل فون ہاٹ اسپاٹ پر جڑتا ہے اور ہوٹل Wi-Fi پر وقت ختم ہوتا ہے، تو متغیر سرور نہیں، راستہ ہے۔ اگر یہ ہر جگہ ناکام ہو، تو متغیر پروفائل یا اینڈ پوائنٹ ہے۔ اگر یہ دن کے ایک مخصوص وقت پر ہی ناکام ہو، تو وقت کی مہر لگائیں اور بوجھ کے بارے میں کچھ فرض کرنے سے پہلے سرور کی طرف کے واقعات سے موازنہ کریں۔
آپ جو خدمت چلاتے ہیں اس کے لیے فیصلہ کن موازنہ یہ ہے کہ کوشش آیا پہنچتی ہے بھی یا نہیں۔ جو کنکشن سننے والے تک پہنچ کر پھر رک جائے وہ مذاکراتی مرحلے کا ہے؛ جو سننے والے کی نظر میں کبھی نہ آئے وہ نقل و حمل یا حل کا مسئلہ ہے، اور دوبارہ کوشش کی کوئی ترتیب اسے ہلا نہیں سکتی۔ سرور لاگ رد شدہ لاگ ان کو خاموش گرنے سے بھی الگ کرتے ہیں، جو شناخت کی درستی اور فائر وال کی درستی کے درمیان فرق ہے۔
کلائنٹ ورژن، پروفائل کا نام، وقت کے منطقے کے ساتھ کوشش کا وقت اور آخری منقطع سطر کی بجائے پہلی مفید خرابی درج کریں۔ اقتباس شیئر کرنے سے پہلے چابیاں اور اسناد لے جانے والا مواد ہٹا دیں۔ پھر ایک بامعنی اصلاح کریں اور دوبارہ کوشش کریں، کیونکہ لمبی مدت صرف دستاویزی سست کارروائی میں مدد کرتی ہے اور غلط پتے یا بلاک شدہ پورٹ کے لیے کچھ نہیں کرتی۔