DD-WRT پر OpenVPN 2.5 سننے والا مر گیا؟ جو کنفیگ اس نے بنایا اسے پڑھیں

DD-WRT پر مردہ سننے والا عام طور پر یہ بتاتا ہے کہ ڈیمون اپنی کنفیگ تجزیہ کرتے ہوئے باہر نکل گیا، یہ نہیں کہ فائر وال کے کسی قاعدے نے پورٹ روکی۔ OpenVPN 2.5 نے کئی ڈیفالٹ سخت کیے جن پر پرانی کنفیگ انحصار کرتی تھیں، اور بنائی گئی کنفیگ جو پرانے بلڈ پر چلتی تھی، سوکیٹ کھلنے سے پہلے ہی مسترد ہو سکتی ہے۔ وجہ راؤٹر کے اپنے لاگ میں ہے، اور ان پٹ بنائی گئی فائل میں ہے۔ دونوں کو اسی ترتیب سے پڑھنا کسی بھی پیکٹ کیپچر سے تیز ہے۔

ڈیمون فائر وال نہیں ہے

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

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

وہ کنفیگ پڑھیں جو DD-WRT نے بنائی

DD-WRT وہ متن جو آپ نے ویب انٹرفیس میں ٹائپ کیا OpenVPN کو نہیں دیتا۔ یہ بنائی گئی کنفیگ /tmp/openvpn/openvpn.conf میں لکھتا ہے اور اسی فائل سے ڈیمون شروع کرتا ہے، اس لیے انٹرفیس کے فیلڈ اور Additional Config کا کوئی بھی متن OpenVPN کے دیکھنے سے پہلے ہی مل جاتے ہیں۔ اگر آپ بنائی گئی فائل کی بجائے فارم ڈیبگ کرتے ہیں، تو آپ ارادہ پڑھ رہے ہیں، اصل ان پٹ نہیں۔ ری بوٹ /tmp صاف کرنے سے پہلے اس فائل کو کسی مستقل جگہ نقل کریں۔

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

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

OpenVPN 2.5 نے کیا قبول کرنا بند کیا

OpenVPN 2.5 نے ncp-ciphers کو data-ciphers سے بدل دیا، اور ڈیفالٹ کم از کم TLS ورژن 1.2 کر دیا۔ اس نے کمپریشن کا طریقہ بھی بدلا، چنانچہ کمپریشن پیش کرنے والا ساتھی مسترد ہوتا ہے جب تک کنفیگ واضح طور پر اجازت نہ دے، اور ns-cert-type جیسے پرانے آپشن ناموں کو remote-cert-tls کے حق میں متروک قرار دیا۔ ان میں سے ہر تبدیلی پہلے چلنے والی کنفیگ کو تجزیہ یا مذاکرات کی ناکامی بنا دیتی ہے۔

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

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

Broadcom کے مخصوص پیشگی شرائط

Broadcom بلڈ پر ٹنل ڈیوائس ڈیمون کے استعمال سے پہلے موجود ہونی چاہیے۔ جانچیں کہ tun ماڈیول لوڈ ہے اور /dev/net/tun موجود ہے، کیونکہ ڈیوائس نہ ہونے سے ایسی شروعاتی ناکامی ہوتی ہے جس کا سرٹیفکیٹ سے کوئی تعلق نہیں۔ یہی بات DD-WRT راستوں اور DNS کے لیے بنائی گئی معاون اسکرپٹس پر بھی لاگو ہے: اگر وہ نہ ہوں یا چلانے کے قابل نہ ہوں، تو ڈیمون شروع ہو سکتا ہے اور پھر بھی اپنی ترتیب مکمل نہیں کر پاتا۔

جب اصل پیغام درکار ہو تو بنائی گئی کنفیگ پر زیادہ تفصیل کے ساتھ ڈیمون کو پیش منظر میں چلائیں۔ پیش منظر میں چلانا وہ تجزیہ خرابی چھاپتا ہے جو init اسکرپٹ نے نگل لی تھی۔

پھر معمول کی سروس بحال کریں، کیونکہ پیش منظر کا ڈیمون اور init اسکرپٹ پورٹ پر جھگڑیں گے۔

کلائنٹ ڈیبگ کرنے سے پہلے ثابت کریں کہ سننے والا موجود ہے

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

کلائنٹ کی طرف ڈیبگنگ تبھی معنی رکھتی ہے جب سننے والا موجود ہو۔ تب جانچیں کہ کلائنٹ کا سائفر اور TLS سیٹنگز سرور کی data-ciphers فہرست اور کم از کم ورژن سے میل کھاتی ہیں، اور پورٹ واقعی راؤٹر تک فارورڈ ہے۔

بنائی گئی کنفیگ اور وہ لاگ سطر محفوظ رکھیں جس نے درستی ثابت کی۔ اگلی فرم ویئر اپ ڈیٹ ڈیفالٹ پھر بدل سکتی ہے، اور وہی ریکارڈ تکرار کو پانچ منٹ کی جانچ میں بدلتا ہے۔