ایپ کی بنیاد پر یا منزل کی بنیاد پر split tunneling: کون سا منتخب کریں

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

دونوں قواعد مختلف تہوں پر عمل کرتے ہیں

ایپ کا قاعدہ نیٹ ورک تہہ کے اوپر، اس شناخت کے خلاف نافذ ہوتا ہے جو آپریٹنگ سسٹم بھیجنے والے کو دیتا ہے۔ Android میں وہ پیکیج کے پیچھے موجود UID ہے، اور VPN سروس ہر UID کے لیے فیصلہ کرتی ہے کہ ٹریفک سرنگ میں داخل ہوتی ہے یا نہیں۔ منزل کے بارے میں کچھ نہیں پوچھا جاتا، اس لیے منتخب کردہ ایپ ہر جگہ پہنچ سکتی ہے اور کوئی دوسری ایپ اندرونی نیٹ ورک تک نہیں پہنچ سکتی۔

منزل کا قاعدہ خود پیکٹ پر نافذ ہوتا ہے۔ سرنگ کا انٹرفیس کچھ سابقے رکھتا ہے، روٹنگ جدول مماثل ٹریفک وہاں بھیجتی ہے، اور بھیجنے والا عمل غیر متعلق ہے۔ اسی لیے منزل کا قاعدہ ایسی سروس، پرنٹر یا بیچ کام کو محیط ہوتا ہے جسے درج کرنے کی کسی کو یاد نہ رہی، اور اسی لیے جس پلیٹ فارم کا کلائنٹ کبھی عمل کی طرف نہیں دیکھتا وہاں اسے صرف یہ پروگرام کہہ کر بیان نہیں کیا جا سکتا۔

ایپ کے قواعد موبائل کلائنٹ اور زیرِ انتظام ایجنٹ کے لیے موزوں ہیں

Android انتخاب براہ راست پیش کرتا ہے: VpnService.Builder.addAllowedApplication() اور addDisallowedApplication() پیکیج کے نام لیتے ہیں اور ہر UID کے لیے فیصلہ نافذ کرتے ہیں، جیسا کہ Android کے VPN ڈویلپر گائیڈ میں بیان کیا گیا ہے۔ iOS میں بنڈل شناخت کنندگان پر مبنی فی ایپ VPN قواعد کے ذریعے مساوی انتظام ہے، جو عام طور پر ہاتھ سے لکھنے کے بجائے MDM پروفائل سے دیا جاتا ہے۔

ڈیسک ٹاپ کلائنٹ کمزور مقام ہیں۔ زیادہ تر Windows اور macOS VPN کلائنٹ منزل کے مطابق روٹ کرتے ہیں اور عمل کے مطابق انتخاب بالکل نہیں دیتے، کیونکہ سرنگ کا ڈرائیور عمل نہیں، پیکٹ دیکھتا ہے۔ اگر آپ کا منصوبہ لیپ ٹاپ پر ایک ایپلیکیشن کو سرنگ کرنے پر منحصر ہے تو اس کے گرد ڈیزائن کرنے سے پہلے کلائنٹ کی حقیقی صلاحیتیں دیکھیں؛ شاید آپ منزل کی فہرست اور دوسری مشین کے درمیان انتخاب کر رہے ہیں۔

وہ نتیجہ جو لوگ چھوڑ دیتے ہیں: ان پلیٹ فارمز پر روٹ کے ذریعے ایپ قاعدے کی نقل نہیں کی جا سکتی۔ ایپ کے سرور کے لیے میزبان روٹ شامل کرنے سے سب کا ٹریفک اسی سرور کی طرف سرنگ ہو جاتا ہے، براؤزر اور اپ ڈیٹر سمیت۔

منزل کے قواعد سب نیٹ فہرستوں اور سائٹ کی رسائی کے لیے موزوں ہیں

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

OpenVPN دھکیلی گئی روٹنگ جدول کے ذریعے اسی مقام تک پہنچتا ہے۔ route-nopull سرور کو روٹ دکھانے سے روکتا ہے، اس کے بعد کلائنٹ کی طرف route 10.20.0.0 255.255.0.0 vpn_gateway بالکل دفتری سابقے کو محیط ہوتا ہے۔ IPv6 ان میں سے ہر کلائنٹ میں الگ بیان ہے، اور اسے بھول جانا صحیح دکھنے والی IPv4 تقسیم کے گرد لیک ہونے کا سب سے عام طریقہ ہے۔

میزبان نام روٹ نہیں ہے۔ اگر پروفائل ڈومین فیلڈ دیتا ہے تو اسے ایسے نام کے طور پر لیں جسے کلائنٹ ایک بار حل کرتا ہے، مستقل پتہ رینج کے طور پر نہیں؛ مواد کی ترسیل کے نیٹ ورک اور لوڈ بیلنسر کل مختلف پتے دیں گے۔

دونوں ماڈل کہاں ٹوٹتے ہیں: مددگار، مشترکہ سروسز، حل کنندگان

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

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

حل کنندگان دونوں کو کاٹتے ہیں۔ اگر کلائنٹ اندرونی DNS سرور مقرر کرے لیکن آپریٹنگ سسٹم عوامی حل کنندہ کی طرف HTTPS پر DNS استعمال کرے تو جواب سرنگ سے باہر سے آتا ہے اور منزل کا قاعدہ کبھی نہ مل سکے۔ قاعدہ غلط ہے کا نتیجہ اخذ کرنے سے پہلے دیکھیں کہ کس حل کنندہ نے واقعی جواب دیا، اور کلائنٹ کی طرف تصدیق کریں کہ اس نے سرنگ کا حل کنندہ نصب کیا بھی یا نہیں۔ DNS کو سرنگ سے باہر چھوڑنے والی تقسیم روٹنگ جدول میں بے عیب دکھتی ہے اور پھر بھی ہر اندرونی نام پر ناکام ہوتی ہے۔

طریقہ کار: منتخب کریں، لاگو کریں، تصدیق کریں

مینو سے نہیں، ضرورت سے شروع کریں۔ اگر مقصد یہ ہے کہ صرف یہ ایپ سرنگ استعمال کر سکے تو ایپ قواعد اور ان کی حمایت کرنے والا پلیٹ فارم درکار ہے۔ اگر مقصد یہ ہے کہ یہ نیٹ ورک سرنگ کے ذریعے قابلِ رسائی ہوں تو سابقے درکار ہیں۔ اگر جواب دونوں ہے تو انہیں دو الگ کنٹرول کے طور پر نافذ کریں اور لکھیں کہ کون کس ناکامی کا ذمہ دار ہے۔

جو سب سے تنگ شکل آپ بیان کر سکتے ہیں اسے لاگو کریں، پھر کلائنٹ کے اسٹیٹس آئیکن کے بجائے روٹنگ جدول سے پوچھ کر تصدیق کریں:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

پہلی دو سطریں اس انٹرفیس کا نام دیتی ہیں جو حقیقی منزل استعمال کرے گی؛ wg show ترتیب شدہ سابقہ فہرست چھاپتا ہے؛ Windows پر Find-NetRoute اسی سوال کا جواب دیتا ہے جو پیکٹ بھیجتے وقت اسٹیک دے گا۔ اگر انٹرفیس سرنگ ہے تو قاعدہ مل گیا۔

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