რატომ opt-verify-ის დამატება OpenVPN-ის შიფრის შეცდომას არ გამოასწორებს

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

სასარგებლოა იცოდეთ, რას აკეთებდა ხაზი ადრე, სანამ დაასკვნით, რომ ის არის დაკარგული ნაწილი. ისტორია ასევე ხსნის, რატომ ვერ დაეხმარება ის ახლა.

რას აწესებდა პარამეტრი ადრე

2.6-ის სახელმძღვანელო opt-verify-ს მოძველებულად აღნიშნავს და აღწერს ადრინდელ ქცევას: სერვერი უგულებელყოფს კლიენტებს, რომელთა გამოცხადებული პარამეტრები მისას არ ემთხვევა, ადარებს რა ისეთ რამეებს, როგორიცაა მოწყობილობის ტიპი და MTU. ეს შემოწმება ასევე დამოკიდებულია იმაზე, რომ პარამეტრების თანმიმდევრულობის შემოწმება ჩართული დარჩეს, ამიტომ disable-occ-ით მომუშავე სერვერს ის არასოდეს ჰქონია. ყურადღება მიაქციეთ, რისგან არის აწყობილი შედარება: ტექსტისგან, რომელიც მეორე მხარის კონფიგურაციას აღწერს. ის არაფერს ამბობს იმაზე, რომელ შიფრს გამოიყენებს მონაცემთა არხი.

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

რას აკეთებს 2.7, როცა ხედავს ხაზს

2.7-ში პარამეტრი აღარ არის. პარსერი ჯერ კიდევ ცნობს სახელს, ამიტომ ძველი პროფილი სინტაქსური შეცდომის გარეშე იტვირთება, და ის აცხადებს, რომ პარამეტრი წაშლილია, ნაცვლად იმისა, რომ ჩუმად გამოტოვოს. სახელის ცნობა და ქცევის დაწესება სხვადასხვა რამეა, და ჯერ მხოლოდ პირველი ხდება. წაშლის შენიშვნები იძლევა მიზეზს: როგორც კი პარამეტრებზე მოლაპარაკება შესაძლებელი ხდება, ორ მხარეს შეიძლება ლეგიტიმურად ჰქონდეს განსხვავებული პარამეტრების სტრიქონები, თანაც შეთანხმდნენ კავშირზე.

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

სად ცხოვრობს სინამდვილეში ხარვეზი

შეინახეთ პირველი კონკრეტული შეცდომა, სანამ რაიმეს შეცვლით, რადგან შემდგომი შეტყობინებები ჩვეულებრივ მისი შედეგებია. მონაცემთა არხის მოლაპარაკების ხარვეზი ეკუთვნის დამტკიცებულ შიფრის პოლიტიკას და იმ შესაძლებლობებს, რომლებსაც ორივე მხარე რეალურად აცხადებს. TLS ვერსიის ან კრებულის ხარვეზი ეკუთვნის საკონტროლო არხს. სერტიფიკატის უარყოფას სჭირდება იდენტობა და ნდობის ჯაჭვი, და არა თავსებადობის დროშა.

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

შეცვალეთ განზრახვა, და არა მხოლოდ ხაზი

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

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

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

მიზანია მხარდაჭერილი შეზღუდვა და მომუშავე აუთენტიფიცირებული გზა, და არა ძველი დროშა, რომელიც ჯერ კიდევ ირჩევა.