پورے کمپیوٹر کے بغیر ایک ایپ کو VPN سے کیسے گزاریں

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

روٹنگ ٹیبل آپ کا پروگرام کیوں نہیں دیکھ سکتا

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

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

ایک ہی منزل اب بھی روٹ ہے، پروگرام کا قاعدہ نہیں۔ macOS پر معمول کا طریقہ یہ ہے کہ "VPN پر ساری ٹریفک بھیجیں" کا نشان ہٹا کر ہوسٹ روٹ شامل کریں: sudo route add -host internal-tuner.example -interface ppp0، جسے پھر اس سے ہٹایا جاتا ہے sudo route delete -host internal-tuner.example -interface ppp0۔ پہلے انٹرفیس کا نام یہاں سے پڑھیں ifconfig، کیونکہ ppp0 صرف ایک مثال ہے۔ ہوسٹ روٹ میں وائلڈ کارڈ کام نہیں کرتے، اس لیے کئی ناموں سے بات کرنے والی سروس کو ہر نام کے لیے ایک اندراج چاہیے، اور قاعدہ مشین کے ہر عمل پر لاگو ہوتا ہے، صرف اس پر نہیں جو آپ کے ذہن میں تھا۔

ساکٹ کو ٹنل کے پتے سے باندھیں

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

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

اعلیٰ سطح کے اوزار یہی خیال پیش کرتے ہیں: curl --interface 10.8.0.2، CURLOPT_INTERFACE PHP میں اور source_address دلیل Python کے HTTP کلائنٹس میں۔ پتہ ٹنل کا ہونا چاہیے، اور یہاں ٹائپنگ کی غلطی عام کنکشن کی خرابی بن کر ناکام ہوتی ہے، روٹنگ کی شکایت نہیں۔ پتے کے بجائے ڈیوائس کے نام سے باندھنا Linux کا استحقاق ہے اور Windows یا macOS میں منتقل نہیں ہوتا، اسی لیے پورٹیبل اسکرپٹس پتہ بھیجتے ہیں۔

Linux: پروگرام کا نام نہیں، مالک ملائیں

کرنل ساکٹ کے مالک صارف کو ملا سکتا ہے، اس لیے ایک مخصوص اکاؤنٹ منتخب کنندہ بن جاتا ہے۔ ٹنل کو اس کی اپنی روٹنگ ٹیبل میں رکھیں اور صرف اسی اکاؤنٹ کی ٹریفک وہاں بھیجیں:

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

یہ صرف اس صورت میں کام کرتا ہے جب ٹنل پہلے سے ڈیفالٹ روٹ نہ ہو۔ کلائنٹ کو --route-nopull کے ساتھ شروع کریں، یا دھکیلے گئے ری ڈائریکٹ کو --pull-filter ignore "redirect-gateway" کے ذریعے OpenVPN 2.4 اور بعد میں فلٹر کریں، پھر ٹیبل کا اندراج خود شامل کریں۔ ورنہ دونوں ڈیفالٹ موجود ہوتے ہیں اور کم ترجیح والا جیت جاتا ہے۔ اس کا دانستہ ورژن یہ ہے کہ ڈیفالٹ روٹ کو ٹنل گیٹ وے کی طرف موڑا جائے، یا یہ ڈسکنکٹ اسکرپٹ سے کیا جائے: یہ ٹنل گرنے پر ٹریفک کو انٹرنیٹ سے دور رکھتا ہے، لیکن یہ ایک کل سوئچ ہے، منتخب کنندہ نہیں، اور تب تک رہتا ہے جب تک کوئی اسے ہٹا نہ دے۔

زیادہ مضبوط ورژن نیٹ ورک نیم اسپیس ہے۔ اسے بنائیں، کلائنٹ کو اندر چلائیں، اور ایپ کو ip netns exec کے ساتھ شروع کریں۔ نیم اسپیس سے باہر کوئی چیز ٹنل انٹرفیس نہیں دیکھتی، اس لیے ایپ اتفاقاً ہوسٹ روٹ پر واپس نہیں جا سکتی۔ قیمت حقیقی ہے: نیم اسپیس کو جسمانی نیٹ ورک تک پہنچنے کے لیے veth جوڑا اور اپنی ریزالور فائل چاہیے، کیونکہ ماؤنٹ نیم اسپیس ہوسٹ کی حل ترتیب شیئر نہیں کرتا۔

ناکامی کے دو طریقے زیادہ تر رساؤ کی وضاحت کرتے ہیں۔ نام کی حل اب بھی ہوسٹ کے ریزالور میں ہوتی ہے، اس لیے استفسار ٹنل سے باہر جاتا ہے چاہے TCP کنکشن اندر جائے۔ اور IPv6 کو اپنا ip -6 rule چاہیے، کیونکہ v4 قاعدہ اسے نہیں ڈھانپتا۔

Windows اور macOS: فائر وال محدود کریں یا پراکسی سونپ دیں

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

macOS وہی منطق مختلف اوزاروں سے اپناتا ہے۔ SSH کے ذریعے پہنچنے والا SOCKS سننے والا سب سے کم مداخلت کا آپشن ہے، کیونکہ ssh -D 1080 user@host ایک مقامی پورٹ بناتا ہے اور صرف وہی ایپس اس راستے سے جاتی ہیں جو اسے استعمال کرنے کے لیے ترتیب دی گئی ہوں۔ ایک pf قاعدہ کسی پروگرام کو صارف یا گروہ کے لحاظ سے بلاک کر سکتا ہے، لیکن پھر بھی صرف اسی پروگرام کے لیے ٹنل نہیں چن سکتا۔ Tunnelblick ڈومین کے لحاظ سے فلٹر ہی نہیں کر سکتا، کیونکہ روٹس پتوں پر کام کرتے ہیں؛ OpenConnect کے صارفین vpn-slice کی طرف جاتے ہیں جب سرور بہت چوڑی سابقہ فہرست دھکیلتا ہے۔

دو حل پلیٹ فارم اوزاروں کی کمی پوری کرتے ہیں۔ براؤزر ایکسٹینشنز جو ڈومین کے لحاظ سے پراکسی بدلتی ہیں "صرف یہ سائٹ" کے لیے عملی جواب ہیں، کیونکہ وہ ایپلیکیشن پرت پر کام کرتی ہیں جہاں نام اب بھی موجود ہیں؛ وہ ایک براؤزر ڈھانپتی ہیں اور کچھ نہیں۔ بھدا طریقہ یہ ہے کہ وینڈر کلائنٹ کو ورچوئل مشین میں چلایا جائے تاکہ مہمان روٹ کی تبدیلی کا مالک ہو جبکہ ہوسٹ اپنا راستہ رکھے، قیمت دو نیٹ ورک اسٹیک کی دیکھ بھال ہے۔

باندھنے کے آپشن کے بغیر اوزاروں کے لیے SOCKS ہاپ

زیادہ تر ایپس کو HTTP یا SOCKS پراکسی کی طرف موڑا جا سکتا ہے چاہے وہ انٹرفیس کے بارے میں کچھ نہ جانتے ہوں۔ SSH کلائنٹ سرور کی طرف کسی تبدیلی کے بغیر ایک فراہم کرتا ہے:

ssh -N -D 127.0.0.1:9999 [email protected]

جو کچھ اس پورٹ کو استعمال کرنے کے لیے ترتیب دیا گیا ہے وہ قلعے پر نکلتا ہے جبکہ باقی ڈیسک ٹاپ اپنا معمول کا کنکشن رکھتا ہے۔ ٹنل کے پتے سے بندھا مقامی 3proxy واقعہ SSH کے بغیر ایک پورٹ کے لیے یہی کرتا ہے، اور stunnel TLS میں لپٹی ایک پورٹ ڈھانپتا ہے۔ حدود عملی ہیں: پراکسی صرف وہی پروٹوکول لے جاتی ہے جو اسے استعمال کرنا جانتے ہوں، UDP کو SOCKS5 UDP وابستگی چاہیے جو بہت سے کلائنٹس کی "SOCKS5" ترتیب فعال نہیں کرتی، اور DNS پراکسی ہی حل کرے (socks5h curl میں) ورنہ نام مقامی ریزالور تک رس جاتا ہے۔

سننے والے کو لوپ بیک پر رکھیں جب تک کسی دوسری مشین کو اس کی ضرورت نہ ہو۔

راستہ کیپچر سے جانچیں، اسٹیٹس پیغام سے نہیں

ایپ کی اسٹیٹس ونڈوز ترتیب بیان کرتی ہیں، پیکٹ نہیں۔ دونوں انٹرفیس پر ٹریفک پکڑیں اور موازنہ کریں:

tcpdump -i any -n port 443
ss -tnp | grep 443

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

پھر وہ حد چنیں جو ضرورت سے مطابقت رکھتی ہے: ایک سائٹ کے لیے پراکسی کافی ہے، ایک اکاؤنٹ کے لیے UID قاعدہ کافی ہے، جب کنکشن کو بند حالت میں ناکام ہونا ہو تو فائر وال پروفائل کافی ہے، اور نیم اسپیس واحد آپشن ہے جو ٹنل کو اس سے باہر سب سے چھپاتا ہے۔