TAP یا TUN؟ Android OpenVPN کلائنٹس اور پل والے سرورز
TAP ایتھرنیٹ فریم لے جاتا ہے، TUN IP پیکٹ لے جاتا ہے، اور Android ایپ کو صرف دوسری قسم ملتی ہے۔ دونوں کا موازنہ کریں، پھر سرور کی طرف درست کریں۔
لیپ ٹاپ پر چلنے والی پروفائل فون پر ناکام ہو جاتی ہے۔ واضح قدم کلائنٹ کنفیگ میں ایک لفظ بدلنا ہے۔ وہ لفظ مدد نہیں کرے گا، کیونکہ دونوں سرے ایک ہی قسم کی ٹریفک کی بات نہیں کر رہے۔
TAP ایتھرنیٹ فریم لے جاتا ہے۔ TUN IP پیکٹ لے جاتا ہے۔ Android VPN ایپ کو ایک IP انٹرفیس دیا جاتا ہے، جو کنفیگ کچھ بھی کہے، دونوں میں سے ایک ترتیب کو ممکن اور دوسری کو ناممکن بنا دیتا ہے۔
موازنہ مختصر ہے، لیکن یہ طے کرتا ہے کہ آپ اسے فون پر درست کر سکتے ہیں یا سروس بدلنی ہوگی۔
مختلف پے لوڈ والی دو قسم کی ٹنل
TAP انٹرفیس ایتھرنیٹ اڈاپٹر کی طرح برتاؤ کرتا ہے۔ یہ فریم لے جاتا ہے، یعنی ARP، براڈکاسٹ اور ہر وہ چیز جو LAN IP کے نیچے لے جاتا ہے۔ یہی پل بنانا ممکن بناتا ہے: ٹنل براڈکاسٹ ڈومین کو پھیلاتی ہے اور کلائنٹ ایسے برتاؤ کرتے ہیں جیسے وہ سوئچ میں لگے ہوں۔
TUN انٹرفیس اُسے مخاطب کیے گئے IP پیکٹ لے جاتا ہے۔ بات چیت کے لیے کوئی لنک لیئر نہیں، نہ ARP اور نہ براڈکاسٹ۔ ٹنل میں کیا داخل ہوگا یہ روٹنگ طے کرتی ہے، اور سرور کی طرف کا کنفیگ پل کے بجائے سب نیٹ استعمال کرتا ہے۔
دونوں سروں کو متفق ہونا چاہیے کہ وہ ان دو میں سے کون سا کر رہے ہیں۔ ایک طرف dev tap کو dev tun میں بدلنے سے سروس تبدیل نہیں ہوتی؛ روٹ شدہ ٹنل کی توقع کرنے والا کلائنٹ اور اب بھی فریم بھیجنے والا سرور بنتا ہے، اور ہینڈ شیک کامیاب ہو سکتا ہے جبکہ کوئی کارآمد چیز گزر نہیں رہی۔
Android ایپ کو حقیقت میں کیا دیتا ہے
پلیٹ فارم کا VpnService API ایپ کو IP پیکٹ کے لیے ورچوئل انٹرفیس دیتا ہے، جو پتوں، روٹس اور MTU سے کنفیگر ہوتا ہے۔ اُس API میں کوئی ایتھرنیٹ اڈاپٹر نہیں، اور ایپ کے لیے ایک بنانے کا کوئی طریقہ نہیں۔
اسی لیے OpenVPN Connect Android پر TAP پل کے بجائے روٹ شدہ TUN کنکشنز کی معاونت دستاویز کرتا ہے۔ Android عمومی سوالات اس حد کے بارے میں کلائنٹ کی طرف کا بیان ہے، اور یہ پلیٹ فارم API سے مطابقت رکھتا ہے۔
روٹ نیٹ ورکنگ ٹولز، حسب ضرورت فرم ویئر یا واضح ترجمہ لیئر نافذ کرنے والی پروڈکٹ دوسری ترتیبات ہیں۔ عام معاملہ وہی ہے جس کے گرد منصوبہ بندی کرنی چاہیے: ایسی ایپ جو آپ کی فائل درآمد کر سکے اور عام صارف کے طور پر چل سکے، ایک IP انٹرفیس کے ساتھ اور اس کے نیچے کچھ نہیں۔
پھر بھی کوشش کرنے پر کیسا لگتا ہے
کنکشن عام طور پر قائم ہو جاتا ہے۔ یہی ناکامی کو مبہم بناتا ہے: کلائنٹ جڑنے کی اطلاع دیتا ہے، سرور لاگ ایک ساتھی دکھاتا ہے، اور کوئی ایپلیکیشن کام نہیں کرتی۔
فون کو دیے گئے پتے پر بھیجی گئی ٹریفک نہیں پہنچتی، کیونکہ سرور فریم کو ایسے MAC پتے پر پل کرتا ہے جو فون کے پاس کبھی نہیں تھا۔ براڈکاسٹ پر منحصر دریافت خالی رہتی ہے۔ اگر LAN پل کے ذریعے DHCP پر انحصار کرتا ہے، تو فون کو اُس طریقے سے لیز نہیں ملے گی، اور پل شدہ سب نیٹ میں ہاتھ سے دیا گیا پتہ بھی گمشدہ انٹرفیس نہیں بناتا۔
کچھ کلائنٹ پہلے ہی ناکام ہو جاتے ہیں، پروفائل درآمد کے وقت، جب اُنہیں ایسی ڈیوائس قسم ملتی ہے جو وہ نافذ نہیں کر سکتے۔ دونوں برتاؤ ایک ہی بات کہتے ہیں، اور روٹ شامل کرنے، DNS بدلنے یا ٹنل کی پتہ رینج وسیع کرنے سے کوئی بھی درست نہیں ہوتا۔
سرور کی طرف کو کیا بدلنا ہے
اصلاح VPN سروس چلانے والے کی ہے، اور یہ عام طور پر منتقلی نہیں بلکہ اضافہ ہے۔ روٹ شدہ ڈیوائس، اپنے کلائنٹ سب نیٹ اور پتے دے کر فونوں کو درکار روٹس بھیجنے والے سرور کی طرف کے کنفیگ کے ساتھ دوسری OpenVPN مثال چلائیں۔ موجودہ پل شدہ مثال اُن ڈیوائسز کی خدمت جاری رکھتی ہے جنہیں واقعی ایتھرنیٹ چاہیے۔
دو تفصیلیں اسے عملی طور پر چلاتی ہیں۔ نئے کلائنٹ سب نیٹ کے لیے LAN کو VPN ہوسٹ کی طرف اشارہ کرنے والا واپسی روٹ چاہیے، ورنہ جواب کبھی واپس نہیں آئیں گے۔ اور ٹنل ہوسٹ پر فائر وال کو ٹنل انٹرفیس اور LAN کے درمیان فارورڈ کرنا چاہیے، اور یہی وہ قدم ہے جو میزبان ہی سے کی گئی جانچ کامیاب ہونے پر سب سے زیادہ چھوٹتا ہے۔
اگر آپریٹر سروس شامل نہیں کر سکتا، تو متبادل ایسی ڈیوائس ہے جو پل میں شامل ہو سکے، یعنی فون کی جانب سے کام کرنے والا لیپ ٹاپ یا راؤٹر۔ یہ اپنی انتظامی لاگت والا وقتی حل ہے، Android کنفیگ نہیں۔
ٹنل سے نہیں، ایپلیکیشن سے فیصلہ کریں
پوچھیں کہ فون کو حقیقت میں کہاں پہنچنا ہے، پھر اس کا نقشہ بنائیں۔ نام یا پتے سے پہنچنے والی فائل شیئرنگ یا انٹرانیٹ سائٹ IP ضرورت ہے، اور DNS نام حل کرے اور روٹ موجود ہو تو روٹ شدہ ٹنل اُسے پورا کرتی ہے۔ مقامی براڈکاسٹ ڈومین براؤز کرنے والا دریافت ٹول IP ضرورت نہیں، اور کتنی ہی روٹنگ اُسے نہیں بھرے گی۔
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
وہ جدول بھیجنے کی درخواست بھی ہے۔ ایپلیکیشن، اُس کا استعمال کردہ پتہ یا نام، اور یہ کہ آیا وہ دریافت پر منحصر ہے، بتائیں۔ آپریٹر اُس وضاحت پر عمل کر سکتا ہے، جو کسی ایسے فون پر کوئی نہیں کر سکتا جو جڑتا نہ ہو۔
آخر میں، ہر کلائنٹ کو LAN اڈاپٹر کی نقل کرنے پر مجبور کرنے کے بجائے جن ڈیوائسز کو ضرورت ہے اُن کے لیے TAP سروس رکھیں۔ واضح مقاصد والی دو سروسز کی معاونت سب کے لیے آدھا چلنے والی ایک سے آسان ہے۔