AES-NI OpenSSL-ში თუ ბირთვში გადატანა: რომელი გჭირდებათ?
გამოყავით CPU-ს ინსტრუქციების მხარდაჭერა იმისგან, თუ სად მუშავდება პაკეტები: კრიპტო backend-ი, შეთანხმებული შიფრი და აქტიური გზა შეამოწმეთ დარეგულირებამდე.
ორი იარლიყი ისე გამოიყენება, თითქოს ერთი და იგივე იყოს: აპარატურულად დაჩქარებული და ბირთვში გადატანილი. ერთი აღწერს, რომელ ინსტრუქციებს ასრულებს ბიბლიოთეკის AES რუტინა, მეორე კი აღწერს, სად ხდება პაკეტების დამუშავება. VPN-ს შეიძლება ჰქონდეს პირველი მეორის გარეშე, მეორე პირველის გარეშე, ან ორივე ერთად. ნებისმიერი გადაწყვეტილება წარმადობაზე უნდა დაიწყოს იმის დასახელებით, თუ ამ ორიდან რომელს ცვლით სინამდვილეში.
ორი ღერძი და არა ერთი ქულა
პირველი ღერძია იმპლემენტაცია: AES-256-GCM-ის შემსრულებელი კოდი მიდის პროცესორის სპეციალურ ინსტრუქციებს იყენებულ ვერსიაზე, თუ გადატანად რუტინაზე, რომელიც მათ ჩვეულებრივ არითმეტიკად ასრულებს. ეს არჩევანი კრიპტოგრაფიული ბიბლიოთეკის შიგნით ცხოვრობს და მისი ინიციალიზაციისას კეთდება.
მეორე ღერძია განლაგება: პაკეტი გადის ბირთვის ტრანსფორმაციის გზაზე, თუ მომხმარებლის სივრცეში მყოფი დემონი კითხულობს გვირაბის მოწყობილობიდან, შიფრავს და უკან წერს.
არც ერთი ღერძი არ ზღუდავს მეორეს. მომხმარებლის სივრცის VPN AES ინსტრუქციების მქონე პროცესორზე შეიძლება მათ მუდამ იყენებდეს, ხოლო ბირთვის გზა მათ გარეშე პროცესორზე პროგრამულ იმპლემენტაციას უბრუნდება. მომწოდებლების მასალებში იარლიყები იშვიათად ასახავს ამ განსხვავებას და ამიტომაც ორ სიტუაციას შორის გადაკოპირებული დარეგულირების რჩევები ასე ხშირად არაფერს აკეთებს.
ღერძი პირველი: რომელი კოდი ასრულებს შიფრაციას
OpenSSL ინიციალიზაციისას ამოიცნობს პროცესორის თვისებებს და შედეგს ოპტიმიზებული კოდის გზების ასარჩევად იყენებს, როგორც ამას x86 შესაძლებლობების დოკუმენტი აღწერს. AES-NI ამ გადამისამართების უკან მდგარი დოკუმენტირებული შესაძლებლობებიდან ერთია. აქედან არაფერი მოითხოვს, რომ ბიბლიოთეკა ბირთვის კომპონენტად იქცეს.
სანამ ჩათვლით, რომ სწრაფი გზა გამოიყენება, დაადასტურეთ, რომ თვისება პროცესისთვის ხილვადია. Linux-ზე წყარო /proc/cpuinfo-ის flags ველია, ხოლო სტუმრის შიგნით ის ასახავს იმას, რასაც ჰიპერვიზორი ამჟღავნებს და არა ფიზიკური ჰოსტის მოდელის სახელს.
grep -m1 '^flags' /proc/cpuinfo | grep -o '\baes\b'
openssl list -providers -verboseმეორე ბრძანება ასახელებს იმ მომწოდებლებს, რომლებიც ამ ბილდში ჩაიტვირთა. ის არ გეუბნებათ, რომელ ბიბლიოთეკას დაუკავშირდა VPN სერვისი, და ერთ ჰოსტს შეიძლება ორი OpenSSL-ის ინსტალაცია ჰქონდეს, სანამ გაშვებული პროცესი მხოლოდ ერთს იყენებს.
ღერძი მეორე: სად მუშაობს პაკეტის გზა
ბირთვში განლაგება ნიშნავს, რომ ტრანსფორმაცია ხდება თავად ბირთვის IPsec მექანიზმში ან ბირთვის შიგნით არსებულ გვირაბის დრაივერში, ამიტომ პაკეტებს თითოეული პარტიისთვის მომხმარებლის სივრცის პროცესში ორმხრივი მოგზაურობა არ სჭირდებათ. ამან შეიძლება შეამციროს კოპირებები და კონტექსტის გადართვები და სამუშაო ბირთვებზე გაანაწილოს ისე, როგორც ერთნაკადიან დემონს არ შეუძლია. ის ასევე გადაადგილებს მრიცხველებსა და კვალს, რომლებსაც წაიკითხავთ, როცა გამტარუნარიანობა დაეცემა, რადგან სამუშაო ახლა იმ საზღვრის მეორე მხარეს ხდება, რომელსაც არ აკონტროლებთ. განიხილეთ ეს გამართვის ხარჯად და არა მხოლოდ წარმადობის გადაწყვეტილებად.
ის არ ქმნის ინსტრუქციების მხარდაჭერას, არ აყენებს შიფრს და არსებულ გზას არ ამუშავებს.
ვირტუალიზაცია ამ ღერძზეც ამატებს ნაოჭს. სტუმარს შეიძლება მისცენ ნიღბიანი პროცესორის მოდელი, რომელიც მალავს ჰოსტის თვისებებს, ხოლო ჩადგმულ სტუმარს კიდევ ნაკლები დაუნახავს. შესაძლებლობების ხედი წაიკითხეთ იმ გარემოს შიგნიდან, სადაც VPN რეალურად მუშაობს და არა ჰიპერვიზორის კონსოლიდან.
რას ყიდულობს თითოეული არჩევანი და რას არ შეუძლია
პრაქტიკული კითხვაა, სად მიდის დრო. თუ გამტარუნარიანობას ზღუდავს ერთი დაკავებული ნაკადი, ბუფერის განმეორებითი კოპირება ან თითო პაკეტზე სისტემური გამოძახება, ტრანსფორმაციის იმ გზაზე გადატანა, რომელიც ამ ხარჯებს აცილებს, შეიძლება დაეხმაროს, იმ პირობით, რომ ბირთვი თქვენთვის საჭირო ტრანსფორმაციას ახორციელებს.
თუ ზღვარი გადატვირთული აღმავალი არხია, დანაკარგებიანი გზა, გრძელი ორმხრივი დრო, გაჯერებული დანიშნულების სერვისი ან ერთ ბირთვზე მიმაგრებული ნაკადი, განლაგება ვერაფერს შეცვლის მნიშვნელოვანს. იგივე ეხება ინსტრუქციების არჩევას: AES სპეციალურ აპარატურაზე ვერ შეაკეთებს დაკარგულ გზას და არ დაეხმარება, თუ გვირაბი უმოქმედოა, რადგან სახელების გარჩევა ვერ ხერხდება.
სადაც ორივე მოქმედებს, ისინი ერთდება. ბირთვის გზას შეუძლია იგივე ინსტრუქციის დონის გადამისამართება გამოიყენოს ბირთვის კრიპტო API-ის შიგნით, ხოლო კარგად შერჩეული ბიბლიოთეკის მქონე მომხმარებლის სივრცის გზა უკვე იყენებს მას. გადაწყვეტილება არ არის, რომელია უფრო სწრაფი აბსტრაქტულად; ის არის, რომელი ხარჯისთვის გაქვთ მტკიცებულება.
ჩაწერეთ ოთხი ფაქტი, სანამ რამეს შეცვლით
ჩაწერეთ სერვისის ბინარული ფაილი და კრიპტოგრაფიული ბიბლიოთეკა, რომელზეც ის დაკავშირებულია, რადგან სწორედ ისინი წყვეტენ პირველ ღერძს. შემდეგ ჩაიწერეთ შეთანხმებული მონაცემთა დაცვა, რადგან სპეციალური ინსტრუქციის გზის გარეშე შიფრი სხვაგვარად იქცევა, ვიდრე მის მქონე, და კრებულს ორივე მხარე ირჩევს.
შემდეგ შესაძლებლობების ხედი მოქმედი გარემოს შიგნიდან და ბოლოს აქტიური პაკეტის გზა მტკიცებულებით, რომ რეჟიმი, რომელსაც ჩართულად თვლით, ნამდვილად ასეთია. ჩატვირთული მოდული არ არის მტკიცებულება, რომ პროფილი მას იყენებს, და კონფიგურაციის სტრიქონი არ არის მტკიცებულება, რომ ბირთვმა ის მიიღო.
შეცვალეთ ერთი რამ და შემდეგ შეადარეთ თანმიმდევრულ დატვირთვას იგივე ბოლო წერტილებითა და გადაცემის იგივე მიმართულებით. სიჩქარის ის მტკიცება, რომელიც არ გაზომეთ, ნაკლებად ღირს, ვიდრე ჩანაწერი, რომ backend-ი არასოდეს ყოფილა ეჭვქვეშ.