روٹر VPN سے ایک ڈیوائس گزارنے کے لیے ٹوگل نہیں، تین اصول درکار ہیں

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

افسانہ: ٹنل کلائنٹ کی سیٹنگ ہے

روٹر کی طرف کا VPN کلائنٹ ایک بھدا کام اچھی طرح کرتا ہے: وہ 0.0.0.0/0 کو مرکزی روٹنگ جدول میں رکھتا ہے اور اسے ٹنل کی طرف موڑ دیتا ہے۔ WireGuard یہ AllowedIPs سے لیتا ہے، OpenVPN اور سرور کی دھکیلی ہوئی redirect-gateway سے لیتا ہے، اور دونوں روٹر کے پیچھے ہر ہوسٹ کا راستہ بدل دیتے ہیں۔ AllowedIPs تنگ کرنا یا route-nopull شامل کرنا یہ بدلتا ہے کہ کلائنٹ کیا نصب کرتا ہے۔ یہ نہیں بدلتا کہ وہ تنصیب کس پر لاگو ہوتی ہے، کیونکہ کلائنٹ کبھی ڈیوائسیں نہیں دیکھتا۔ وہ صرف پیکٹ دیکھتا ہے۔

ماخذ یا منزل کے لحاظ سے انتخاب روٹنگ کا فیصلہ ہے، اس لیے یہ روٹر کی پالیسی تہہ سے تعلق رکھتا ہے: RouterOS پر mangle قاعدہ اور دوسرا جدول، OpenWrt یا DD-WRT پر MARK اور ip rule، یا pfSense پر وہ فائر وال قاعدہ جس کا گیٹ وے ٹنل ہے۔ Netgate کی WireGuard کلائنٹ ترکیب وہ چیز ہے جو اندازہ لگانے سے پہلے پڑھنی چاہیے، کیونکہ اس پلیٹ فارم پر قاعدے کا گیٹ وے، انٹرفیس کی تخصیص اور باہر جانے والا NAT اندراج سب کو متفق ہونا پڑتا ہے، اس سے پہلے کہ ایک بھی کلائنٹ ٹنل استعمال کرے۔

افسانے کا دوسرا نصف دوسرا روٹر ہے۔ دوسرا باکس خریدنا، یا ڈیوائس کو مہمان SSID پر منتقل کرنا اکثر کام کرتا ہے، اور وجہ ہارڈ ویئر نہیں: یہ ڈیوائس کو اس کے اپنے سب نیٹ میں رکھتا ہے، جو آپ کو وہ ماخذ منتخب کرنے والا دیتا ہے جو فرم ویئر پہلے ہی سمجھتا ہے۔ اگر آپ اپنے روٹر پر وہ سیگمنٹ متعین کر سکیں، تو اضافی باکس ایسا مسئلہ حل کرتا ہے جو آپ کے پاس نہیں تھا۔

پہلا حصہ: وہ ٹنل جو ڈیفالٹ روٹ نہیں

RouterOS پر کلائنٹ کو ڈیفالٹ روٹ کے بغیر شامل کریں اور ٹنل کو اس کا اپنا جدول دیں۔ پہلا روٹ نشان زدہ ڈیفالٹ ہے؛ دوسرا ناکامی کا نصف ہے۔

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

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

RouterOS 7 ان چیزوں کو الگ کرتا ہے جو 6.x نے ساتھ رکھی تھیں: آپ جدول کا اعلان /routing table add name=vpn fib سے کرتے ہیں، پھر روٹ پر اور mangle قاعدے میں نام سے حوالہ دیتے ہیں۔ وہ 6.x ٹکڑا جو جدول متعین کیے بغیر routing-mark لکھتا ہے صاف لوڈ ہوتا ہے اور کسی چیز سے نہیں ملتا۔ دوسری کلاسک صورت دو 0.0.0.0/1 نصف ہیں، یا ایک ہی جدول میں ایک ہی فاصلے پر دو ڈیفالٹ: کرنل ایک منتخب کرتا ہے، اور دوبارہ آغاز کے بعد رویہ بدل سکتا ہے۔

دوسرا حصہ: روٹ کی تلاش سے پہلے نشان لگائیں

منتخب کنندہ فیصلہ کرتا ہے کہ کون سے پیکٹ اس جدول میں داخل ہوں گے۔ RouterOS عام طور پر منزل کی پالیسی کے لیے ایڈریس فہرست سے، یا ڈیوائس کی پالیسی کے لیے ماخذ ایڈریس سے شروع کرتا ہے:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

لینکس فرم ویئر بھی یہی کام netfilter مارک اور اس قاعدے سے کرتا ہے جو نشان زدہ پیکٹ آپ کے بھرے ہوئے جدول کی طرف لے جاتا ہے:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

چین انداز کا انتخاب نہیں ہے۔ جب پیکٹ FORWARD تک پہنچتا ہے تو روٹ کی تلاش پہلے ہو چکی ہوتی ہے، اس لیے وہاں MARK یا DROP صرف دوبارہ لکھ سکتا ہے یا رد کر سکتا ہے۔ مارک PREROUTING میں آگے بھیجے جانے والے ٹریفک کے لیے اور OUTPUT میں اس ٹریفک کے لیے گرنا چاہیے جو روٹر خود بناتا ہے، جہاں روٹر کے DNS، NTP اور اپ ڈیٹ جانچ رہتی ہیں۔ وہی اخراجی راستہ وہ عام وجہ ہے کہ مکمل طور پر ٹنل شدہ ترتیب لیک ٹیسٹ میں پھر بھی ISP ریزالور سے جواب دیتی ہے۔

ڈیوائس پالیسی کو ایسی مطابقت چاہیے جو پھسلے نہیں۔ DHCP میں ایڈریس مخصوص کریں، یا مخصوص سیگمنٹ کے لیے انٹرفیس ملائیں؛ وہ ایڈریس جو بعد میں دوسری ڈیوائس پر جائے خاموشی سے غلط کلائنٹ پر ٹنل لاگو کرتا ہے۔ اپنے سب نیٹ والا ہر SSID پل اسی خیال کا زیادہ پائیدار روپ ہے، اور یہ IPv6 قواعد کو بھی رہنے کی جگہ دیتا ہے۔

تیسرا حصہ: NAT، DNS اور LAN استثنا

ٹنل سے باہر جانے والے ٹریفک کو وہ ماخذ ایڈریس چاہیے جس کا دوسرا سرا جواب دے۔ ترجمے کو ٹنل انٹرفیس تک محدود کریں: RouterOS پر out-interface=VPN_NAME، لینکس پر -o tun0، pfSense پر مطابق باہر جانے والا NAT اندراج۔ اس حد کے بغیر masquerade قاعدہ وہ ٹریفک بھی دوبارہ لکھتا ہے جسے آپ چھوڑنا چاہتے تھے، اور علامت یہ ہے کہ ٹنل سے باہر ڈیوائس اپنا عوامی ایڈریس کھو دیتی ہے۔

LAN استثنا خود ٹنل سے زیادہ معاونتی موضوعات پیدا کرتا ہے۔ اگر نشان زدہ جدول میں صرف ڈیفالٹ روٹ ہو، تو منتخب ڈیوائس سے پرنٹر یا NAS کی منزل اس ڈیفالٹ سے مل جاتی ہے اور ٹنل میں غائب ہو جاتی ہے۔ اسی جدول میں LAN روٹ شامل کریں، یا منتخب کنندہ میں مقامی سب نیٹ خارج کریں؛ دونوں کام کرتے ہیں، اور بعد میں VLAN شامل کرنے پر خارج کرنا درست رکھنا آسان ہے۔

DNS الگ راستہ لیتا ہے۔ روٹر جو استفسارات آگے بھیجتا ہے وہ روٹر سے پیدا ہوتے ہیں اور OUTPUT کی پیروی کرتے ہیں، بھیجے گئے مارک کی نہیں، اس لیے مکمل طور پر ٹنل شدہ لیپ ٹاپ بھی ISP کے ذریعے نام حل کر سکتا ہے۔ کلائنٹ کو ایسے ریزالور کی طرف موڑیں جو ٹنل کے ذریعے قابل رسائی ہو، یا خود روٹر کے port-53 ٹریفک کو نشان زد کریں، پھر یہ ماننے کے بجائے کہ جواب ویب درخواست کے ساتھ سفر کیا، حل شدہ ایڈریس جانچیں۔

جب قاعدہ ملتا ہے مگر ایپ پھر بھی WAN استعمال کرتی ہے

منزل کی فہرستیں جلدی پرانی ہو جاتی ہیں۔ کوئی نام ایسے ایڈریس پر حل ہوتا ہے جو فہرست میں نہیں، اس لیے درخواست WAN اختیار کرتی ہے، جبکہ فہرست والے ایڈریس پر آپ کا ہر ٹیسٹ کام کر رہا تھا۔ فہرست کو اسی ریزالور سے تازہ کریں جو کلائنٹ استعمال کرتا ہے، اور جب واقعی ایک ڈیوائس سے سارا ٹریفک چاہیے ہو تو ماخذ پر مبنی منتخب کنندہ کو ترجیح دیں۔

IPv6 خاموش گریز ہے۔ ڈیوائس میں دوسرا ایڈریس خاندان ہے جس کا اپنا ڈیفالٹ روٹ اور اپنا قواعد مجموعہ ہے، اور صرف IPv4 ایڈریس سے مطابقت پالیسی کا آدھا حصہ ہے۔ وہی منتخب کنندہ ip6tables یا nftables کے مساوی پر لاگو کریں، یا اس سیگمنٹ میں IPv6 کو حادثے سے نہیں بلکہ جان بوجھ کر بند کریں۔

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

دو ڈیوائس اور ایک ری بوٹ سے تصدیق کریں

اس ڈیوائس کو آزمائیں جو ٹنل میں ہونی چاہیے اور اسے جو نہیں ہونی چاہیے، اور رفتار کے عدد کی بجائے دوسرے ہاپ کا موازنہ کریں۔ ہر ایک سے traceroute دوسرے ہاپ پر ٹنل کا گیٹ وے یا ISP کا گیٹ وے دکھاتا ہے؛ اگر دونوں ایک جیسے لگیں تو مارک یا جدول قاعدے کے مطابق کام نہیں کر رہے۔ ٹیسٹ کے لیے نئے کنکشن استعمال کریں۔

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

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