AES-256-GCM ვერ მოიძებნა: კლიენტის შესაძლებლობა თუ მოლაპარაკება?

OpenVPN-ის პროფილი, რომელიც სხვაგან მუშაობს, აცხადებს, რომ AES-256-GCM ვერ მოიძებნა, ან რომ მხარეებს საერთო შიფრი არ აქვთ, და პირველი იმპულსი პროფილის რედაქტირებაა. ეს ორი შეტყობინება სხვადასხვა წარუმატებლობას აღწერს. ერთი ამბობს, რომ ადგილობრივ პროგრამას ასეთი ალგორითმი არ აქვს; მეორე ამბობს, რომ ორივე მხარეს ალგორითმები აქვს, მაგრამ საერთო არჩევანი არა. პროფილის რედაქტირება არც ერთს არ ასწორებს, სანამ არ გაიგებთ, რომელი გაქვთ.

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

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

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

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

ადგილობრივი შესაძლებლობის ხარვეზი

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

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

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

OpenVPN 3-ზე დაფუძნებულ კლიენტებში ძრავა და მისაღები დირექტივები საზოგადოების 2.x ხაზისგან განსხვავდება, ამიტომ იგივე პროფილის ტექსტი შეიძლება ჩავარდეს მიზეზებით, რომლებსაც შიფრების სიასთან კავშირი არ აქვთ.

მოლაპარაკების ხარვეზი

როცა ორივე მხარე ალგორითმს ჩამოთვლის, რჩება კითხვა, რომელი სია გვთავაზობს თითოეული მხარე. საზოგადოების OpenVPN-მა მოლაპარაკების დირექტივა გადაარქვა: ncp-ciphers 2.4-ში გახდა data-ciphers 2.5-ში, ხოლო 2.6-ში ძველი cipher ხაზი ძირითადად თავსებადობას და უკან დაბრუნებას ემსახურება და არა მოლაპარაკებული ნაკრების განსაზღვრას.

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

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

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

შეინარჩუნეთ თავსებადობა ცხადად

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

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

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