ایک OpenVPN حب، تین LAN: پتہ منصوبہ اور iroute فائلیں

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

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

ایسے منصوبے سے شروع کریں جسے کسی کو اندازہ لگانے کی ضرورت نہ ہو

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

ایک مثالی منصوبہ پول کو تین LAN سے کافی دور رکھتا ہے۔ آپ کا مختلف ہوگا، اور واحد سخت اصول یہ ہے کہ کوئی دو رینجیں اوورلیپ نہ ہوں۔

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

حب کے کرنل کو بتائیں کہ شاخیں کہاں ہیں

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

جب کرنل کو قواعد کے نفاذ کا مقام ہونا چاہیے تو client-to-client بند رکھیں۔ وہ آپشن پیروں کے درمیان ٹریفک کو ڈیمون کے اندر منتقل کرتا ہے، جو سہولت دیتا ہے اور اس کا مطلب یہ بھی ہے کہ آپ کے فارورڈنگ قواعد اس بہاؤ کو کبھی نہیں دیکھتے۔ نیچے سب کچھ یہ فرض کرتا ہے کہ کرنل شاخوں کے درمیان ہر پیکٹ دیکھتا ہے۔

ہر شاخ کو ضروری راستے دیں

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

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

مکمل کہنے سے پہلے دونوں سمتوں میں جانچ کریں

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

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

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

ڈیزائن اس لیے جڑا رہتا ہے کہ ہر تہہ کا ایک ہی کام ہے: منصوبہ سابقوں کو منفرد رکھتا ہے، کرنل راستہ پیکٹ منتقل کرتا ہے، iroute مالک کا نام لیتا ہے، اور فائر وال فیصلہ کرتا ہے کہ کیا اجازت ہے۔ جب کچھ ٹوٹے تو وہی فہرست جانچ کی ترتیب بھی ہوتی ہے۔