PPTP کنکشن کو اوپر آتے دیکھیں اور یہ ماننا آسان ہے کہ مشکل حصہ ختم ہو گیا: کلائنٹ تصدیق کرتا ہے، ppp0 اڈاپٹر یا WAN Miniport ظاہر ہوتا ہے، اور اسٹیٹس ونڈو سبز ہو جاتی ہے۔ پھر اندرونی ہوسٹ کی پہلی درخواست وقت سے گزر جاتی ہے، اور پروفائل کو قصوروار ٹھہرایا جاتا ہے۔ عملاً دو آزاد تہیں صاف کرنی ہیں: بیرونی نقل و حمل جو TCP 1723 اور GRE لے جاتی ہے، اور اندرونی پالیسی جو فیصلہ کرتی ہے کہ کون سے مقامات PPP انٹرفیس استعمال کریں۔ سبز حالت صرف یہ ثابت کرتی ہے کہ پہلی تہہ نے بات چیت کی؛ دوسری کے بارے میں یہ کچھ نہیں کہتی۔

کلائنٹ کا پروفائل سے کنٹرول ساکٹ تک پیچھا کریں

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

کسی بھی راستے کو چھونے سے پہلے تار پر کنٹرول کنکشن کی تصدیق کریں۔ کلائنٹ یا آئینہ پورٹ پر، ایک کنکشن کوشش کے لیے TCP 1723 حاصل کریں:

sudo tcpdump -ni any 'tcp port 1723' -c 20

مکمل ہینڈ شیک اور قائم شدہ سیشن کا مطلب ہے کہ بیرونی کنٹرول چینل کام کر رہا ہے۔ جو SYN کبھی SYN-ACK نہیں پاتا وہ فائر وال، غلط سرور پتہ یا پورٹ فلٹر کرنے والے فراہم کنندہ کی طرف اشارہ کرتا ہے۔ ہینڈ شیک کے فوراً بعد ری سیٹ آنا اکثر یہ معنی رکھتا ہے کہ سرور نے اسناد یا ٹنل کی قسم مسترد کر دی۔

GRE دوسرا پروٹوکول ہے، پورٹ نہیں

PPTP PPP پے لوڈ کو توسیع شدہ GRE، IP پروٹوکول 47 کے اندر لے جاتا ہے، جس کا کوئی پورٹ نمبر نہیں جسے راؤٹر ٹریک کر سکے۔ اسی لیے TCP 1723 کی اجازت دینے والا اصول بھی ٹنل کو ڈیٹا راستے کے بغیر چھوڑ سکتا ہے۔ اسٹیٹ رکھنے والے NAT آلات کو جوابات واپس نقش کرنے کے لیے GRE کے اندر کال ID سمجھنا ہوتا ہے، اور بہت سے ایسا نہیں کرتے۔ PPTP تفصیل کنٹرول چینل اور GRE پے لوڈ کو الگ حصوں کے طور پر رکھتی ہے، اور آپ کے ٹیسٹ منصوبے کو بھی ایسا ہی ہونا چاہیے۔

اسی کیپچر میں پروٹوکول 47 دیکھیں، پھر جو باہر جاتا ہے اس کا جو واپس آتا ہے اس سے موازنہ کریں:

sudo tcpdump -ni any 'proto gre' -c 20

جو پیکٹ جواب کے بغیر باہر جاتے ہیں، جبکہ TCP 1723 صحت مند رہتا ہے، وہ مسدود GRE کی روایتی نشانی ہیں۔ صارفین کے راؤٹر پر PPTP پاس تھرو اسی مخصوص فرم ویئر کی خصوصیت ہے، لہٰذا کام کرنے والا ہوٹل نیٹ ورک اگلے کے بارے میں کچھ ثابت نہیں کرتا۔ اگر راؤٹر پاس تھرو نہیں دیتا اور آپ اسے بدل نہیں سکتے، تو مسئلہ راؤٹ ٹیبل نہیں، پروٹوکول کا انتخاب ہے۔

ثابت کریں کہ ٹنل ایک پیکٹ منتقل کرتی ہے

GRE بہنے لگے تو PPP بات چیت کلائنٹ انٹرفیس کو پتہ تفویض کرتی ہے۔ فرض کرنے کے بجائے تفویض پڑھیں:

ip -4 addr show ppp0

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

کوئی بھی اسپلٹ راستہ شامل کرنے سے پہلے یہ کریں۔ نقل و حمل خراب ہونے کی حالت میں کیا گیا راستہ تبدیلی دوسرا متغیر پیدا کرتا ہے اور پہلے کو چھپا دیتا ہے۔

اسپلٹ پالیسی لکھیں، DNS سمیت

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

ہر زمرے میں ایک پتے کے لیے کرنل کا فیصلہ جانچیں:

ip route get 10.20.5.10
ip route get 203.0.113.25

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

پانچ مراحل میں دہرائی جانے والی جانچ

تہوں کو ترتیب سے چلائیں اور پہلی ناکام تہہ پر رکیں: کنٹرول چینل، GRE کی نظر آنا، PPP پیر کا جواب، ایک اندرونی پتے کے لیے اسپلٹ راستہ، اور ٹنل پر ایپلیکیشن درخواست۔ ہر مرحلے کا اپنا حکم ہے، لہٰذا ناکامی پراسرار نہیں بلکہ منسوب کی جا سکتی ہے۔

Linux کلائنٹ کے لیے مختصر ورژن ایسا دکھتا ہے:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows میں وہی ترتیب route print اور کلائنٹ میں دکھائی گئی اڈاپٹر حالت کے ساتھ لاگو ہوتی ہے۔ PPTP پرانا پروٹوکول ہے، اور اگر سرور SSTP یا IKEv2 پیش کرے تو ہر ہاپ پر پروٹوکول 47 گزرنے پر منحصر راستہ ایڈجسٹ کرنے سے بہتر عام طور پر منتقل ہونا ہے۔ پرانے پروفائل کو نئی ریلیز میں نقل کرنے کے بجائے متبادل کا سرٹیفکیٹ اور تصدیقی معاہدہ جانچیں۔

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