ایک ہی ہوسٹ پر OpenVPN سرور اور کلائنٹ: کلائنٹ کیوں گرتے ہیں

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

ایک مشین، دو کردار، اور جواب کہاں جانے چاہئیں اس بارے میں دو متضاد جواب۔

ایک ہی پول، دو سرور: کون جیتتا ہے

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

ترمیم سے پہلے فہرست بنائیں کہ کیا فعال ہے: ip -4 addr show ٹنل ڈیوائسز کی فہرست دیتا ہے، ss -lunp سننے والوں کی فہرست دیتا ہے، اور systemctl list-units یونٹس کے نام بتاتا ہے۔ ٹنل پتوں پر ایک نظر طے کرتی ہے کہ پول ٹکراتے ہیں یا نہیں۔

کلائنٹ پروفائل جدول میں کیا شامل کرتا ہے

کلائنٹ آدھا جڑتے ہی راستے لکھتا ہے۔ redirect-gateway def1 طے شدہ راستے کو 0.0.0.0/1 اور 128.0.0.0/1 میں تقسیم کرتا ہے، دونوں نئے ڈیوائس سے گزرتے ہیں، ساتھ میں دور دراز سرور تک ایک ہوسٹ راستہ جو جان بوجھ کر فزیکل انٹرفیس پر پن کیا گیا ہے۔ یہ پن اس لیے ہے کہ ٹنل اپنی ترسیل کے لیے راستہ رکھے۔ باقی سب کچھ، بشمول وہ جواب جو مقامی سرور اپنے کلائنٹس کا مقروض ہے، اب نئے طے شدہ راستے کی پیروی کرتا ہے اور دور دراز لنک سے باہر جاتا ہے۔

تو دوسرا ٹکراؤ ٹوٹا ہوا ٹنل نہیں ہے۔ یہ جدول میں غلط جگہ پر کام کرتا ٹنل ہے۔

کرداروں کو الگ رکھنے کے تین طریقے

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

آپ جو بھی راستہ لیں، استثنا میں LAN نہیں بلکہ مقامی ٹنل سب نیٹ کا نام ہونا چاہیے۔ مقامی سرور جو جواب بھیجتا ہے اس کا منزل ٹنل پتہ ہوتا ہے، اس لیے LAN کی شکل کا استثنا اس سے کبھی نہیں ملتا۔

دونوں انسٹینس میں سے کون قصوروار ہے

کلائنٹ انسٹینس روکیں اور اصل کلائنٹ دوبارہ جانچیں۔ فوری بحالی کا مطلب روٹنگ ہے، سرور نہیں۔ کلائنٹ واپس لائیں اور ip route get کے ذریعے ایک جواب کا سراغ لگائیں جسے ماخذ اور منزل دونوں پتے دیے گئے ہوں، جو دکھاتا ہے کرنل کون سا راستہ چنے گا، پھر tcpdump -ni any port 1194 سے دیکھیں کہ پیکٹ واقعی کون سا انٹرفیس استعمال کرتے ہیں۔ سرور کی حالت فائل، جو ہر چند سیکنڈ بعد status ہدایت کے ذریعے لکھی جاتی ہے، جڑے کلائنٹس کی فہرست اور دونوں سمتوں کے بائٹ کاؤنٹر رکھتی ہے۔

ان کاؤنٹروں کو ایک دوسرے کے سامنے پڑھیں۔ جو ٹریفک باہر جاتا ہے اور کبھی واپس نہیں آتا وہ ہینڈ شیک کا مسئلہ نہیں، روٹنگ کا جواب ہے۔