DD-WRT-ზე OpenVPN 2.5-ის მსმენელი მკვდარია? წაიკითხეთ მის მიერ შექმნილი კონფიგურაცია

მკვდარი მსმენელი DD-WRT-ზე ჩვეულებრივ ნიშნავს, რომ დემონი გავიდა თავისი კონფიგურაციის ანალიზისას და არა ის, რომ firewall-ის წესმა პორტი დაბლოკა. OpenVPN 2.5-მა გაამკაცრა რამდენიმე ნაგულისხმევი მნიშვნელობა, რომლებსაც ძველი კონფიგურაციები ეყრდნობოდნენ, და შექმნილი კონფიგურაცია, რომელიც ძველ ბილდზე მუშაობდა, შეიძლება უარყოფილი იქნას socket-ის გახსნამდე. მიზეზი როუტერის საკუთარ ლოგშია, ხოლო შეყვანა — შექმნილ ფაილში. ორივეს ამ თანმიმდევრობით წაკითხვა ნებისმიერ პაკეტის ჩაჭერაზე სწრაფია.

დემონი firewall არ არის

განსხვავება მნიშვნელოვანია, რადგან გარედან ორივე ჩავარდნა ერთნაირად გამოიყურება: კლიენტი აგზავნის handshake-ს და არაფერს იღებს უკან. ერთი პროცესია, რომელიც არ მუშაობს, მეორე კი პროცესი, რომელიც მუშაობს და ფილტრავს.

გამოყავით ისინი ორი შემოწმებით, სანამ რამეს შეცვლით, რადგან მკვდარ დემონზე firewall-ის რედაქტირება მხოლოდ მეორე ცვლადს ამატებს.

წაიკითხეთ კონფიგურაცია, რომელიც 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. ამ ცვლილებებიდან თითოეული ადრე მომუშავე კონფიგურაციას ანალიზის ან მოლაპარაკების ჩავარდნად აქცევს.

ჩავარდნის ხერხი დირექტივაზეა დამოკიდებული. უცნობი ან წაშლილი ოფცია დემონს გაშვებისას აჩერებს, ეს არის თქვენი მკვდარი მსმენელი. მოლაპარაკების შეუთანხმებლობა დემონს ამუშავებს და კლიენტებს უარყოფს, რაც კლიენტის მხრიდან firewall-ის პრობლემად გამოიყურება.

წაიკითხეთ ლოგში პირველი შეცდომა და არა ბოლო. ანალიზი პირველ ცუდ დირექტივაზე ჩერდება და ყველაფერი მის შემდეგ გამორთვის ხმაურია.

Broadcom-ისთვის დამახასიათებელი წინაპირობები

Broadcom-ის ბილდებზე გვირაბის მოწყობილობა უნდა არსებობდეს, სანამ დემონი მას გამოიყენებს. შეამოწმეთ, რომ tun მოდული ჩატვირთულია და რომ /dev/net/tun არსებობს, რადგან მოწყობილობის არარსებობა იწვევს გაშვების ჩავარდნას, რომელსაც სერტიფიკატებთან არანაირი კავშირი არ აქვს. იგივე ეხება დამხმარე სკრიპტებს, რომლებსაც DD-WRT მარშრუტებისა და DNS-ისთვის ქმნის: თუ ისინი არ არსებობს ან არ არის შესრულებადი, დემონი შეიძლება გაეშვას და მაინც ვერ დაასრულოს თავისი კონფიგურირება.

როცა ნამდვილი შეტყობინება გჭირდებათ, გაუშვით დემონი წინა პლანზე უფრო მაღალი დეტალურობით შექმნილ კონფიგურაციაზე. წინა პლანზე გაშვება ბეჭდავს იმ ანალიზის შეცდომას, რომელიც init სკრიპტმა გადაყლაპა.

შემდეგ აღადგინეთ ჩვეულებრივი სერვისი, რადგან წინა პლანის დემონი და init სკრიპტი პორტისთვის იჩხუბებენ.

დაამტკიცეთ, რომ მსმენელი არსებობს, სანამ კლიენტებს გამართავთ

ცალ-ცალკე დაადასტურეთ პროცესი და socket: ერთი ბრძანება მომუშავე დემონისთვის, მეორე — მოსალოდნელ მისამართზე მიბმული UDP პორტისთვის. socket-ის გარეშე პროცესი ნიშნავს, რომ ის ჯერ კონფიგურირებაშია ან არასწორ ინტერფეისზეა მიბმული. წყვილი სასარგებლო ტესტია ზუსტად იმიტომ, რომ ერთი ნახევარი მეორის გარეშე ვერ იქნება ჭეშმარიტი.

კლიენტის მხრიდან გამართვას აზრი მხოლოდ მას შემდეგ აქვს, რაც მსმენელი არსებობს. შემდეგ შეამოწმეთ, რომ კლიენტის შიფრი და TLS პარამეტრები შეესაბამება სერვერის data-ciphers სიას და მინიმალურ ვერსიას, და რომ პორტი ნამდვილად გადაეცემა როუტერს.

შეინახეთ შექმნილი კონფიგურაცია და ლოგის ის ხაზი, რომელმაც გამოსწორება დაამტკიცა. შემდეგი firmware განახლება შეიძლება კვლავ შეცვალოს ნაგულისხმევები და სწორედ ეს ჩანაწერი აქცევს გამეორებას ხუთწუთიან შემოწმებად.