دو گیٹ وے، ایک VPN: OpenVPN کیوں غلط اوپری لنک چنتا ہے

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

ٹنل کا پتہ آخری نقطہ نہیں ہے

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

پروفائل میں remote اندراج بیرونی منزل کا نام دیتا ہے، اس لیے وہی پتہ پن کرنا ہے۔ یہ وہ قدر بھی ہے جو اس وقت بدلتی ہے جب ہوسٹ نام کسی اور طرح حل ہو یا پروفائل کئی remote درج کرے۔

وہ پتہ تلاش کریں جس پر کلائنٹ نے واقعی ڈائل کیا

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

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

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

پتے کا خاندان بھی جانچیں۔ دوہرے اسٹیک والا پروفائل IPv6 کے ذریعے جڑ سکتا ہے جبکہ آپ کا استثنا صرف IPv4 کا احاطہ کرتا ہے، اور پھر ٹریفک آپ کے لکھے ہوئے قاعدے سے مختلف قاعدے کی پیروی کرتی ہے۔ یہی بات اُس پراکسی پر بھی لاگو ہے جو آخری نقطے کی طرف سے جواب دیتا ہے۔ دونوں صورتوں میں ایسا ٹنل بنتا ہے جو کام کرتا ہے جبکہ آپ کا روٹ کچھ نہیں کرتا۔

آخری نقطہ پن کریں اور پالیسی کی ترتیب پڑھیں

ہوسٹ روٹ کسی بھی ڈیفالٹ روٹ سے زیادہ مخصوص ہے۔ اسی لیے پیر کے پتے کے لیے /32 اُس جدول میں جیت جاتا ہے جو اسے رکھتی ہے۔ عام شکل گیٹ وے اور ڈیوائس کا واضح نام لیتی ہے:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

وہ روٹ صرف اُس وقت مدد کرتا ہے جب تلاش اُس جدول تک پہنچے۔ پالیسی کے قواعد ترتیب سے جانچے جاتے ہیں اور پہلا میل فیصلہ کرتا ہے، اس لیے جو قاعدہ سب کچھ دوسری جدول میں بھیجتا ہے وہ main میں آپ کے ہوسٹ روٹ کو نظرانداز کرتا ہے۔ روٹ کو مستند ماننے سے پہلے قواعد پڑھیں:

ip rule show
ip route get 203.0.113.40

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

جب آخری نقطہ سرکے

جو ہوسٹ نام کئی پتوں میں حل ہو، وہ جواب بدلتے ہی مستقل /32 کو باطل کر دیتا ہے۔ کئی remote لائنوں والا پروفائل بھی وہی مسئلہ رکھتا ہے، کیونکہ کلائنٹ اُن میں سے کسی پر بھی اتر سکتا ہے۔ روٹ کو ہاتھ سے شامل کرنے کے بجائے کلائنٹ کے اپنے زندگی کے چکر کے ہکس سے تازہ کریں۔ وہ up اسکرپٹ جو طے شدہ پیر پڑھتا ہے اور ہوسٹ روٹ نصب کرتا ہے، استثنا کو حقیقت کے ساتھ ہم آہنگ رکھتا ہے، اور مماثل down اسکرپٹ اسے ہٹا دیتا ہے۔

تازہ کاری کو اُسی جگہ درج کریں جہاں ہوسٹ کی باقی روٹنگ ترتیبات ہیں۔ جو روٹ صرف اگلی ری بوٹ تک رہے وہ آزمائش ہے، حل نہیں۔

اندرونی پالیسی الگ رکھیں

بیرونی راستہ ہٹانے سے نئے نجی ذیلی نیٹ ورک تک رسائی نہیں ملتی اور یہ بھی نہیں بدلتا کہ سرور ٹنل میں کون سی منزلیں دھکیلتا ہے۔ نچلی پرت کا روٹ تار چنتا ہے؛ دھکیلے گئے روٹ چنتے ہیں کہ ٹنل میں کیا داخل ہوتا ہے۔ ان دو فیصلوں کو الگ رکھنا ہی تقسیم کو قابلِ پیش گوئی بناتا ہے۔

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

نتیجے کی تصدیق دو آزاد مشاہدوں سے کریں: ساکٹ کا مقامی پتہ اور ڈیوائس، اور وہ روٹ جس پر نجی منزل حل ہوتی ہے۔ جب دونوں آپ کے ارادے سے میل کھائیں تو تقسیم حقیقی ہے۔ OpenVPN 2.6 Manuel remote اور مقامی بائنڈنگ کے اختیارات کا احاطہ کرتا ہے جو طے کرتے ہیں کہ کلائنٹ کس پتے پر ڈائل کرے گا۔