اینڈرائیڈ پر غیر معیاری UDP پورٹ پر IKEv2 کیوں ناکام ہوتا ہے

گیٹ وے UDP 4443 پر IKEv2 کو کسی وجہ سے جواب دیتا ہے، پروفائل میں Server نامی فیلڈ ہے، آپ ہوسٹ کا نام اور پورٹ لکھتے ہیں، اور فون بتاتا ہے کہ وہ سرور تک نہیں پہنچ سکتا یا پتہ حل نہیں کر سکتا۔ کچھ بھی مسدود نہیں ہے۔ اینڈرائیڈ کا مول فارم ہوسٹ کی توقع کرتا ہے، اور ونڈوز پر بھی یہی درست ہے۔ حسب ضرورت پورٹ سرور کی ترتیب بننے سے پہلے کلائنٹ کی صلاحیت ہے، اور صرف کچھ کلائنٹ ہی اسے بیان کرنے دیتے ہیں۔ تینوں حصے ترتیب سے دیکھیں: کلائنٹ کیا کہہ سکتا ہے، سرور کس پر سن رہا ہے، اور کیا دونوں سرے پیکٹ ایک ہی طرح فریم کرتے ہیں۔

فون نے دراصل کیا بھیجا

نام کے لیے بنائی گئی فیلڈ میں host:port اسٹرنگ نام کے طور پر حل ہوتی ہے۔ حل کنندہ vpn.example.net:4443 کے لیے کچھ واپس نہیں کرتا، اور جو خرابی آپ دیکھتے ہیں وہ پورٹ پر وقت کا ختم ہونا نہیں بلکہ نام حل ہونے یا عدم رسائی کی ناکامی ہے۔ یہ فرق اہم ہے، کیونکہ چھوٹے نام یا دوسرے نیٹ ورک کے ساتھ دوبارہ کوشش اس اسٹرنگ کو کبھی ٹھیک نہیں کرے گی جسے فارم تجزیہ نہیں کر سکتا۔

اینڈرائیڈ پر مول IKEv2 پروفائل، ونڈوز کے بلٹ اِن VPN کلائنٹ کی طرح، معیاری IKE پورٹس پر مقفل ہے۔ ان میں سے کوئی پورٹ فیلڈ نہیں دکھاتا، اور پروفائل میں ترمیم سے کوئی شامل نہیں ہوتا۔ اگر آپریٹر کا سننے والا واقعی 4443 پر ہے تو بلٹ اِن کلائنٹ غلط طریقے سے ترتیب دیا گیا نہیں بلکہ غلط اوزار ہے۔

ایسا کلائنٹ استعمال کریں جو پورٹ دکھائے

strongSwan کا اینڈرائیڈ کلائنٹ اپنی اعلیٰ درجے کی پروفائل ترتیبات میں قابلِ ترتیب سرور پورٹ کی دستاویز کرتا ہے، اسی لیے یہ اس ڈیزائن کے لیے کام کرنے والی تقریباً ہر ترکیب میں نظر آتا ہے۔ یہ حمایت اسی کلائنٹ کی ہے: کوئی دوسرا IKEv2 ایپ، یا اسی ایپ کا وینڈر فورک، وہی فیلڈ نہیں دکھا سکتا، اگرچہ نیچے کا strongSwan ڈیمن اس کی حمایت کرتا ہو۔

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

سرور کے دو پورٹ ہیں، اور دونوں کا میل کھانا ضروری ہے

IKE UDP 500 پر شروع ہوتا ہے، اور NAT گزر عام طور پر IKE اور لپیٹے گئے ESP کو UDP 4500 پر منتقل کرتا ہے۔ یہ strongSwan میں الگ ترتیبات ہیں، اس لیے ایک حسب ضرورت پورٹ پر منتقل شدہ سرور کو دونوں کو ایک ہی قدر میں بدلنا ہوگا:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

جب ایک ہی پورٹ دونوں کردار ادا کرے تو ڈیمن کو اسی ساکٹ پر IKE کو ESP-in-UDP سے الگ کرنا ہوتا ہے، جو وہ IKE پیغام سے پہلے آنے والے چار بائٹ غیر ESP نشان کے ذریعے کرتا ہے۔ اسی لیے کلائنٹ حسب ضرورت پورٹ پر گفت و شنید کر کے پھر خاموشی سے 4500 پر جاری نہیں رکھ سکتا، اور اسی لیے “صرف پورٹ بدل دیں” کا فقرہ فریمنگ کی شرط چھپاتا ہے۔

فارورڈ کرنا سننے والا نہیں ہے

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

راستے کو UDP بھی سرے سے سرے تک اجازت دینی چاہیے۔ TCP 443 کا ہوٹل یا آپریٹر نیٹ ورک سے گزرنا UDP پورٹ پر IKEv2 کے بارے میں کچھ نہیں کہتا، چاہے نمبر ایک ہی ہو۔ جہاں صرف TCP 443 کی اجازت ہو، وہاں حسب ضرورت UDP پورٹ IKEv2 کو HTTPS نہیں بناتا، اور درست جواب کوئی اور پورٹ تجربہ نہیں بلکہ دوسرا رسائی راستہ ہو سکتا ہے۔

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

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

tcpdump -ni eth0 -vv udp port 4443

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