Android OpenVPN ٹنل ایڈریس کے بغیر روٹ شامل نہیں کرتا

آپ کا Android OpenVPN پروفائل روٹ شامل نہیں کر سکتا کیونکہ فون کے پاس ورچوئل انٹرفیس پر کوئی ایڈریس نہیں، اس لیے روٹ کے اشارہ کرنے کے لیے کچھ نہیں۔ روٹ صرف یہ بتاتے ہیں کہ پیکٹ کہاں جانے چاہئیں۔ ٹنل ایڈریس یہ بتاتا ہے کہ ٹنل کے اندر فون کون ہے، اور انٹرفیس وجود میں آنے سے پہلے کلائنٹ کو ایک دینا ہوگا۔ نیچے دی گئی چاروں جانچیں ترتیب سے کریں اور پہلی ناکامی پر رک جائیں، کیونکہ ایڈریس سے پہلے روٹ میں ترمیم اصل مسئلہ چھپا دیتی ہے۔

ناکامی کو اسی ترتیب سے پڑھیں جس میں کلائنٹ اسے چلاتا ہے

Android کا VpnService.Builder دونوں تصورات کو الگ رکھتا ہے: addAddress() اس انٹرفیس پر ایڈریس رکھتا ہے جو ایپ بنا رہی ہے، addRoute() منزل کا سابقہ شامل کرتا ہے، اور establish() کم از کم ایک ایڈریس شامل ہونے تک انٹرفیس بنانے سے انکار کرتا ہے۔ OpenVPN کلائنٹ پروفائل اور سرور کے بھیجے گئے اختیارات کو بالکل انہی کالوں پر نقش کرتا ہے، اس لیے جو کنکشن کبھی ایڈریس تجزیہ نہیں کرتا وہ انٹرفیس بنا ہی نہیں سکتا۔

اسی لیے آپ جو لاگ لائن پڑھ رہے ہیں وہ روٹ کا نام لے سکتی ہے جبکہ وجہ ایک قدم پہلے ہے۔ کلائنٹ روٹ کے مرحلے تک انٹرفیس بننے کے بعد ہی پہنچتا ہے؛ ایڈریس نہ ہو تو روٹ کال فوراً ناکام ہو جاتی ہے یا کبھی چلتی ہی نہیں۔ جب لاگ کہے کہ روٹ شامل نہیں کیا جا سکتا، تو روٹ کے نحو سے نہیں، ایڈریس سے شروع کریں۔

جانچ 1: کیا سرور جواب میں ایڈریس رکھتا ہے؟

روٹ شدہ OpenVPN سروس میں ایڈریس سرور کے تالاب یا فی کلائنٹ مختص سے آتا ہے، اور اس کی شکل ٹوپولوجی طے کرتی ہے۔ OpenVPN 2.4 یا نئے سرور پر، سب نیٹ ٹوپولوجی والی سروس ایسی دکھتی ہے:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

اس شکل کے ساتھ سرور ifconfig 10.8.0.6 255.255.255.0 جیسا کچھ بھیجتا ہے۔ پرانا topology net30 نصب اس کے بجائے ساتھی کا ایڈریس بھیجتا ہے، مثلاً ifconfig 10.8.0.6 10.8.0.5، اس لیے دو ماڈلوں کے درمیان منتقل شدہ پروفائل درست دکھ سکتا ہے جبکہ غلط نیٹ ماسک اٹھائے ہوئے ہو۔

کلائنٹ کے کنکشن لاگ میں بھیجے گئے اختیارات کا مجموعہ تلاش کریں۔ اگر اس میں ifconfig کی ایک بھی سطر نہ ہو، تو سرور نے کبھی ایڈریس نہیں بھیجا یا کلائنٹ نے اختیار مسترد کیا۔ جو سرور client-config-dir استعمال کرتا ہے، اس پر سرٹیفکیٹ کے common name کے نام والی فائل موجود ہونی چاہیے اور مختص رکھنا چاہیے:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

جانچ 2: کیا کلائنٹ ملا ہوا ایڈریس رکھتا ہے؟

بہت چوڑا فلٹر دوسری عام وجہ ہے۔ pull-filter OpenVPN 2.4 اور نئے میں موجود ہے، اور جب کئی فلٹر ایک ہی اختیار سے میل کھائیں تو آخری ملی ہوئی جیتتی ہے، اس لیے آخر میں چھوڑا گیا catch-all بغیر خرابی کے ایڈریس ہٹا دیتا ہے:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

فلٹر کو اسی اختیار تک محدود کریں جسے آپ واقعی ہٹانا چاہتے ہیں اور ایڈریس کو چھیڑیں نہیں:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

تمام pull بند کرنے کا مشورہ عام طور پر ایسے شخص سے آتا ہے جو صرف ایک روٹ سے چھٹکارا چاہتا ہے۔ route-nopull زیادہ تنگ سوئچ ہے: یہ ifconfig اور دیگر بھیجے گئے اختیارات رکھتا ہے جبکہ بھیجے گئے روٹ اور DHCP طرز کے اختیارات مسترد کرتا ہے۔ جب واقعی یہی چاہیے ہو تب استعمال کریں، اور ایڈریس کا سوال الگ حل کریں۔

جانچ 3: کیا ایڈریس آپ کے لکھنے کا ہے؟

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

روٹ میں دور دراز LAN کا سابقہ منزل ہے، کبھی فون کی شناخت نہیں۔ 10.60.0.0/24 کے لیے روٹ کہتا ہے کہ اس نیٹ ورک تک ٹنل سے پہنچیں؛ یہ نہیں بتاتا کہ فون کے پاس کون سا 10.60.0.x ایڈریس ہونا چاہیے، اور فون کے پاس ان میں سے کوئی نہیں ہونا چاہیے۔ مستقل مختص سرور کی طرف کے ہوتے ہیں، جہاں وہ متحرک تالاب سے ٹکرا نہیں سکتے۔

ایک شناخت پر دو سیشن وہی ٹکراؤ ظاہر کرتے ہیں۔ اگر ایک ہی سرٹیفکیٹ دو بار جڑے اور سرور دونوں کو ایک مقررہ ایڈریس بھیجے، تو دوسرا سیشن پہلے کی نقل بن جاتا ہے، اور حل کلائنٹ کی طرف ترمیم نہیں بلکہ الگ شناختیں یا الگ مختص ہیں۔

جانچ 4: کیا کوئی اور ٹنل کی جگہ روکے ہوئے ہے؟

Android ایک وقت میں صرف ایک فعال VPN سروس کی اجازت دیتا ہے۔ کوئی دوسری VPN ایپ، یا ایسی always-on VPN اندراج جو اب کام نہ کرنے والے پروفائل کے لیے آن چھوڑی گئی ہو، آپ کے OpenVPN کلائنٹ کے establish() بلانے سے پہلے وہ جگہ لے سکتی ہے۔ پھر پروفائل درست ہونے کے باوجود انٹرفیس کبھی نظر نہیں آتا، اس لیے دوسرا VPN منقطع کریں، always-on ترتیب بند کریں اور پروفائل چھونے سے پہلے دوبارہ جڑیں۔

Ethernet برجنگ پر اصرار کرنے والی سروس دوسری بند گلی ہے۔ root کے بغیر Android ایپ IP ٹنل بنا سکتی ہے، برج شدہ Ethernet قطعہ نہیں، اس لیے آپ جو بھی ایڈریس لکھیں وہ dev tap سرور کو کام نہیں کرائے گا؛ آپریٹر کو روٹ شدہ سروس پیش کرنی ہوگی۔ مسئلہ رپورٹ کرتے وقت کلائنٹ کا نام اور ورژن، بھیجے گئے اختیارات کا مجموعہ، ٹوپولوجی اور وہ درست مرحلہ شامل کریں جہاں ایڈریس نظر آنا چاہیے تھا۔

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