გაძლევთ TLS გარსი პირად ქსელს? ჩვეულებრივ არა

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

რას აკავშირებს სინამდვილეში სერვისის გარსი

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

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

application -> local listener -> TLS connection -> remote listener -> configured backend

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

იპოვეთ, სად მთავრდება TLS არხი

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

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

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

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

რას ამატებს მარშრუტირებული VPN და რას არ აკეთებს გარსი

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

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

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

შეადარეთ ის საზღვარი, რომელიც ფერხდება

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

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

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

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

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