ایک ہی روٹر کے پیچھے صرف ایک VPN کلائنٹ کیوں جڑتا ہے

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

کلائنٹ کو چھونے سے پہلے گیٹ وے کا لاگ پڑھیں

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

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

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

روٹر GRE اور NAT-T کے ساتھ کیا کرتا ہے

PPTP روایتی مجرم ہے: کنٹرول چینل TCP 1723 ہے جبکہ ڈیٹا کا راستہ GRE، یعنی IP پروٹوکول 47 ہے۔ بہت سے صارف روٹر PPTP مددگار کے ساتھ آتے ہیں جو صرف ایک کنٹرول کنکشن پر نظر رکھتا ہے، اس لیے اسی NAT کے پیچھے دوسرا کلائنٹ اپنا کنٹرول چینل کھولتا ہے اور پھر اسے کوئی ڈیٹا راستہ ہی نہیں ملتا۔ 47 نمبر کا TCP پورٹ فارورڈ کرنے سے GRE کے لیے کچھ نہیں ہوتا، کیونکہ GRE پورٹ نہیں، پروٹوکول نمبر ہے۔

L2TP IPsec کے اوپر ڈیزائن کے مطابق مختلف رویہ رکھتا ہے: IKE UDP 500 استعمال کرتا ہے، NAT ٹریورسل محفوظ پے لوڈ کو UDP 4500 پر منتقل کرتا ہے، اور انکیپسولیشن بالکل اسی لیے ہے کہ ایک پتے کے پیچھے کئی کلائنٹ ایک ہی گیٹ وے تک پہنچ سکیں۔ یہ ڈیزائن کسی گیٹ وے یا درمیانی ڈبے کو ہر پتے کے لیے سیشن کی حد لگانے سے نہیں روکتا، اور صوفے سے دونوں ناکامیاں یکساں دکھائی دیتی ہیں۔ SoftEther کے اپنے پروٹوکول میں بھی اسی قسم کا مسئلہ ہے: کام کرنے والے گزر کے بغیر روٹر LAN سے پہلے کلائنٹ کو اندر لیتا ہے اور دوسرے کو گرا دیتا ہے۔ روٹر کا ALG یا گزر سوئچ دونوں حالتوں میں جانچیں، کیونکہ پرانے کلائنٹ کے لیے لکھا گیا مددگار موجودہ کلائنٹ کے بھیجے پیکٹ خراب کر سکتا ہے۔

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

شناخت کی وہ حدیں جو نقل و حمل کی حدوں جیسی دکھتی ہیں

روٹر واحد مشتبہ نہیں، اور لاگ اسے متبادل سے الگ کرتا ہے۔ جب OpenVPN سرور کوئی مشترک نام ایک سرنگ کے پتے سے باندھتا ہے، تو دونوں آلات کو وہ پتہ مل جاتا ہے، اور duplicate-cn کے بغیر نیا سیشن پرانے کو باہر دھکیل دیتا ہے۔ اس آپشن کو فعال کرنے سے دونوں جڑے رہتے ہیں مگر ان کے پاس ایک شناخت، ایک سرٹیفکیٹ اور منسوخی کا ایک فیصلہ ہی رہ جاتا ہے، جو دکھنے سے بدتر ہے۔ پھر دوسرے آلے کو کبھی تنہا منسوخ نہیں کیا جا سکتا، اس لیے سہولت کا سوئچ خاموشی سے وہ کنٹرول ہٹا دیتا ہے جس کی آپ کو بعد میں ضرورت پڑ سکتی ہے۔

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

مرمت کو لاگ کے اندراج سے ملا دیں

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

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

دو زندہ سیشنوں کی تصدیق

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

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