VPN کا کون سا مرحلہ ناکام ہوا: IPsec، L2TP کنٹرول یا PPP توثیق
آخری کامیاب مرحلہ تلاش کریں اور صرف وہی تہہ درست کریں: IPsec، L2TP کنٹرول چینل، PPP توثیق یا پتہ تفویض۔
آپ نے پاس ورڈ بدلا اور کچھ نہیں ہلا، کیونکہ خرابی کبھی PPP میں نہیں تھی۔ L2TP/IPsec پانچ بالکل مختلف حوالگیوں کے لیے ایک ہی کنکشن خرابی بتاتا ہے، اور ہر حوالگی کی اپنی مرمت ہے۔ الٹی سمت میں کام کریں: آخری کامیاب مرحلہ تلاش کریں اور صرف وہی بدلیں جو اس کے بعد آتا ہے۔ نیچے ترتیب یہ بھی طے کرتی ہے کہ کون سے ثبوت پہلے جمع کریں۔
چار سوالوں کا جواب ترتیب سے دیں
نئی کوشش پر مجبور کریں، کیونکہ کچھ کلائنٹ پروفائل منقطع اور دوبارہ منسلک ہونے تک پچھلی خرابی دکھاتے رہتے ہیں۔ پھر اس کا جواب دیں: کیا IPsec سکیورٹی ایسوسی ایشن تھی، کیا L2TP کنٹرول کنکشن اور کال نمودار ہوئے، PPP توثیق کے فیصلے تک پہنچا، اور کیا IPCP نے کلائنٹ کو پتہ دیا؟ پہلا نہیں ہی وہ مرحلہ ہے جو آپ درست کرتے ہیں۔ اس کے بعد سب کچھ غیر جانچا ہے، اس لیے جب ایسوسی ایشن کبھی نہیں تھی تو مسترد صارف نام کچھ ثابت نہیں کرتا۔
موازنے سے پہلے دونوں سروں کے گھڑیال ہم آہنگ کریں۔ وہ دوبارہ کوشش جس نے IPsec صاف کیا اور PPP پر ناکام ہوئی، ایک ہی خرابی لگتی ہے جب کلائنٹ صرف آخری پیغام دکھاتا ہے اور سرور لاگ اب بھی پچھلی کوشش رکھتا ہے۔ سب سے بلند آواز والی سطر سے نہیں، وقت کے نشان سے پڑھیں۔
جب صرف صارف کا اسکرین شاٹ ہو، سب سے سستی تقسیم پر بھروسا کریں: غلط پیشگی مشترکہ کلید اور وہ xl2tpd جو کبھی جواب نہیں دیتا Windows ڈائیلاگ میں ایک ہی متن پیدا کرتے ہیں، مگر ایک کو دونوں سروں پر بدلا ہوا راز درکار ہے اور دوسرے کو خود سرور پر شروع شدہ ڈیمن یا فائر وال قاعدہ۔ درمیان کا آلہ اندرونی 1701 کو نہیں گرا سکتا جب ٹرانسپورٹ موڈ IPsec اسے لپیٹ چکا ہو، اس لیے ایسا راستہ فلٹر نہ ڈھونڈیں جو موجود نہ ہو۔
ہر تہہ اصل میں کیا رکھتی ہے
IPsec دو ساتھیوں کے درمیان پیکٹ محفوظ کرتا ہے؛ L2TP اسی محفوظ راستے کے اندر PPP سیشن لے کر چلتا ہے، اسی لیے RFC 3193 اپنی الگ سرنگ کے بجائے ٹرانسپورٹ موڈ مقرر کرتا ہے۔ کلائنٹ کا لیبل L2TP کہتا ہے، اس لیے سرنگ اور لاگ ان ایک ہی طریقہ کار لگتے ہیں۔ ایسا نہیں: L2TP کنٹرول کنکشن وہاں سرنگ کے سروں کی توثیق کرتا ہے جہاں تعیناتی اسے فعال کرتی ہے، اور PPP سرور کی پالیسی کے مطابق صارف کی علیحدہ توثیق CHAP، PAP یا MS-CHAPv2 سے کرتا ہے۔
یہ تقسیم وہ دو راز واضح کرتی ہے جنہیں لوگ مسلسل گڈمڈ کرتے ہیں۔ پیشگی مشترکہ کلید IPsec ساتھیوں کی توثیق کرتی ہے۔ صارف نام اور پاس ورڈ PPP کے سامنے صارف کی شناخت کرتے ہیں۔ سرٹیفکیٹ سے توثیق کرنے والے پروفائل پر Windows کا مشترکہ راز دوبارہ لکھنا ناکام مرحلے پر کچھ نہیں بدلتا، اور PPP پاس ورڈ میں ترمیم غائب محفوظ چینل فراہم نہیں کر سکتی۔ یہی ضبط شناخت کی جانچ پر بھی لاگو ہے: سرنگ حاصل کرنے کے لیے ساتھی کی شناخت یا سرٹیفکیٹ کی توثیق بند نہ کریں، کیونکہ تب جڑنے والا راستہ ہوتا ہے، ساتھی نہیں۔
توثیق بھی PPP کا اختتام نہیں۔ صارف کے قبول ہونے کے بعد IPCP کلائنٹ کے پتے اور وہ DNS و WINS اختیارات طے کرتا ہے جو سرور دینے کو تیار ہے۔ کلائنٹ CHAP یا MS-CHAPv2 پاس کر کے بھی بغیر پتے کے رہ سکتا ہے، جو PPP کے اندر خرابی ہے، روٹنگ مسئلہ نہیں۔ IPsec کے بغیر سادہ L2TP درست اور غیر محفوظ رہتا ہے، اس لیے کامیاب کنکشن کبھی ثابت نہیں کرتا کہ ٹریفک محفوظ ہے؛ دیکھیں سرور کیا لازم ٹھہراتا ہے، کلائنٹ کا لیبل نہیں۔
پہلے غائب مرحلے سے فیصلہ کریں
جدول کو پہلے غائب عنصر کے مطابق بائیں سے دائیں پڑھیں۔ دایاں کالم اس لمحے واحد کارآمد کام ہے؛ اس کے بائیں سب پہلے ہی ثابت ہے، اور دوبارہ جانچ معلومات شامل کیے بغیر خلل کی کھڑکی جلاتی ہے۔
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
تین قطاریں توجہ کے قابل ہیں۔ 1701 قطار وہ جگہ ہے جہاں NAT کے پیچھے Windows کلائنٹ عام طور پر اترتے ہیں: ایسوسی ایشن مکمل ہوتی ہے، پھر کچھ نہیں آتا، اور وجہ خراب پاس ورڈ نہیں بلکہ انکیپسولیشن ہے۔ IPCP قطار وہ ہے جسے غلطی سے روٹ مسئلہ پڑھا جاتا ہے، کیونکہ Windows غائب پتہ کو خرابی 720 میں لپیٹتا ہے اور ٹرے آئیکن صرف کہتا ہے کہ کنکشن ناکام ہوا؛ وہ خرابی توثیق کے بعد اور روٹنگ سے پہلے بیٹھی ہے۔ آخری قطار بالکل IPsec خرابی نہیں، اگرچہ آئیکن کہے کہ منقطع ہے۔
وہ کمانڈز جو تہوں کو الگ کرتی ہیں
strongSwan چلانے والے Linux سرور پر swanctl --list-sas قائم ایسوسی ایشنز کو ساتھی کی شناخت کے ساتھ فہرست کرتا ہے، اور ipsec statusall پرانے strongSwan اور libreswan میزبانوں کو ڈھانپتا ہے۔ اس کے نیچے ip xfrm state کرنل کی اصل ایسوسی ایشنز دکھاتا ہے، جبکہ ss -lunp | grep 1701 ثابت کرتا ہے کہ xl2tpd کہاں بندھا ہے۔ کنٹرول کنکشنز اور کالیں آتے دیکھنے کے لیے xl2tpd -D سامنے چلائیں، اور پیش کردہ طریقہ اور جواب دیکھنے کے لیے /etc/ppp/options.xl2tpd میں pppd ڈیبگ فعال کریں۔
جب لاگ کامیاب توثیق دکھائیں، اگلا سوال یہ ہے کہ IPCP مکمل ہوا۔ دیکھیں کہ /etc/xl2tpd/xl2tpd.conf کے [lns default] حصے میں ip range کے پاس اب بھی خالی پتے ہیں، اور اگر کلائنٹ توقع کرتا ہے تو /etc/ppp/options.xl2tpd واقعی ms-dns اور ms-wins رکھتا ہے۔ ختم شدہ تالاب اور غائب DNS اختیار تار پر مختلف نظر آتے ہیں: پہلا کلائنٹ کو بغیر پتے اور 720 کے ساتھ چھوڑتا ہے، دوسرا پتہ دیتا ہے مگر کوئی حل کنندہ نہیں، اس لیے نام ناکام ہوتے ہیں جبکہ خام پتوں پر ping کام کرتا ہے۔ دونوں پاس ورڈ دوبارہ لکھنے سے درست نہیں ہوتے۔
کلائنٹ پر NetworkManager کا L2TP پلگ ان pppd کی گفتگو جرنل میں لکھتا ہے، اس لیے journalctl -u NetworkManager -b عام طور پر سرنگ اوپر، توثیق مسترد کو کوئی سرنگ ہی نہیں سے الگ کرتا ہے۔ Windows پر Get-VpnConnection پروفائل کی اصل توثیق کی ترتیبات بتاتا ہے، اور Event Viewer میں Application کے تحت RasClient واقعات ناکام جزو کا نام لیتے ہیں۔ جب ڈائیلاگ بہت مبہم ہو، netsh ras set tracing * enable فعال کریں۔
کیپچر کو ایک احتیاط درکار ہے۔ ٹرانسپورٹ موڈ IPsec کے ساتھ اندرونی UDP 1701 خفیہ ہے، اس لیے بیرونی انٹرفیس پر کیپچر ESP دکھاتا ہے، یا NAT-T کے تحت UDP 4500، اور L2TP بالکل نہیں۔ کیپچر میں 1701 نہ ہونا متوقع ہے اور بند پورٹ کا ثبوت نہیں؛ دیکھیں کہ ESP یا 4500 کاؤنٹر ہلتے ہیں یا نہیں۔
NAT، MTU اور راستے: جہاں اسٹیک آپ کو گمراہ کرتا ہے
NAT مفروضے توڑ دیتا ہے اس سے پہلے کہ کچھ توثیق ہو۔ ESP اپنا IP پروٹوکول ہے، اس لیے ترجمہ کرنے والا آلہ اسے پھینک دیتا ہے جب تک ساتھی انکیپسولیٹ نہ کریں؛ UDP 4500 یہی فراہم کرتا ہے۔ ایسے Windows سرور پر جو خود گھریلو روٹر یا کلاؤڈ NAT گیٹ وے کے پیچھے ہو، IPsec مرحلہ خرابی 789 سے ناکام ہوتا ہے، جب تک PolicyAgent کلید کے تحت AssumeUDPEncapsulationContextOnSendRule 2 پر مقرر نہ ہو اور مشین دوبارہ شروع نہ ہو، اور خرابی بند پورٹ سے الگ نہیں پہچانی جاتی۔ NAT کے پیچھے کلائنٹ آسان ہیں: سرور پر عوامی پتہ ہو تو UDP 4500 پر NAT-T انہیں لے کر چلتا ہے اور وہ قدر شامل نہیں ہوتی۔
جب PPP اوپر ہو، سیاہ سوراخ والا MTU مردہ سرنگ کی نقل کرتا ہے: چھوٹے پیکٹ گزرتے ہیں، TLS ہاتھ ملانا یا صفحہ لوڈ ہونا لٹک جاتا ہے، اور کلائنٹ اب بھی منسلک دکھا سکتا ہے۔ سرور کو قصوروار ٹھہرانے سے پہلے انٹرفیس کا MTU گھٹائیں یا گیٹ وے پر MSS سکیڑیں۔ تقسیم شدہ سرنگ کی روٹنگ دوسرا دھوکے باز ہے؛ غلط ماسک کے ساتھ بھیجی گئی سب نیٹ سرنگ کو صحت مند اور ایک ایپلیکیشن کو ناقابل رسائی رکھتی ہے۔ نجی میزبان نام اپنا قدم جوڑتا ہے: اگر استفسار مقامی حل کنندہ سے باہر جائے تو کسی بھی راستے کی جانچ سے پہلے نام حل نہیں ہوتا۔
اسناد کو چھونے سے پہلے چیک لسٹ
فہرست ترتیب سے کریں اور پہلے ناکام عنصر پر رکیں۔ ہر قدم سستا ہے، اور ہر ایک ترمیمات کی پوری کلاس خارج کرتا ہے۔
- تصدیق کریں کہ ایسوسی ایشن دونوں سروں پر ہے، منسلک لیبل سے نہیں بلکہ ساتھی کی شناخت سے ملا کر۔
- تصدیق کریں کہ UDP 1701 xl2tpd تک پہنچتا ہے؛ بغیر کال ایسوسی ایشن ہی آپ کی خرابی ہے۔
- پاس ورڈ غلط ماننے سے پہلے PPP کا فیصلہ، اور توثیق ہوئی تو IPCP کا نتیجہ پڑھیں۔
- ابھی ہی اسناد کو سرور کی متوقع شکل میں دوبارہ درج کریں، کیونکہ ڈومین سابقہ اکاؤنٹ بدل دیتا ہے۔
- اگر پھر بھی ناکام ہو تو دونوں سرے ہم آہنگ وقت کے نشانوں کے ساتھ کیپچر کریں اور مرحلہ وار موازنہ کریں۔
دوسرے قدم پر رکنا یعنی راستہ یا انکیپسولیشن مسئلہ، اور پاس ورڈ کی کوئی ترمیم اسے نہیں ہلائے گی۔ تیسرے قدم پر رکنا یعنی لاگ پہلے ہی درست کرنے والا طریقہ یا پتہ تالاب نام لے چکا ہے۔ بہرحال اگلی تبدیلی وہ ہے جس کا آپ جواز پیش کر سکیں، اور آپ ایسی ترتیبات میں گھومنا چھوڑ دیتے ہیں جو کبھی شامل نہ تھیں۔