کیسے VPN کے ذریعے صرف ایک نجی ذیلی نیٹ بھیجا جائے

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

ڈیزائن طے کرنے والی تین شرطیں

پہلے، آپ کو نیٹ ورک کے مالک سے درست سابقہ اور ماسک چاہیے۔ 10.x نیٹ ورک سابقہ نہیں ہے؛ 10.20.0.0/16 سابقہ ہے۔ یقینی بنائیں کہ یہ آپ کے گھریلو LAN، Docker پل یا آپ کے چلائے گئے کسی دوسرے VPN سے متصل نہیں ہوتا، کیونکہ اتصال راستہ کو مبہم کر دیتا ہے اور کرنل وہ اندراج چن لیتا ہے جو آپ کا مقصود نہیں تھا۔

دوسرے، واپس آنے والے ٹریفک کا جواب کون دیتا ہے۔ پیکٹ کو سرنگ میں بھیجنا اسے صرف VPN سرور تک پہنچاتا ہے۔ اگر ذیلی نیٹ کسی ایسے دوسرے راؤٹر کے پیچھے ہے جس کے پاس آپ کے کلائنٹ تالاب تک واپسی کا راستہ نہیں، تو سرور کو ٹریفک ماسک کرنا ہوگا، یا اس راؤٹر کو آپ کا تالاب سیکھنا ہوگا۔ کلائنٹ کی طرف کا کوئی راستہ غائب واپسی راستے کو درست نہیں کرتا۔

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

WireGuard: AllowedIPs ہی راستہ جدول ہے

کلائنٹ پر، AllowedIPs ان منزلوں کی فہرست دیتا ہے جنہیں سرنگ میں داخل ہونے کی اجازت ہے، اور wg-quick ہر اندراج کو عام راستہ بنا دیتا ہے۔ اس لیے اس کام کا کلائنٹ آدھا حصہ ایک سطر ہے۔

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

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

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

ان دونوں کو بدلنا وہ غلطی ہے جو میں سب سے زیادہ دیکھتا ہوں۔ سرور کے peer حصے کے نیچے 10.20.0.0/16 رکھنا کہتا ہے کہ پورا ذیلی نیٹ اس کلائنٹ کے پیچھے ہے، اور یہ سائٹ سے سائٹ کا دعویٰ ہے، اجازت نہیں۔ جو پیکٹ کسی بھی peer کے AllowedIPs سے نہیں ملتے وہ خاموشی سے پھینک دیے جاتے ہیں، اس لیے غلط اندراج بالکل فائر وال مسئلے جیسا لگتا ہے۔

اگر آپ خود راستے سنبھالتے ہیں، تو [Interface] کے نیچے Table = off مقرر کریں اور مطلوبہ راستہ شامل کریں۔ پھر کچھ بھی خودبخود شامل نہیں ہوتا، اس لیے راستہ اسی چیز میں ہونا چاہیے جو انٹرفیس کو اوپر اٹھاتی ہے۔

OpenVPN: راستہ دھکیلیں، پھر یقینی بنائیں کہ وہ پہنچتا ہے

عام سرور پر تبدیلی سرور ترتیب میں کلائنٹ تالاب کے ساتھ ایک ہدایت ہے۔

push "route 10.20.0.0 255.255.0.0"

کلائنٹ جڑتے وقت اسے شامل کرتا ہے۔ ناکامی کا طریقہ تب ظاہر ہوتا ہے جب وہی پروفائل redirect-gateway بھی دھکیلے، یا جب کسی نے پہلے ہی route-nopull شامل کر دیا ہو: پہلا سیشن کو مکمل سرنگ بنا دیتا ہے، اور دوسرا آپ کے سمیت ہر دھکیلے گئے راستے کو پھینک دیتا ہے۔

مکمل سرنگ والے سرور کے سامنے تنگ رویہ درکار کلائنٹ کو صرف وہ حصے نظرانداز کرنے چاہئیں جو اسے نہیں چاہیے۔ OpenVPN 2.4 اور بعد کے نسخوں میں، pull-filter بالکل اسی کے لیے موجود ہے۔

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

پتوں کے خاندان الگ رکھیں: دھکیلا گیا IPv4 راستہ IPv6 میں حل ہونے والی داخلی خدمت کے لیے کچھ نہیں کرتا، اور وہ خدمت سرنگ کے ذریعے ناکام ہوتی ہے جبکہ باقی سب ٹھیک دکھتا ہے۔

جب نجی ذیلی نیٹ VPN سرور پر نہ ہو بلکہ کسی دوسرے کلائنٹ کے پیچھے ہو، تو سرور کو بتانا پڑتا ہے۔ client-config-dir کے ذریعے ہر کلائنٹ کے لیے iroute 10.20.0.0 255.255.0.0 پر مشتمل فائل شامل کریں، ساتھ ملتا ہوا route بھی تاکہ دوسرے کلائنٹ راستہ سیکھیں۔ iroute کے بغیر سرور کے پاس وہ سابقہ بالکل اسی سرنگ سے بھیجنے کی کوئی وجہ نہیں۔

IPsec: ٹریفک منتخب کنندگان کا متفق ہونا ضروری ہے

IPsec میں دھکیلنے کے لیے کوئی راستہ نہیں۔ دونوں سرے طے کرتے ہیں کہ سرنگ کے اندر کون سے پتے ہیں، اور متفقہ منتخب کنندگان سے باہر کا ٹریفک نہ خفیہ ہوتا ہے نہ اس سے گزرتا ہے۔ strongSwan کلائنٹ پر منتخب کنندگان واضح ہوتے ہیں۔

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

اگر گٹ وے دونوں طرف 0.0.0.0/0 کے ساتھ تشکیل شدہ ہو، تو IKEv2 کی تنگی عام طور پر چائلڈ SA کو دونوں تجاویز کے تقاطع تک کم کر دیتی ہے، جو مطلوبہ نتیجہ ہے۔ کچھ گٹ وے اس کے بجائے ایسی تجویز مسترد کر دیتے ہیں جو ان کے تشکیل شدہ منتخب کنندگان سے مطابقت نہیں رکھتی، اور لاگ تب راستہ شکایت کے بجائے ناکام چائلڈ SA دکھاتا ہے۔ جب ایسا ہو تو تبدیلی گٹ وے کی ہے، کیونکہ کلائنٹ راستہ ایسے منتخب کنندہ کے لیے سرنگ نہیں بنا سکتا جسے دوسرا فریق قبول نہ کرے۔

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

سابقہ رجسٹر کرنا ہی اسے دوبارہ جڑنے کے بعد بھی برقرار رکھتا ہے، جو ہاتھ سے شامل کردہ راستہ نہیں کرتا۔

اینڈ پوائنٹ اور DNS کو فیصلے سے باہر رکھیں

VPN اینڈ پوائنٹ سرنگ کے بغیر قابل رسائی رہنا چاہیے، ورنہ سرنگ اپنے اندر ہی ڈھیر ہو جاتی ہے۔ جب صرف 10.20.0.0/16 کا راستہ بنتا ہے تو یہ خودکار ہے، کیونکہ اینڈ پوائنٹ عوامی پتہ ہے۔ مکمل سرنگ پروفائل میں ایسا نہیں، اور سرنگ چڑھنے سے پہلے کلائنٹ کو اینڈ پوائنٹ تک واضح ہوسٹ راستہ درکار ہے۔

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

جانچیں، پھر ری بوٹ کریں اور دوبارہ جانچیں

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

پہلی سطر کسی انٹرفیس کا نام لیتی ہے۔ اگر وہ آپ کے طبعی انٹرفیس کا نام لے، تو راستہ کبھی پہنچا ہی نہیں۔ Windows پر Find-NetRoute -RemoteIPAddress 10.20.5.7 اسی سوال کا جواب دیتا ہے، اور آخری جانچ میں اب بھی آپ کا معمول کا پتہ دکھنا چاہیے، VPN سرور کا نہیں۔

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

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