TLS VPN IPsec-ის წინააღმდეგ: ხუთი ველი, რომელიც ღირს გადამოწმებად
შეადარეთ TLS VPN და IPsec VPN გამოშვების, პროტოკოლის ვერსიის, კომპლექტის, თანაწარმომადგენლის იდენტობისა და გამოვლენილი არეალის მიხედვით, ასევე იმ წარუმატებლობის შედეგის მიხედვით, რომელიც თქვენ რეალურად დააკონფიგურირეთ.
TLS VPN-ების IPsec VPN-ებთან პროტოკოლის ოჯახის მიხედვით რანჟირება პასუხობს კითხვას, რომელიც არავის დაუსვამს, და ჩვეულებრივ მოიხსენიებს კონსტრუქციას, რომელიც ორივე ოჯახმა წლების წინ მიატოვა. რისი შეფასებაც რეცენზენტს ნამდვილად შეუძლია, არის შეთანხმებული დაცვა, თანაწარმომადგენლის იდენტობა, კლიენტის მოდელი და გამოვლენილი სერვისი. ეს ოთხი რამ განლაგებაში ჩანს და არც ერთი მათგანი არ გამომდინარეობს პროდუქტის ეტიკეტიდან. მოითხოვეთ ხუთი ველი და საუბარი კონკრეტული გახდება.
ხუთი ველი, და ეტიკეტი მათგან ერთი არ არის
პირველი ველი არის მხარდაჭერილი პროგრამული უზრუნველყოფის გამოშვება, რადგან ვერსიის გარეშე პროტოკოლის აღწერა ბროშურაა. მეორე არის შეთანხმებული პროტოკოლის ვერსია, რომელიც განსაზღვრავს, რომელი კონსტრუქციებია საერთოდ ხელმისაწვდომი. მესამე არის დაცვის კომპლექტი, მეოთხე არის ავთენტიფიკაციის მეთოდი როგორც თანაწარმომადგენლისთვის, ისე მომხმარებლისთვის, ხოლო მეხუთე არის წვდომის არეალი, რომელსაც პროდუქტი დაშვების შემდეგ იძლევა.
SSL VPN ეტიკეტი მოიცავს მინიმუმ სამ სხვადასხვა პროდუქტს: სრულ ქსელურ კლიენტს, აპლიკაციის პროქსის და ბრაუზერზე დაფუძნებულ ძველ პორტალს. ისინი სხვადასხვა სერვისს ამჟღავნებენ და სხვადასხვანაირად ფუჭდებიან, ამიტომ ეტიკეტი ვერ შეცვლის არეალის ველს.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
რას ცვლის სინამდვილეში ავთენტიფიცირებული დაშიფვრა
TLS 1.3 მოითხოვს ავთენტიფიცირებულ დაშიფვრას, რაც პროტოკოლიდან აშორებს ძველ MAC-then-encrypt კონსტრუქციას და არ ტოვებს მას არჩევითს. IPsec ESP-საც იმავე ხანგრძლივობით აქვს ავთენტიფიცირებული დაშიფვრის კომპლექტები, AES-GCM კი საკუთარ RFC-შია განსაზღვრული. ორივე ოჯახში გარანტია მოდის შეთანხმებული კომპლექტიდან და არა ოჯახის სახელიდან, ამიტომაც ველების სია ვერსიით იწყება. რეცენზენტს, რომელსაც კომპლექტის დასახელება არ შეუძლია, შესაფასებელი არაფერი აქვს.
ამიტომ ისტორიული შედარება შეცდომაში შეჰყავს. ძველ TLS ვერსიაზე CBC კომპლექტით მიმაგრებული განლაგება და AEAD კომპლექტით TLS 1.3-ის მაშველი განლაგება ერთი და იგივე უსაფრთხოების პოზიცია არ არის, თუმცა ორივე TLS VPN-ია. იგივე გაყოფა IPsec-ის მხარესაც არსებობს თანამედროვე ESP კომპლექტსა და ძველ კომბინაციას შორის.
წაიკითხეთ შეთანხმებული მნიშვნელობები და არა კონფიგურაცია, რომელიც განიზრახეთ. ქვემოთ მოცემული ბრძანებები აჩვენებს, რაზეც ცოცხალი ბოლო წერტილი და ცოცხალი გვირაბი რეალურად შეთანხმდნენ.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasთუ ბოლო წერტილს TLS 1.3-ზე მოლაპარაკება არ სურს, ეს აღმოჩენაა და არა უპირატესობა. თუ გვირაბი ჩამოთვლის კომპლექტს, რომელსაც არ ელოდით, მნიშვნელოვანი კონფიგურაცია არის ის, რაც თანაწარმომადგენლებმა აირჩიეს და არა ის, რაც შაბლონშია.
თანაწარმომადგენლის იდენტობა ცალკე კითხვაა
დაშიფვრა დაუდასტურებელი თანაწარმომადგენლის გარეშე იცავს ტრაფიკს დამკვირვებლებისგან და გადასცემს მას იმას, ვინც კავშირს უპასუხა. თანაწარმომადგენლის ავთენტიფიკაცია კითხულობს, რომელი იდენტობაა მოსალოდნელი, რომელი ნდობის მასალა ამოწმებს მას და როგორ იქცევა კლიენტი, როცა პასუხი არ ემთხვევა. სერტიფიკატების ჯაჭვი, ჩამაგრებული გასაღები და წინასწარ გაზიარებული საიდუმლო სამი სხვადასხვა პასუხია სამი სხვადასხვა ოპერაციული ხარჯით.
შემდეგ დასვით იგივე კითხვები მომხმარებელზე ან მოწყობილობაზე. შესასვლელი, რომელიც ავთენტიფიცირებს მანქანას და უშვებს ნებისმიერ მომხმარებელს, ან პირიქით, აქვს გარკვეული პოზიცია, რომელიც უნდა ჩაიწეროს და არა ჩაითვალოს. დაშვების შემდეგ გამოყენებული რესურსების ნებართვები იმავე ველის ნაწილია, რადგან ავთენტიფიკაცია ავტორიზაცია არ არის.
ჰოსტის სახელისა და სერტიფიკატის შემოწმებების შენარჩუნება უფრო მნიშვნელოვანია, ვიდრე შესვლის ფანჯრის ნაცნობობა. კლიენტმა, რომელიც შემოწმების იგნორირებაზეა დაკონფიგურირებული, ამოიღო ერთადერთი ნაბიჯი, რომელიც თქვენს შესასვლელს დამაჯერებელი მიბაძვისგან გამოარჩევს.
საზღვარი, რომელსაც პროდუქტი ამჟღავნებს
კლიენტის გარეშე პორტალი არჩეულ აპლიკაციის ოპერაციებს შესასვლელის გავლით პროქსავს, ამიტომ მომხმარებელი ინტერფეისს აღწევს და არა ქსელს. სრული გვირაბის კლიენტი ატარებს იმას, რასაც მისი მარშრუტები და ფილტრაციის პოლიტიკა ირჩევს, რაც გაცილებით დიდი ზედაპირია. ორივეს პროტოკოლის სიძლიერით შედარება გამოტოვებს განსხვავებას იმაში, რასაც თავდამსხმელი მათი მეშვეობით მიაღწევს. ერთი ამჟღავნებს აპლიკაციის ინტერფეისს, მეორე მარშრუტიზებულ ქსელს, და ორივე სხვადასხვა მიმოხილვას მოითხოვს.
იკითხეთ, რომელი სერვისია გამოვლენილი, რომელი ოპერაციებია ავტორიზებული და რას უსმენს თავად შესასვლელი. მართვის ინტერფეისი, რომელიც მომხმარებლის პორტალის იმავე მისამართიდან არის ხელმისაწვდომი, განლაგების აღმოჩენაა და არც ერთი პროტოკოლის არჩევანი არ ანაზღაურებს მას.
აპლიკაციაზე არეალი კიდევ უფრო ავიწროებს ზედაპირს და ცვლის წარუმატებლობის ქცევასაც, როცა გვირაბი ვარდება. დიზაინი, რომელიც სრული გვირაბის მიღწევას ვარაუდობს, ისე ტყდება, როგორც აპლიკაციაზე დაფუძნებული დიზაინი არ იცის, და მხარდაჭერის დატვირთვა მოჰყვება.
გადაწყვიტეთ წარუმატებლობის შედეგი და სასიცოცხლო ციკლი
რა ხდება, როცა ავთენტიფიკაცია ან დაცვა მიუწვდომელია, ეს პოლიტიკის გადაწყვეტილებაა, რომელიც მიმოხილვას ეკუთვნის. დაბლოკილი შედეგი და გაუცხადებელი პირდაპირი უკან დაბრუნება სხვადასხვა შედეგს იძლევა და განსხვავება ფუნქციების სიაში უხილავია. მიუთითეთ განზრახული ქცევა რესურსის გვერდით, რომელსაც ის იცავს.
შეიტანეთ შესასვლელის პაჩებისა და მხარდაჭერის სასიცოცხლო ციკლი, მისი ჩართული გარე ფუნქციები და კლიენტების განახლების გზა. სწორი პროტოკოლის არჩევანი ცუდად განლაგებულ სერვისს უსაფრთხოს არ ხდის და ინციდენტების უმეტესობა სწორედ იმ ხარვეზში ცხოვრობს და არა კომპლექტში.
ჩაწერეთ ხუთი ველი, წარუმატებლობის პოლიტიკა და სასიცოცხლო ციკლის მფლობელი ერთ გვერდზე. ეს გვერდი მიმოხილვაა; პროტოკოლის ოჯახების შედარება აზრია.