اینڈرائیڈ کا واحد-VPN اصول ہوسٹ شدہ SSH سرور کو نہیں روکتا

یہ عقیدہ اتنا عام ہے کہ اسے حقیقت سمجھا جاتا ہے: اینڈرائیڈ صرف ایک VPN کی اجازت دیتا ہے، اس لیے فون پر چلنے والا SSH سرور اُس ٹنل سے کام نہیں کر سکتا۔ پہلا نصف درست ہے اور نتیجہ اُس سے نہیں نکلتا۔ پلیٹ فارم کی حد اس بارے میں ہے کہ کتنی ایپس VPN سروس کی جگہ لے سکتی ہیں، نہ کہ کتنے ساکٹس ہو سکتے ہیں یا فون سے کون جڑ سکتا ہے۔ سننے والا ساکٹ رکھنے والا SSH ڈیمون ایک عام پورٹ والی عام ایپ ہے، اور ٹنل اُن راستوں میں سے ایک ہے جن سے اُس کی ٹریفک جا سکتی ہے۔

واحد-VPN اصول واقعی کس چیز کو محدود کرتا ہے

VpnService ایک ہی جگہ کا وسیلہ ہے۔ جب کوئی ایپ ٹنل قائم کرتی ہے تو وہ ڈیوائس کا VPN بن جاتی ہے، اور دوسری ایپ جو ٹنل قائم کرنے کی کوشش کرتی ہے، پہلی کے جانے تک مسترد ہو جاتی ہے۔ یہ ٹنل کی ملکیت کا اصول ہے، اور یہ بتاتا ہے کہ دو VPN کلائنٹ ایک ساتھ کیوں نہیں چل سکتے۔

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

لسنر ایک منزل ہے، ٹنل کا حصہ نہیں

ٹنل موجود ہونے پر فون کا اُس پر ایک پتہ ہوتا ہے اور ہم منصب ڈیوائس کا اُس پتے تک راستہ ہوتا ہے۔ کچھ جواب دیتا ہے یا نہیں، یہ لسنر طے کرتا ہے۔ loopback سے بندھا ڈیمون صرف خود فون سے قابلِ رسائی ہے؛ پرانے ٹنل پتے سے بندھا ڈیمون دوبارہ جڑنے کے بعد بھی اپنا بندھن برقرار رکھ سکتا ہے جبکہ جس پتے سے وہ بندھا تھا وہ بدل چکا ہوتا ہے۔

باندھنے کے اصول عام SSH کنفیگریشن ہیں: سننے کا پتہ اور پورٹ، اور کون تصدیق کر سکتا ہے۔ اینڈرائیڈ پر وہ سیٹنگز ایپ کی اپنی کنفیگریشن میں ہوتی ہیں، اور ایپ کے پروسیس کے مالک کو مراعات یافتہ پورٹس استعمال کرنے کی اجازت نہ ہو سکتی ہے، اس لیے root کے طور پر پورٹ 22 باندھنے کی ڈیسک ٹاپ عادت بلا تبدیلی منتقل نہیں ہوتی۔

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

پھر راستے پر ہی اجازت ہے۔ صارفی VPN جو باہر جانے والی ویب ٹریفک خوشی سے ڈھوتا ہے، اُسے اپنے کلائنٹس کی طرف آنے والے کنکشنز کی اجازت دینے کی ضرورت نہیں؛ بہت سے نہیں دیتے، کیونکہ یہ ایک صارف کو دوسرے کے سامنے لے آئے گا۔ اگر ہم منصب کہیں سے بھی فون کے ٹنل پتے تک نہیں پہنچ سکتا، تو مسئلہ سروس کی پالیسی میں ہے، فون میں نہیں۔

جوابی راستہ وہ جگہ ہے جہاں عام طور پر ٹوٹتا ہے

فرض کریں ہم منصب فون کے ٹنل پتے تک پہنچتا ہے اور SYN آتا ہے۔ اب جواب کو اُسی راستے سے باہر جانا ہے، اور یہ فون کے اندر روٹنگ کا فیصلہ ہے۔ اگر جواب Wi-Fi سے باہر جاتا ہے کیونکہ وہی ڈیفالٹ نیٹ ورک ہے، تو ہم منصب کو ایسا کنکشن نظر آتا ہے جو کبھی مکمل نہیں ہوتا، جو فائر وال جیسا ہی لگتا ہے۔

اینڈرائیڈ اسے ڈیسک ٹاپ سے زیادہ پیچیدہ بناتا ہے کیونکہ ڈیفالٹ نیٹ ورک فی پروسیس منتخب ہوتا ہے اور VPN ایپ کی پالیسی اُسے بدل سکتی ہے۔ VPN کلائنٹ صرف اجازت یافتہ ایپس کی فہرست کو روٹ کر سکتا ہے، اس لیے اُس فہرست سے باہر کی سرور ایپ اپنے جوابات کے لیے جسمانی نیٹ ورک استعمال کرتی رہتی ہے جبکہ ہم منصب اُنہیں ٹنل سے متوقع کرتا ہے۔

ایپ اپنے ساکٹس کو کسی مخصوص نیٹ ورک سے بھی باندھ سکتی ہے، جو ڈیفالٹ کو منسوخ کرتا ہے۔ جب آپ کوئی رپورٹ پڑھیں کہ کوئی سروس ایک پتے سے قابلِ رسائی ہے اور دوسرے سے نہیں، تو عام طور پر یہی اُس کے پیچھے کا طریقہ کار ہوتا ہے۔

VPN کو بائی پاس کرنا آنے والی سروس کی مرمت نہیں کرتا

مقبول حل، SSH ایپ کو VPN سے خارج کرنا تاکہ اُس کی ٹریفک دوبارہ نیویگیٹ ہونا بند ہو، اُلٹے مسئلے کی درستی ہے۔ یہ اُس وقت مدد کرتا ہے جب باہر جانے والے SSH کلائنٹ کی ترسیل ٹنل کی وجہ سے بار بار ٹوٹتی ہو۔ ہوسٹ شدہ سرور کے لیے یہ جوابات کو اُس ٹنل سے باہر لے جا سکتا ہے جو ہم منصب استعمال کر رہا ہے، جس سے جزوی ناکامی مکمل ناکامی بن جاتی ہے۔

یہی بات روٹر پر عوامی پورٹ کھولنے پر بھی لاگو ہوتی ہے۔ اگر تقاضا یہ ہو کہ ایک مجاز ڈیوائس VPN کے ذریعے فون تک پہنچے، تو SSH کو انٹرنیٹ پر کھولنا ایک مختلف خطرہ ماڈل ہے، مرمت نہیں۔

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

ایک وقت میں ایک سمت کی تشخیص کریں

کنفیگریشن بدلنے سے پہلے چار حقائق لکھیں: وہ پتہ جس سے ہم منصب جڑ رہا ہے، فون پر لسنر کی حالت، اُسے رکھنے والا ایپ اور صارف کا سیاق، اور ہر سمت میں مشاہدہ شدہ راستہ۔ جو رپورٹ کہتی ہے کہ VPN SSH کو منقطع کرتا ہے، اُس میں اِن میں سے کوئی نہیں ہوتا اور وہ کلائنٹ کی ترسیل کے مسئلے کو ناقابلِ رسائی سرور سے الگ نہیں کر سکتی۔

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

پورٹ کی جانچ ہم منصب سے چلائیں، فون سے نہیں، اور SSH کلائنٹ کا تفصیلی آؤٹ پٹ پڑھیں کہ یہ TCP ہینڈ شیک سے پہلے یا بعد ناکام ہوتا ہے۔ جو ساکٹ کبھی جڑتا نہیں اور جو لاگ اِن مسترد ہوتا ہے، وہ مختلف مرحلے ہیں جن کے ذمہ دار بھی مختلف ہیں۔

ڈی بگ کرتے وقت ہوسٹ کی تصدیق اور اکاؤنٹ پابندیاں برقرار رکھیں۔ لسنر اور اجازت یافتہ صارفین کو محدود کرنا ہی قابلِ رسائی سرور کو قابلِ قبول بناتا ہے؛ کنکشن چلانے کے لیے اُنہیں ڈھیلا کرنا ایک مسئلے کو بدتر سے بدل دیتا ہے۔ اگر آپ کا اینڈرائیڈ نفاذ وہی کنفیگریشن نام مانتا ہے تو OpenSSH سرور حوالہ سننے اور رسائی کے کنٹرولز کا احاطہ کرتا ہے۔