OpenVPN کے ذریعے عوامی سابقہ: واپسی کا راستہ درست کریں

دیکھیں کہ ٹنل اوپر آتا ہے اور کلائنٹ دوسری طرف پنگ کرتا ہے، پھر VPN کے پیچھے موجود کوئی عوامی پتہ کہیں اور سے جواب دیتا ہے، یا بالکل جواب نہیں دیتا۔ اس علامت کا عام طور پر سائفر یا سرٹیفکیٹس سے کوئی تعلق نہیں ہوتا۔ فراہم کنندہ کا روٹ کیا ہوا سابقہ IP راستے کے طور پر پہنچایا جاتا ہے، اور اسے OpenVPN کے ذریعے لے جانے کا مطلب ہے اس راستے کو دو سطحوں پر دوبارہ بنانا اور واپسی کے راستے پر ماخذ پتہ محفوظ رکھنا۔ WAN کو برج کرنے کی ضرورت نہیں، اور پتہ کسی انٹرفیس میں شامل کرنے سے اوپری راستہ نہیں بنتا۔

سابقہ پہلے آپ کی طرف روٹ ہونا چاہیے

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

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

OpenVPN کو چھونے سے پہلے ڈیلیوری ماڈل آزمائیں: باہر سے بلاک کے کسی پتے کو پنگ کریں اور دیکھیں کون سا انٹرفیس اسے وصول کرتا ہے۔ اگر کچھ نہ آئے تو کوئی ٹنل کنفیگریشن مدد نہیں کرے گی۔ اگر پتہ WAN پر براہ راست جواب دیتا ہے، تو فراہم کنندہ روٹ کرنے کے بجائے برج کر رہا ہے، اور نیچے کا ڈیزائن لاگو نہیں ہوتا۔

دو روٹنگ سطحیں: کرنل راستہ اور iroute

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

سرور کی طرف کا راستہ ایسا دکھتا ہے، جس میں سابقہ اور ماسک تخصیص سے مطابقت رکھنے چاہئیں:

ip route add 198.51.100.64/28 dev tun0

کلائنٹ مخصوص کنفیگریشن ملکیت تفویض کرتی ہے۔ اسے کلائنٹ سرٹیفکیٹ کے عام نام پر نامزد CCD فائل میں رکھیں، اور تصدیق کریں کہ سرور واقعی وہی ڈائریکٹری پڑھتا ہے:

iroute 198.51.100.64 255.255.255.240

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

سروس کا پتہ کہاں رہتا ہے

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

جس Linux کلائنٹ پر سروس مقامی طور پر ختم ہوتی ہے، وہاں ایک ہی ہوسٹ پتہ کافی ہے:

ip address add 198.51.100.70/32 dev lo

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

واپسی کے راستے پر عوامی ماخذ محفوظ رکھیں

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

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

iptables -t nat -S POSTROUTING

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

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

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

کرنل سے پوچھیں کہ تفویض شدہ پتہ کون سا راستہ لیتا ہے، اور درخواست چلنے کے دوران ٹنل کا مشاہدہ کریں:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

ریورس پاتھ فلٹرنگ درست راستہ منسوخ کر سکتی ہے۔ ٹنل اور اپ لنک پر مؤثر سیٹنگ جانچیں، اور یاد رکھیں کہ سخت موڈ اس ٹریفک کو مسترد کرتا ہے جس کا ماخذ اس انٹرفیس سے مطابقت نہیں رکھتا جس پر وہ آیا:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

آخر میں، ناکامی کی صورت آزمائیں۔ ٹنل روکیں اور تصدیق کریں کہ عوامی سابقہ عام اپ لنک سے نہیں نکلتا۔ VPN بحال کرنے سے سروس واپس آنی چاہیے بغیر یہ بڑھائے کہ ہوسٹ کون سی پورٹیں کھولتا ہے۔