რატომ SSL VPN და საიტ-საიტ VPN ერთმანეთის საპირისპირო არ არის
SSL VPN და საიტ-საიტ VPN სხვადასხვა ღერძს აღწერენ: ვინ უერთდება ქსელს და როგორ შენდება გვირაბი. ორივეს ერთად დასახელება კატეგორიის შეცდომაა.
სთხოვეთ ორ ადმინისტრატორს აღწერონ ერთი და იგივე VPN, და ერთმა შეიძლება უპასუხოს „SSL VPN“, მეორემ კი თქვას „საიტ-საიტ“, თითქოს ორივე მენიუში კონკურენტი ვარიანტი იყოს. ეს სხვადასხვა კითხვის პასუხია და მათ ალტერნატივად მოპყრობა წარმოშობს შედარებებს, რომლებიც ვერ გადაწყდება. ერთი ეტიკეტი ამბობს, რომელი ბოლო წერტილები ერთდება; მეორე ამბობს, რა ატარებს ტრაფიკს მათ შორის. ღერძები ცალ-ცალკე შეინახეთ და კამათის უმეტესი ნაწილი გაქრება.
ორი ეტიკეტი, ორი ცალკე კითხვა
ტოპოლოგია პასუხობს, ვინ უერთდება რას. დისტანციური წვდომის დიზაინი ცალკეულ მომხმარებლებს ან მოწყობილობებს აკავშირებს კარიბჭესთან, ჩვეულებრივ მომხმარებლის იდენტობითა და მისამართების აუზით. საიტ-საიტ დიზაინი ორ ქსელს აკავშირებს კარიბჭეების მეშვეობით, ამიტომ საინტერესო იდენტობა პარტნიორი კარიბჭეა და არა კლავიატურის წინ მჯდომი ადამიანი. ეს სხვადასხვა ოპერაციული პრობლემაა: მისამართების დაგეგმვიდან იმამდე, თუ ვის შეუძლია წვდომის გაუქმება ღამის 2 საათზე.
მექანიზმი პასუხობს, როგორ შენდება და ავთენტიფიცირდება გვირაბი. IPsec IKEv2-ით, TLS-ზე დაფუძნებული პროდუქტი, რომელიც შიგნით ატარებს IP-ს, და ბრაუზერისკენ მიმართული აპლიკაციის პორტალი მექანიზმის არჩევანია, და თითოეულს თავისი მოლაპარაკება, შიფრის კომპლექტები და წარუმატებლობის რეჟიმები აქვს. არცერთი მათგანი არ გულისხმობს ტოპოლოგიას, და ტოპოლოგია მექანიზმს არ ირჩევს.
ორი ღერძი ერთ ცხრილში მოათავსეთ და დაბნეულობა გამოჩნდება, რადგან ბადის ყველა უჯრა შეიძლება აივსოს. რაც ცხრილმა ვერ გააკეთა, არის იმის თქმა, თუ რომელი კომბინაცია მოგაწოდათ თქვენმა მომწოდებელმა, რადგან პროდუქტის სახელები ორივე ღერძს ერთ მარკეტინგულ ფრაზაში აწურებენ.
საიდან მოდის კატეგორიის შეცდომა
მომწოდებლები წლების განმავლობაში ყიდდნენ „SSL VPN“-ს როგორც „IPsec VPN“-ის საპირისპიროს, რაც მექანიზმების შედარებას ტოპოლოგიის არჩევნის მსგავსად აჩვენებდა. ფრაზა საკუთარი პირობებითაც ცუდად დაბერდა, რადგან დღევანდელი დიზაინები იყენებენ მხარდაჭერილ TLS ვერსიებს და SSL სახელი ძირითადად პროდუქტის კატეგორიად რჩება.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
იგივე შეკუმშვიდან გამომდინარეობს ორი დაკავშირებული მითი. პირველია, რომ IPsec ნიშნავს საიტ-საიტს; IKEv2 შექმნილია კლიენტ-კარიბჭის ურთიერთობებისთვისაც, ამიტომ ცალკე ლეპტოპი შეიძლება IPsec-ით შეუერთდეს. მეორეა, რომ TLS-ზე დაფუძნებული პროდუქტი მხოლოდ დისტანციურ წვდომას ნიშნავს; OpenVPN რეგულარულად გამოიყენება ორ საიტს შორის ტრაფიკის გადასატანად, და მისი TLS გამოყენება კონცენტრირებულია კონტროლისა და ავთენტიფიკაციის გაცვლაში და არა ბრაუზერის სესიაში.
სასარგებლო ტესტი ნებისმიერი აღწერისთვის: თუ ერთი სიტყვის შეცვლა ცვლის როგორც ბოლო წერტილებს, ისე პროტოკოლს, წინადადება ღერძებს ურევს. „SSL VPN საიტ-საიტის წინააღმდეგ“ ამ ტესტს ვერ გადის, რადგან პირველი ტერმინი მექანიზმების ოჯახს ასახელებს, მეორე კი ტოპოლოგიას.
აღწერეთ განლაგება ისე, რომ შესადარებელი იყოს
დაწერეთ ოთხი ველი და შეავსეთ: ბოლო წერტილები, მექანიზმი, ავთენტიფიკაცია და წვდომის ზედაპირი. ფილიალის კავშირი შეიძლება წაიკითხოს როგორც IKEv2 კარიბჭეების წყვილი ორ დასახელებულ პრეფიქსს შორის სერტიფიკატით ავთენტიფიკაციით და მომხმარებლის დონის პორტალის გარეშე. დისტანციური წვდომის სერვისი შეიძლება წაიკითხოს როგორც TLS-ზე დაფუძნებული კლიენტი, რომელიც ანიჭებს მისამართებს თითოეულ მომხმარებელს, მოითხოვს მეორე ფაქტორს შესვლისას და აქვეყნებს მხოლოდ შიდა DNS ზონას.
ეს წინადადებები შესადარებელია იმგვარად, როგორც პროდუქტის სახელები არ არის. დისტანციური წვდომის ორი დიზაინი შეიძლება გაიზომოს ერთი და იმავე მომხმარებლის სამუშაო ნაკადისა და გაუქმების ერთი და იმავე გზის წინააღმდეგ, ხოლო საიტებს შორის ორი დიზაინი ერთი და იმავე პრეფიქსების სიის, ტრაფიკის პოლიტიკისა და წარუმატებლობის მოთხოვნების წინააღმდეგ. ეტიკეტები აწყობენ შედარებას; ისინი არ ცვლიან მას.
ტერმინოლოგიას ასევე აქვს გამოქვეყნებული საყრდენი. IETF-ის VPN ტერმინოლოგიის დოკუმენტი გამოყოფს რამდენიმე მომსახურების მოდელს, მათ შორის დისტანციურ წვდომასა და საიტ-საიტს, იმ მექანიზმებისგან, რომლითაც ისინი შენდება, და ეს არის ზუსტად ის განსხვავება, რომელიც გამუდმებით იკარგება.
წაიკითხეთ მოლაპარაკებული პროტოკოლი და არა პროდუქტის სახელი
ყუთზე არსებული ეტიკეტი არ ადგენს, რაზე შეთანხმდა მოქმედი გვირაბი. ჰკითხეთ პარტნიორს პირდაპირ, TLS მხარეს, და წაიკითხეთ ხელის ჩამორთმევით წარმოქმნილი პროტოკოლის ვერსია და შიფრი და არა ბროშურაში მოცემული ვერსია.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsec კარიბჭისთვის ეკვივალენტური დაკვირვება მოდის თავად იმპლემენტაციის სტატუსის გამოსავლიდან, რომელიც იტყობინება გამოყენებული IKE და ESP შეთავაზებების შესახებ. ყოველ შემთხვევაში, არსი იგივეა: მექანიზმის ღერძი უნდა წაიკითხოს ცოცხალი სესიიდან, რადგან კლიენტი და კარიბჭე შეიძლება შეთანხმდნენ უფრო ძველზე, ვიდრე რომელიმე ადმინისტრატორი ელოდა.
ipsec statusall | grep -E "IKE|ESP"ამის შემდეგ რჩება კითხვები, რომლებზეც არც ერთი ეტიკეტი არ პასუხობს. რომელი პროტოკოლის ვერსიები ჯერ კიდევ მიიღება, როგორ მოწმდება კარიბჭის იდენტობა, რომელი ალგორითმების ნაკრებია დაშვებული, ვინ ანიჭებს უფლებას მოცემულ მომხმარებელს მოცემულ რესურსზე და რა აუქმებს წვდომას მოწყობილობის დაკარგვისას. ტოპოლოგიის დიაგრამა და მექანიზმის სახელი ამ სიის დასაწყისია და არა მისი შემცვლელი.
ამიტომ შეინახეთ ორი ეტიკეტი, მაგრამ გამოიყენეთ ისინი იმისთვის, რაც არიან: მოკლე გზა იმის სათქმელად, თუ რომელი ბოლო წერტილები ერთდება და როგორ შენდება გვირაბი. იმ წუთას, როცა ერთი მეორის გამოსარიცხად გამოიყენება, აღწერამ შეწყვიტა რაიმეს აღწერა.