Android always-on VPN: اینڈ پوائنٹ کا نام پہلے کیسے حل ہوتا ہے
Android ٹنل وجود میں آنے سے پہلے ہی ٹریفک روکتا ہے، پھر بھی کلائنٹ کو اپنا اینڈ پوائنٹ حل کرنا پڑتا ہے۔ یہ ہے ترتیب اور وہ جگہ جہاں یہ اٹک جاتا ہے۔
فون دوبارہ بوٹ ہوتا ہے، always-on فعال ہے، «VPN کے بغیر کنکشن روکیں» آن ہے، اور ٹنل کبھی نہیں آتا۔ کچھ بھی غلط کنفیگر نہیں: روک کام کر رہی ہے، اور کلائنٹ کی اپنی کوشش کہ وہ اپنے اینڈ پوائنٹ تک پہنچے، بھی اسی کے تابع ہے۔ اینڈ پوائنٹ کا نام ٹنل وجود میں آنے سے پہلے حل ہونا چاہیے، ایسے کلائنٹ کے ذریعے جسے نیٹ ورک سے بات کرنے کی اجازت ہے جبکہ باقی تمام ایپس کو نہیں۔ یہ سمجھنا کہ کون سا جزو یہ کرتا ہے اور کس ترتیب سے، اسی معمے کو کنفیگریشن کے سوال میں بدل دیتا ہے۔
VPN بنانے والا اصل میں کیا مانگتا ہے
Android VPN ایپ پلیٹ فارم کو سرور کا پتہ نہیں دیتی۔ یہ ایک مقامی انٹرفیس بناتی ہے: ٹنل کے لیے پتے اور راستے، وہ حل کنندہ جو ایپس کو اس کے اندر استعمال کرنے چاہئیں، اور پھر establish() ایک فائل ڈسکرپٹر واپس کرتا ہے جسے ایپ خام IP پیکٹوں کے طور پر پڑھتی اور لکھتی ہے۔ دور کا اینڈ پوائنٹ اُس بنانے والے میں بالکل نظر نہیں آتا۔
یہی بنیادی ساختی حقیقت ہے۔ پلیٹ فارم tun انٹرفیس بناتا ہے اور اُس پر پالیسی نافذ کرتا ہے؛ ایپ صارف کی جگہ میں ٹرانسپورٹ نافذ کرتی ہے، یعنی اینڈ پوائنٹ کا نام خود حل کرتی ہے اور خفیہ کردہ کنکشن خود کھولتی ہے۔ اس لیے ہوسٹ نام کی صورت میں اینڈ پوائنٹ ممکن ہے — اس لیے نہیں کہ پلیٹ فارم ناموں کی حمایت کرتا ہے، بلکہ اس لیے کہ پلیٹ فارم اینڈ پوائنٹ کو کبھی نہیں دیکھتا۔
بنانے والے کا ایک فیلڈ پھر بھی پتے لیتا ہے: DNS سرورز۔ یہ عددی حل کنندہ پتے ہونے چاہئیں، عام طور پر وہی جنہیں آپریٹر ٹنل کے ذریعے پوچھنا چاہتا ہے۔ وہ فیلڈ بتاتا ہے کہ ٹنل آنے کے بعد ایپس سوالات کہاں بھیجتی ہیں۔ یہ نہیں بتاتا کہ کلائنٹ اینڈ پوائنٹ کیسے ڈھونڈتا ہے، اور ان دونوں کو ایک ہی سیٹنگ سمجھنا ہی الجھن کا آغاز ہے۔
ایک نہیں، دو DNS سوال
پہلا سوال یہ ہے: ٹنل آنے کے بعد ایپس سوالات کہاں بھیجتی ہیں؟ جواب ٹنل کے اندر حل کنندہ کا پتہ ہے، tun انٹرفیس کے ذریعے قابل رسائی، اور ساخت کے لحاظ سے عددی۔
دوسرا سوال یہ ہے: اُس ٹنل کے وجود میں آنے سے پہلے کلائنٹ اپنا اینڈ پوائنٹ کیسے ڈھونڈتا ہے؟ وہ تلاش ٹنل سے باہر، بنیادی نیٹ ورک پر، کلائنٹ کے عمل میں ہوتی ہے۔ یہ نام استعمال کر سکتی ہے، اور ایسا حل کنندہ استعمال کرنا ضروری ہے جس تک آلہ VPN کے بغیر پہنچ سکے۔
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
تین مراحل، تین مختلف علامات۔ «کنیکٹ نہیں ہو سکتا» کا ایک ہی غلطی پیغام انہیں یکجا کر دیتا ہے، اور اسی لیے لوگ اُس فیلڈ کے پڑھے جانے سے پہلے ہونے والے مسئلے کو درست کرنے کے لیے DNS سرور فیلڈ میں ترمیم کرنے لگتے ہیں۔
bootstrap کیوں اٹک سکتا ہے
always-on میں روک فعال ہونے کا مطلب ہے کہ VPN کے اندر نہ ہونے والی ٹریفک رد کر دی جاتی ہے، بشمول اُس ایپ کی ٹریفک جس کے پاس VPN ہے۔ نکلنے کا راستہ واضح ہے: ایپ ساکٹ پر protect() بلاتی ہے، جو اسے بنیادی نیٹ ورک سے باندھتا ہے تاکہ یہ ٹنل سے گزر کر باہر جا سکے۔ ہر VPN کلائنٹ کو اپنی ٹرانسپورٹ کے لیے یہ کرنا ضروری ہے، ورنہ وہ کبھی سرور تک نہیں پہنچے گا۔
اب ایسی تعیناتی کا تصور کریں جہاں اینڈ پوائنٹ کا نام جاننے والا واحد حل کنندہ خود ٹنل کے اندر ہے۔ کلائنٹ کو نام حل کرنے کے لیے ٹنل درکار ہے، اور ٹنل بنانے کے لیے نام درکار ہے۔ یہ حقیقی دائروی انحصار ہے، اور کوئی کلائنٹ کنفیگریشن اسے حل نہیں کرتی۔ یہ ڈیزائن کی غلطی ہے، بگ نہیں۔
وقت اسی انحصار کو ہلکی صورتوں میں بے نقاب کرتا ہے۔ بوٹ کے وقت، پہلی ان لاک سے پہلے، آلے کے پاس ابھی قابل استعمال نیٹ ورک نہ ہو؛ captive portal پر نیٹ ورک موجود ہے مگر پورٹل کے سوا سب کچھ روکتا ہے؛ Wi-Fi سے موبائل نیٹ ورک پر منتقلی میں محفوظ ساکٹ کا بنیادی نیٹ ورک بدل جاتا ہے اور کلائنٹ کو یہ نوٹ کر کے دوبارہ حل کرنا ہوتا ہے۔ ان میں سے ہر ایک bootstrap واقعہ ہے، اور ہر ایک کو رات 3 بجے دریافت کرنے کے بجائے دانستہ جانچنا چاہیے۔
جواب کو مستقل کرنا حل کیوں نہیں
آسانی کا راستہ یہ ہے کہ نام ایک بار حل کیا جائے اور حاصل شدہ پتہ عددی فیلڈ میں چپکا دیا جائے، یا کسی حسب ضرورت بلڈ میں سخت کوڈ کر دیا جائے۔ یہ کام کرتا دکھتا ہے، اور نام کو تصویر بنا دیتا ہے۔ جب آپریٹر اینڈ پوائنٹ کو منتقل کرتا ہے — منتقلی، anycast تبدیلی، نیا علاقائی پتہ — کلائنٹ پرانے کو ہی کال کرتا رہتا ہے اور UI میں کہیں کوئی وجہ بیان نہیں ہوتی۔
DNS ریکارڈز میں عمر ہونے کی وجہ یہی ہے کہ جواب بدل سکیں؛ کیشنگ اسی مدت کی بنیاد پر متعین ہوتی ہے، ہمیشہ کے لیے نہیں۔ جواب کو مستقل کرنا اُس طریقہ کار کو پھینک دیتا ہے جو نام کو پتے سے بہتر بناتا ہے، جبکہ نام استعمال کرنے کی آپریشنل لاگت برقرار رہتی ہے۔
مستقل کرنا عموماً دوسری بری عادت کے ساتھ آتا ہے: شناخت کی جانچ ڈھیلی کرنا کیونکہ کنکشن اب مختلف طریقے سے ناکام ہوتا ہے۔ سرور کی شناخت کی تصدیق bootstrap مسئلے کا حصہ نہیں، اور اسے کمزور کرنا DNS کی تکلیف کو مداخلت کے خطرے سے بدل دیتا ہے۔
وہ ڈیزائن جو دوبارہ بوٹ کو برداشت کریں
پائیدار ترتیب کوئی پرکشش نہیں۔ ایسا کلائنٹ استعمال کریں جو محفوظ ساکٹ صحیح طریقے سے نافذ کرے اور اپنا اینڈ پوائنٹ بنیادی نیٹ ورک پر حل کرے، اور اسے ایسا اینڈ پوائنٹ نام دیں جو عوامی طور پر یا ٹنل سے پہلے قابل رسائی حل کنندہ کے ذریعے حل ہو۔ روک فعال رکھیں؛ DNS کے کام کرنے کے لیے اسے مکمل بند کرنا وہ خصوصیت ہٹا دیتا ہے جس کے لیے تعیناتی ہے۔
جہاں اینڈ پوائنٹ نجی رہنا چاہیے، وہاں واضح bootstrap راستہ فراہم کریں جو پلیٹ فارم استعمال کر سکے — ٹنل کے بغیر قابل رسائی حل کنندہ، یا آپریٹر کے زیر انتظام رابطہ — اور اس استثنا کو تنگ رکھیں اور پالیسی کی ملکیت میں، صارف کے ٹوگل کی نہیں۔ Android VpnService کی دستاویزات اس بات کی حوالہ ہیں کہ پلیٹ فارم تحفظ اور زندگی کے دورانیے کے بارے میں کیا ضمانت دیتا ہے، اور VpnService.Builder کا حوالہ تصدیق کرتا ہے کہ DNS فیلڈ عددی پتے لیتی ہے۔
پھر دوبارہ بوٹ کے بعد نئے کنکشن پر تینوں مراحل ترتیب سے جانچیں: اینڈ پوائنٹ کا نام حل ہوتا ہے، ٹنل قائم ہوتا ہے اور ساتھی کی تصدیق ہوتی ہے، اور نجی نام ٹنل کے حل کنندہ کے ذریعے حل ہوتا ہے۔ اگر پہلا مرحلہ ناکام ہو تو آگے کچھ بھی کام نہیں کر سکتا، اور اصلاح bootstrap راستے کی ہے — کبھی حل کنندہ فیلڈ کی نہیں۔
- اینڈ پوائنٹ کا حل ایپ کے اندر، ٹنل سے باہر، محفوظ ساکٹ پر ہوتا ہے۔
- بنانے والے کی DNS فیلڈ ٹنل کے اندر کی ایپس کے لیے ہے، کلائنٹ کے اپنے اینڈ پوائنٹ کے لیے نہیں۔
- صرف ٹنل کے ذریعے قابل رسائی حل کنندہ اٹکاؤ ہے، سست آغاز نہیں۔
- دوبارہ بوٹ کے بعد اینڈ پوائنٹ، تصدیق اور نجی تلاش الگ الگ جانچیں۔