ایک LAN ذیلی نیٹ ورک کو OpenVPN سے گزارو اور طے شدہ راستہ رکھو
LAN کا طے شدہ راستہ رکھو جب ایک ذیلی نیٹ ورک سرنگ سے گزرتا ہے۔ پالیسی جدول کا مرکزی جدول کی تبدیلیوں سے موازنہ کرو، پھر NAT یا سرور کی طرف راستہ چنو۔
وہ آلات جو LAN کے لیے راستہ بناتے ہیں اور ساتھ ہی VPN ڈائل کرتے ہیں، اپنے آپ سے اسی بحث میں پھنس جاتے ہیں: سرنگ طے شدہ راستے کی ملکیت چاہتی ہے، اور LAN کو وہ واپس چاہیے۔ جب OpenVPN جڑتا ہے تو یہ سرنگ کے ذریعے ایک طے شدہ یا دو ادھورے طے شدہ راستے بٹھا سکتا ہے، جو لیپ ٹاپ کے لیے درست اور ایسے گیٹ وے کے لیے غلط ہے جس کے پڑوسی اس کے LAN پتے سے جواب کی توقع کرتے ہیں۔ جواب VPN چھوڑ دینا نہیں ہے۔ جواب یہ ہے کہ دونوں فیصلوں کو الگ الگ جدولیں دی جائیں۔
ایک طے شدہ راستہ، دو مالک
آگے بھیجا گیا ٹریفک اور مقامی طور پر پیدا ہونے والا ٹریفک ایک ہی راستہ نہیں لینا پڑتا۔ LAN کلائنٹس کو سرنگ صرف اُن منزلوں کے لیے درکار ہے جو آپ چنتے ہیں، جبکہ میزبان کے اپنے انتظامی سیشن اور اُن کلائنٹس کو اس کے جوابات کو LAN کا طے شدہ راستہ درکار ہے۔ دونوں کو مرکزی جدول میں ملانا دو مختلف سوالوں پر ایک ہی جواب مسلط کرتا ہے۔
OpenVPN میں ٹھیک اسی کے لیے ایک سوئچ ہے۔ route-noexec کلائنٹ کو مرکزی جدول چھونے ہی سے روکتا ہے، اور جو اقدار وہ استعمال کرتا، وہ route-up اسکرپٹ میں route_vpn_gateway، dev اور انٹرفیس کے پتوں کے طور پر بھیج دی جاتی ہیں۔ پھر آپ طے کرتے ہیں کہ کون سی جدول کون سا راستہ لے گی، ایسے کوڈ میں جو بعد میں پڑھا جا سکے۔
پالیسی جدول بمقابلہ مرکزی جدول کو دوبارہ لکھنا
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
الگ جدول ہی واحد آپشن ہے جو ایک ذیلی نیٹ ورک سے آگے بڑھتا ہے۔ اسے ایک بار نام دو، پھر نام سے ہی حوالہ دو تاکہ کسی کو کوئی عدد یاد نہ رکھنا پڑے:
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnیہاں کے پتے عارضی ہیں۔ کچھ بھی چلانے سے پہلے اپنی تنصیب سے LAN پری فکس، سرنگ کا گیٹ وے اور ڈیوائس کا نام بدلو۔
قاعدہ میزبان سے بھی میل کھانا چاہیے
صرف LAN پری فکس سے میل کھانے والا قاعدہ آگے بھیجے گئے پیکٹ ڈھانپتا ہے۔ یہ گیٹ وے کے خود پیدا کردہ ٹریفک کو نہیں ڈھانپتا، اور نہ ہی LAN کلائنٹس کو واپس بھیجے گئے جوابات کو ڈھانپتا ہے، جو بطور ماخذ گیٹ وے کا LAN پتہ رکھتے ہیں۔ وہ تلاشیں main میں گرتی ہیں اور پھر بھی سرنگ سے باہر نکل سکتی ہیں۔
گیٹ وے کے اپنے LAN پتے کے لیے دوسرا قاعدہ شامل کرو، یا پہلے قاعدے کو دونوں کو شامل کرنے والے مجموعے تک پھیلا دو۔ ترتیب اہم ہے: زیادہ مخصوص قاعدہ پہلے رکھو، اور ماخذ کو واضح طور پر بتانے والی تلاش سے نتیجہ جانچو۔
ip route get 203.0.113.9 from 192.168.50.1اگر یہ اُس منزل کے لیے سرنگ کا آلہ بتائے جسے مقامی رہنا چاہیے، تو جدول میں کچھ بھی ہو، قواعد کا مجموعہ غلط ہے۔
NAT یا پار کی طرف راستہ
VPN سرور سرنگ کے ذیلی نیٹ ورک کو جانتا ہے اور کچھ نہیں۔ LAN ماخذ پتے کے ساتھ آنے والے پیکٹوں کے پاس واپسی کا راستہ نہیں ہوتا جب تک کوئی وہ مہیا نہ کرے، اور اسے مہیا کرنے کے بالکل دو طریقے ہیں۔ سرور پر LAN پری فکس کے لیے راستہ شامل کرنا اصل ماخذ کو سرے سے سرے تک نظر آتا رکھتا ہے، جو آڈٹ شدہ ڈیزائن کو عام طور پر چاہیے ہوتا ہے۔ گیٹ وے پر ماسکریڈ کرنا ماخذ کو سرنگ کے پتے میں دوبارہ لکھتا ہے اور سرور کے کسی تعاون کی ضرورت نہیں ہوتی۔
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEجب آپ سرور کنٹرول نہیں کرتے اور وہاں راستے شامل نہیں کر سکتے تو NAT چنو۔ جب لاگز، رسائی کنٹرول یا واپسی کے راستے کی ہم آہنگی اہم ہو تو سرور کی طرف کا راستہ چنو، کیونکہ ماسکریڈ اصل پتہ پار کی طرف کی ہر ریکارڈنگ سے مٹا دیتا ہے۔
ہر حال میں فارورڈنگ فعال ہونی چاہیے، اور سخت ریورس پاتھ فلٹرنگ جواب گرا سکتی ہے جب main اُس ماخذ کے لیے سرنگ نہ چنتا ہو۔ سرنگ کو قصوروار ٹھہرانے سے پہلے مؤثر قدر جانچو۔
دوبارہ جڑنے کے بعد بھی تقسیم قائم رہے
ہاتھ سے شامل کیے گئے قواعد اور راستے انٹرفیس دوبارہ بننے پر غائب ہو جاتے ہیں، اور پرانا جدول اندراج اُس سیشن سے زیادہ جی سکتا ہے جس نے اسے جائز ٹھہرایا تھا۔ جدول کا قاعدہ، سرنگ کا راستہ اور ماسکریڈ اندراج کلائنٹ کی route-up اسکرپٹ کے اندر رکھو، اور اسکرپٹ کے شروع میں جدول خالی کرو تاکہ پرانا گیٹ وے نئے سیشن میں نہ جی سکے۔
دونوں سروں سے جانچو: گیٹ وے پر LAN ماخذ کے ساتھ تلاش، اور LAN کلائنٹ سے اُس منزل تک حقیقی درخواست جسے سرنگ سے گزرنا چاہیے۔ جو راستہ موجود ہے مگر کبھی نہیں چنا جاتا، وہ شمار کنندگان پڑھنے تک بالکل راستہ نہ ہونے جیسا برتاؤ کرتا ہے۔