OpenVPN اب بھی پرانے راستے دھکیل رہا ہے؟ دیکھیں اس نے کیا لوڈ کیا

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

نیچے دیا گیا موازنہ عمل سے باہر کی طرف جاتا ہے، کیونکہ کون سی فائل نافذ ہے یہ صرف عمل ہی جانتا ہے۔

وہ فائل جو آپ نے ترمیم کی اور وہ فائل جو عمل پڑھتا ہے

unit اور اس کی بنائی ہوئی کمانڈ لائن سے شروع کریں۔ systemd ہوسٹ پر systemctl cat openvpn@server ExecStart سطر چھاپتا ہے، اور instance unit عام طور پر اپنا کنفیگریشن راستہ instance کے نام سے نکالتا ہے، اس لیے openvpn@office کے طور پر شروع کیا گیا ڈیمون openvpn@server کے طور پر شروع کیے گئے سے مختلف فائل پڑھتا ہے۔ اس کا موازنہ چل رہے عمل کے argv سے کریں۔ کنفیگریشن مینجمنٹ ٹول تبدیلی گنوانے کا ایک اور طریقہ جوڑتا ہے: یہ صحیح فائل ایسی جگہ لکھ سکتا ہے جس کا unit کبھی ذکر نہیں کرتا، اور پھر کامیاب ڈپلائے کچھ نہ کرنے جیسا لگتا ہے۔

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

سرور کیا دھکیلتا ہے اور کلائنٹ کیا انسٹال کرتا ہے

دھکیلا گیا راستہ دو فلٹر پار کرے۔ سرور پر یہ لوڈ شدہ کنفیگریشن میں ہونا چاہیے، کسی تبصرہ شدہ بلاک میں یا ایسی کلائنٹ مخصوص فائل میں نہیں جس کا نام نہ ملے۔ کلائنٹ پر pull فعال ہونا چاہیے اور کوئی pull-filter اس انتخاب کو نہ پھینکے۔ verbosity 4 کے ساتھ جڑیں اور کلائنٹ کی بتائی دھکیلی گئی ترتیبات پڑھیں: اگر راستہ اس فہرست میں ہے تو سرور نے اپنا کام کیا ہے اور انسٹال نہ کرنے کا فیصلہ کلائنٹ کر رہا ہے۔

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

دھکیلا گیا سابقہ اور واپسی کا راستہ مختلف مسائل ہیں

وہ کلائنٹ جو اپنا مقامی انٹرنیٹ راستہ بچانے کے لیے redirect-gateway کو جان بوجھ کر نظر انداز کرتا ہے، دوسرا، غیر متعلق خلا پیدا کرتا ہے۔ سرور کی جانچ ٹنل کے پتے تک پہنچتی ہے مگر جواب کبھی نہیں آتے، کیونکہ سرور کے ٹنل IP کے لیے بھیجا گیا جواب کلائنٹ کے عام ڈیفالٹ گیٹ وے سے گزرتا ہے۔ یہاں دھکیلا گیا سب نیٹ راستہ قصوروار نہیں؛ جو نہیں ہے وہ ایسا راستہ ہے جو سرور کے ٹنل نیٹ ورک کی ٹریفک ٹنل ڈیوائس سے واپس بھیجے۔

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

دونوں سروں کی جدولیں موازنہ کریں

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

تین شناختیں ساتھ رکھیں: کنفیگریشن راستہ، unit یا instance کا نام، اور وہ کلائنٹ شناخت جس سے آپ نے جانچ کی۔

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

وہ راستہ مسئلہ جو دوبارہ آغاز کے بعد بھی رہے، اکثر راستہ بندی کا مسئلہ ہی نہیں ہوتا؛ خرابی اس جدول سے اوپر ہوتی ہے جو آپ مسلسل پڑھتے رہتے ہیں۔