PPTP اور L2TP/IPsec صارف نام کی پوچھ سے پہلے کیوں رک جاتے ہیں؟
صارف نام کی پوچھ نہ آنا یعنی PPP کبھی شروع نہیں ہوا، اس لیے خرابی ترسیل، کلید کی ادلا بدلی یا ٹنل سیٹ اپ میں ہے۔ دوبارہ انسٹال کرنے سے پہلے مرحلوں کی ترتیب دیکھیں۔۔
صارف نام کی پوچھ نہ آنا تشخیصی تحفہ ہے: PPP ابھی شروع نہیں ہوا، اس لیے اکاؤنٹ، پاس ورڈ اور ڈومین پالیسی ابھی نہیں پوچھی گئی۔ PPTP یا L2TP/IPsec کنکشن میں کلائنٹ اسناد صرف اس وقت مانگتا ہے جب ٹنل موجود ہو اور سرور PPP سیشن شروع کر چکا ہو۔ اس لمحے سے پہلے جو کچھ ناکام ہو سکتا ہے وہ ترسیل، کلید کی ادلا بدلی یا ٹنل سیٹ اپ ہے، جو «VPN خراب ہے» سے بہت چھوٹا میدان ہے۔
غائب پوچھ خرابی کو تین مرحلوں تک محدود کرتی ہے
آخری مرحلہ لکھیں جو نظر آ کر کامیاب ہوا، کیونکہ ہر ایک کا مالک اور حل الگ ہے۔ دو مرحلے پہلے پھنسے ہوئے اکاؤنٹ کی ترتیبات کا اندازہ لگانا وہ طریقہ ہے جس سے دوپہر گزر جاتی ہے۔
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
بغیر پوچھ کے وقت ختم ہونے والے کلائنٹ کو کبھی IPsec انجمن نہیں ملی، اس لیے خرابی IKE میں ہے یا اس میں کہ آپ کے پیکٹ گیٹ وے تک پہنچتے ہیں یا نہیں۔ جو کلائنٹ اسناد جانچنے کی اطلاع دے کر پھر گر جاتا ہے وہ پیغام کے اشارے سے آگے گیا تھا۔ پوچھ کے بعد انکار آنا PPP تصدیق ہے، اور اس کی جگہ اکاؤنٹ کے مضمون میں ہے، اس مضمون میں نہیں۔
پہلا مرحلہ: وہ پروٹوکول جسے فائر وال خاموشی سے گرا دیتا ہے
PPTP کو اپنے کنٹرول چینل کے لیے TCP 1723 اور ڈیٹا راستے کے لیے IP پروٹوکول 47 چاہیے، اور دونوں الگ سفر کرتے ہیں۔ بہت سے نیٹ ورک 1723 آگے بھیجتے ہیں اور پروٹوکول 47 گرا دیتے ہیں، جس سے ایسی ٹنل بنتی ہے جو بات چیت کرتی ہے اور پھر کچھ بھی نہیں ڈھوتی۔ NAT کرنے والے راؤٹر کو GRE معاون گزرگاہ بھی چاہیے، اور صرف IPv6 والا رسائی راستہ کسی ترتیب میں PPTP نہیں ڈھو سکتا۔
IPsec پر L2TP IKE کے لیے پورٹ 500 اور NAT عبور کرنے کے لیے پورٹ 4500 خرچ کرتا ہے، پھر L2TP ٹریفک کو ہی 1701 میں لپیٹتا ہے، اور انجمن بننے کے بعد ESP محفوظ پے لوڈ ڈھوتا ہے۔ دو کنٹرول پورٹس کی اجازت دیں مگر ESP کی نہیں، اور آپ کو بالکل سرخی والی علامت ملے گی: نظر آنے والی پیش رفت، پھر کسی بھی اسناد گفتگو سے پہلے مردہ کلائنٹ۔ فون ہاٹ اسپاٹ سے جانچنا کلائنٹ کے مسئلے کو راستے کے مسئلے سے الگ کرنے کا سستا طریقہ ہے۔
دوسرا مرحلہ: وہ کلید جو کلید نہیں، وہ تجویز جو پیش نہیں کی جاتی
جو کلید پہلے سے شیئر کی گئی ہے اور میل نہیں کھاتی وہ تیزی سے اور خاموشی سے ناکام ہوتی ہے، اور عام شکل وہ کلید ہے جو اسکرین پر درست دکھتی ہے مگر چسپاں کردہ سطر کا وقفہ یا آخر میں خالی جگہ رکھتی ہے۔ Linux کلائنٹ پر گفتگو ضروری نہیں کہ سچائی کا ماخذ ہو: NetworkManager کا L2TP پلگ ان راز /etc/ipsec.d/ کے نیچے فائلوں میں رکھتا ہے، اور پرانی فی کنکشن فائل جسے /etc/ipsec.secrets اب بھی شامل کرتا ہے آپ کی ابھی ٹائپ کردہ فائل کی بجائے استعمال ہوگی۔ وہ فائل محفوظ جگہ پر نقل کریں، شمولیت کے راستے سے ہٹائیں، اور پھر کلید ہاتھ سے دوبارہ ٹائپ کریں۔
اس مرحلے کا دوسرا نصف تجویز ہے۔ دونوں سروں کو ایک ہی مرحلے 1 کے الگورتھم مجموعے — انکرپشن، سالمیت اور Diffie-Hellman گروپ — اور مرحلے 2 کے لیے میل کھاتے ESP تبدیلیوں پر متفق ہونا چاہیے، ورنہ انجمن ہی نہیں بنتی۔ جو گیٹ وے صرف 3DES، SHA1 اور MODP1024 دیتا ہے وہ مضبوط الگورتھم کے لیے ترتیب دیے گئے کلائنٹ کو مسترد کرے گا، اور اس کا لاگ مسترد شدہ تبدیلی کا نام لیتا ہے۔ سروس دوبارہ چلانے کی بجائے لاگ پڑھیں تو لاگ ہی عدم مطابقت کا نام لیتا ہے۔ فورم کے دھاگے سے الگورتھم کی تار نقل کرنے کی بجائے گیٹ وے سے پوچھیں کہ وہ واقعی کن تبدیلیوں پر گفتگو کرے گا: اس کے پتے کی طرف نشانہ ike-scan وہ تبدیلیاں واپس دیتا ہے جن پر وہ گفتگو کرے گا۔ اگر واحد پیشکش ایسی کرپٹوگرافی ہے جس کی آپ کی پالیسی اب اجازت نہیں دیتی، تو اصلاح گیٹ وے پر ہے، کلائنٹ کو نیچے کرنے میں نہیں۔
Windows میں کلید اور تصدیق کا طریقہ VPN پروفائل میں رہتا ہے، اور عدم مطابقت اسناد کی پوچھ سے پہلے ظاہر ہوتی ہے، بعد میں نہیں۔ جہاں وصول کنندہ Windows Server ہو، وہاں یقینی بنائیں کہ دور رسائی کا کردار نصب ہے، سرٹیفکیٹ اس نام سے میل کھاتا ہے جس پر کلائنٹ جڑتے ہیں، اور کوئی پورٹ فلٹر اوپر کے پروٹوکولوں سے تنگ نہیں۔
تیسرا مرحلہ: ٹنل موجود ہے اور PPP شروع نہیں ہوتا
IKE مکمل ہونے کے بعد بھی پوچھ نہ آئے تو فائر وال نہیں، ٹنل ڈیمن دیکھیں۔ L2TP کو UDP 1701 پر سننے والا کچھ چاہیے — Linux میں xl2tpd یا kl2tpd، Windows میں دور رسائی سروس — اور نصب مگر بند سروس کلائنٹ کی طرف سے پھینکے گئے پیکٹ جیسی ہی دکھتی ہے۔ جو قواعد آپ پہلے ہی جانچ چکے ہیں انہیں دوبارہ کھولنے سے پہلے سننے والے کو دیکھیں۔ پھر PPP کو گفتگو کرنی ہوتی ہے، اور پہلی LCP ادلا بدلی وہی جگہ ہے جہاں خاموش ناکامی عام طور پر اترتی ہے۔
اس مرحلے کا ایک جال نیٹ ورک کی خرابی بالکل نہیں ہے: Windows ایک وقت میں دیے گئے VPN قسم کا صرف ایک کنکشن اجازت دیتا ہے، اس لیے دوسری کوشش غلطی 937 واپس دیتی ہے، «اس قسم کا دوسرا کنکشن استعمال میں ہے»۔ یہ مقامی قاعدہ ہے، اور اس سے بچنے کا راستہ دوسرا آلہ، دوسری ٹنل قسم، یا پہلے سے موجود واحد کنکشن کو شیئر کرنا ہے۔
اندازہ لگانے کی بجائے مرحلوں کی ترتیب میں لاگ پڑھیں
کلائنٹ روکیں، دوبارہ چلائیں، اور اجزا کو اسی ترتیب میں پڑھیں جس میں وہ لاگ لکھتے ہیں۔ یعنی پہلے IPsec ڈیمن — strongSwan یا Libreswan، اور ipsec --version بتاتا ہے کون — پھر L2TP ڈیمن، پھر pppd۔ ناکامی سے پہلے جس جز نے آخری بار لکھا وہی جانچنے والا مرحلہ بتاتا ہے، کیونکہ ترتیب میں اس کے بعد آنے والا کچھ بھی چلا ہی نہیں۔
محفوظ شدہ سیشن کی بجائے نئے کنکشن سے تصدیق کریں، کیونکہ کیشے سے دوبارہ جڑنے والا کلائنٹ ادلا بدلی کے حصے چھوڑ کر پرانا نتیجہ دہرا سکتا ہے۔ رسائی، کلید کی ادلا بدلی، ٹنل اور PPP ایک ایک کر کے، اسی ترتیب میں تصدیق کریں۔ تب غائب پوچھ معمہ رہنا چھوڑ دیتی ہے اور ایسی فہرست کی دوسری سطر بن جاتی ہے جس پر واقعی کام کیا جا سکتا ہے۔ وہی فہرست آپ نیٹ ورک ٹیم کو دیتے ہیں، جسے ورنہ ایسی خرابی کے لیے فائر وال جانچنے کو کہا جائے گا جو بغیر چلے ڈیمن میں رہتی ہے۔