دو لیپ ٹاپ DD-WRT بکس پر PPTP سرور پر ڈائل کرتے ہیں، ہر ایک کو پتہ ملتا ہے، اور کوئی بھی دوسرے کو پنگ نہیں کر سکتا۔ مشترکہ فولڈر کبھی ظاہر نہیں ہوتے اور پہلا خیال یہی آتا ہے کہ روٹر جو 255.255.255.255 ماسک دیتا ہے وہ ضرور غلط ہے۔ یہ قصور نہیں، اور اسے بدلنے سے ایک بھی نیا پڑوسی پیدا نہ ہوگا۔ نیچے دی گئی پانچ جانچیں ترتیب سے کریں اور جیسے ہی کوئی ایک ناکام ہو وہیں رک جائیں، کیونکہ ہر ایک کا علاج الگ ہے۔

پہلی جانچ: /32 کوئی نقص نہیں

PPTP، PPP اٹھائے چلتا ہے، اور PPP لنک بالکل دو سروں کو جوڑتا ہے: آپ کا کلائنٹ اور سرور۔ نیٹ ماسک بتاتا ہے کہ کون سے پتے مقامی قطعہ بانٹتے ہیں، اور یہاں کوئی قطعہ نہیں، صرف ایک تار کے دوسرے سرے پر ہم منصب ہے۔ سب ایک والا ماسک بالکل یہی کہتا ہے، اس لیے DD-WRT اس لنک قسم کے لیے درست قدر دے رہا ہے۔ پتہ ہم منصب کا پتہ ہے، LAN میں انٹرفیس کا پتہ نہیں۔

255.255.255.0 ماسک سینکڑوں آلات والے مشترکہ ذریعے کا ہے، اور اسے PPP انٹرفیس پر رکھنے سے سرنگ کا دوسرا سرا بھی پڑوسی نہیں بنے گا۔

دوسری جانچ: PPTP سرور صفحے کی قدریں پڑھیں

تمام اہم ترتیبات خدمات، VPN، PPTP سرور میں ہیں۔ سرور فعال کریں، سرور کا پتہ روٹر کے LAN پتے پر رکھیں، اور کلائنٹ کی حد DHCP پول سے باہر رکھیں تاکہ ڈائل اِن کلائنٹ اور تار والی مشین کو ایک ہی پتہ نہ ملے۔ CHAP-Secrets کے تحت ہر اکاؤنٹ کے لیے username * password * کی شکل میں ایک سطر شامل کریں، نام کے اندر کوئی خالی جگہ نہ ہو۔ لاگو کریں، پھر ایسی پروفائل سے جڑیں جو روٹر اور ان اکاؤنٹس میں سے کسی ایک کا نام لے۔

کلائنٹ کہاں رکتا ہے یہ بتاتا ہے کہ کون سی پرت دیکھنی ہے۔ جو کلائنٹ تصدیق سے گزرے مگر پتہ نہ ملے وہ پول یا راز کا مسئلہ ہے؛ جو کلائنٹ پتہ ملنے پر بھی کہیں نہ پہنچے وہ راستہ بندی یا فائر وال کا مسئلہ ہے۔

تیسری جانچ: دو ہم منصبوں کے درمیان راستہ تلاش کریں

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

دو الگ ppp انٹرفیسوں کی طرف دو میزبان راستے — آگے بڑھنے سے پہلے یہی شکل درکار ہے۔

چوتھی جانچ: FORWARD زنجیر دیکھیں، INPUT نہیں

کلائنٹ سے کلائنٹ ٹریفک آگے بھیجا جاتا ہے، مقامی طور پر قبول نہیں ہوتا، اس لیے INPUT زنجیر غلط جگہ ہے۔ iptables -L FORWARD -v -n چلائیں اور وہ ڈراپ قاعدہ تلاش کریں جو PPP انٹرفیسوں کو پکڑے، ساتھ ہی وہ پیکٹ شمار کنندہ جو دکھائیں کہ زنجیر تک کچھ پہنچتا ہے یا نہیں۔ سرنگ ٹریفک کے لیے قبولیت کا قاعدہ نہ ہونے والی طے شدہ ڈراپ پالیسی بالکل وہی علامت پیدا کرتی ہے جس سے آپ شروع ہوئے تھے: ہر کلائنٹ اکیلا ٹھیک ہے، مل کر وہ ایک دوسرے کے لیے نظر نہیں آتے۔

اگر چھوٹے پنگ چلیں اور بڑی منتقلی رک جائے، تو سرنگ روکی نہیں جا رہی بلکہ ٹکڑے ہو رہی ہے۔ PPP پر PPTP عام طور پر تقریباً 1450 کا MTU اور MRU چاہتا ہے، اور انہیں 1500 پر چھوڑ دینے سے ایسا لنک ملتا ہے جو مصافحہ پار کر جائے مگر اصل بوجھ پر ناکام ہو۔

پانچویں جانچ: طے کریں کہ انٹرنیٹ رسائی کو کیا کرنا چاہیے

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

آخری بات، جو اصلاح سے متعلق نہیں: PPTP پرانا ہے اور اس کی تصدیق برسوں سے ٹوٹی ہوئی ہے۔ اوپر کی فہرست اب بھی بتاتی ہے کہ PPP لنک کیا کرتا ہے، اور اگر بعد میں کلائنٹ کو جدید سرنگ پر منتقل کریں تو وہی استدلال لاگو ہوگا۔

متعلقہ مضامین