SSTP OpenVPN-ის წინააღმდეგ: იგივე პორტი 443, სხვა პროტოკოლი

ორივე ვარიანტი შეიძლება იდგეს TCP 443-ის უკან, ამიტომ ადამიანები ფიქრობენ, რომ ისინი ურთიერთშემცვლელი ბოლო წერტილებია. ასე არ არის: SSTP სერვერი HTTPS-ის შიგნით PPP-ს ლაპარაკობს, ხოლო OpenVPN სერვერი საკუთარ პროტოკოლს ლაპარაკობს TLS-ის ზემოთ ან ნედლი UDP ნაკადით. ერთი კლიენტის მეორის პორტზე მიმართვა ქმნის კავშირს, რომელიც არასდროს აღწევს შესვლის მოთხოვნამდე. არჩევანი ეხება რომელი კლიენტი და ტრანსპორტი შეგიძლიათ მხარი დაუჭიროთ, და არა ნომერს.

საერთო პორტი საერთო პროტოკოლს არ ქმნის

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

არც გადარქმეული პროფილი და არც სხვა მენიუს ჩანაწერი არ აქცევს ერთს მეორედ. SSTP კავშირი იქმნება Windows-ის VPN პარამეტრებიდან სერვერის მისამართითა და ოპერატორის ავთენტიფიკაციის მონაცემებით, ხოლო OpenVPN კავშირს სჭირდება კლიენტი და შესაბამისი კონფიგურაციის ფაილი. Microsoft-ის SSTP სპეციფიკაცია პირველს აღწერს და OpenVPN-ის ხელის ჩამორთმევას არ აღწერს.

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

SSTP PPP-ს HTTPS-ის შიგნით ტუნელებს

სახელი აღწერს კონსტრუქციას: HTTPS სესიის შიგნით გადატანილი PPP ჩარჩოები, რაც ნიშნავს TLS-ს ქვემოთ და სერტიფიკატს, რომლის შემოწმებაც კლიენტს შეუძლია. Windows ამას მშობლიურ VPN ტიპად მოიცავს, ამიტომ მართული ლეპტოპი ხშირად შეიძლება დაუკავშირდეს ოპერატორის მიერ მოწოდებული პროფილის გარდა დამატებითი პროგრამის გარეშე.

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

SSTP ჩვეულებრივ მხოლოდ TCP-ა. ეს ერთი ტრანსპორტი გავლენას ახდენს იმაზე, როგორ იქცევა დანაკარგებიან ხაზზე, რადგან ხელახალი გაგზავნა ხდება ტუნელის შიგნითაც და მის ქვეშაც.

OpenVPN თავის კლიენტს და ტრანსპორტის არჩევანს მოაქვს

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

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

UDP ჩვეულებრივი ნაგულისხმევია, რადგან თავს არიდებს საიმედო ნაკადის სხვა საიმედო ნაკადში ჩადგმას. TCP რეჟიმი არსებობს იმ ქსელებისთვის, რომლებიც UDP-ს ბლოკავენ, და ის მუშაობს, მაგრამ მძიმე დანაკარგმა შეიძლება ის უფრო უარესად აგრძნობინოს, ვიდრე ის UDP გზა, რომელიც მან შეცვალა. აირჩიეთ TCP, როცა აუცილებელია, და არა იმიტომ, რომ უფრო საიმედოდ ჟღერს.

აირჩიეთ კლიენტის, ტრანსპორტისა და მხარდაჭერის მიხედვით

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

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

შემდეგ დაადასტურეთ, რომელი დაამყარეთ სინამდვილეში, სანამ რაიმე სხვას გამართავთ:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

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

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