AWS Client VPN თუ Site-to-Site: შეამოწმეთ, ვინ ხსნის კავშირს
Client VPN ამოწმებს მოწყობილობას ან მომხმარებელს; Site-to-Site აკავშირებს კარიბჭეს AWS-თან. ოთხი შემოწმება განსაზღვრავს, რომელი სჭირდება თქვენს ლეპტოპს ან ფილიალს.
ამას ოთხი შემოწმება წყვეტს და არც ერთი მათგანი პროტოკოლის სახელი არ არის. ვინ ხსნის კავშირს, რას ამოწმებს AWS, როგორ უერთდება კავშირი თქვენს ქსელს და რა მარშრუტიზაცია და პოლიტიკა მოდის მასთან ერთად. უპასუხეთ მათ რიგრიგობით და პროდუქტის არჩევანი ჩვეულებრივ თავისით ხდება; უპასუხეთ მას შემდეგ, რაც უკვე იყიდეთ დიზაინი და თქვენ დაიცავთ გვირაბს, რომელიც პრობლემის არასწორ ნახევარს წყვეტს. ოთხიდან არც ერთი არ გთხოვთ შიფრის არჩევას, ამიტომაც პროტოკოლით დაწყებული დიზაინი ჩვეულებრივ ნიშანია იმისა, რომ მოთხოვნები არასოდეს დაწერილა.
ყოველი შემოწმება ჩაატარეთ იმ რეალური ბოლო წერტილის, კლიენტისა და მისამართების ოჯახის მიმართ, რომელთა გამოყენებასაც გეგმავთ და არა კატეგორიის მიმართ. მართული VPN პროდუქტები განსხვავდება იმ OpenVPN და IPsec სამშენებლო ბლოკებისგან, რომლებსაც ჰგვანან.
პირველი, ვინ ხსნის კავშირს
თუ ის, რასაც წვდომა სჭირდება, ლეპტოპი, ტელეფონი ან ერთი ადმინისტრატორის სამუშაო სადგურია, კავშირი იწყება დისტანციური მოწყობილობიდან და დიზაინი დისტანციური კლიენტის წვდომაა. თუ ის, რასაც წვდომა სჭირდება, ერთი მარშრუტიზატორის უკან მანქანებით სავსე ფილიალია, კავშირი იწყება ამ მარშრუტიზატორიდან და დიზაინი კარიბჭე-კარიბჭისაა. ეს არის ის შემოწმება, რომელიც უმეტეს შემთხვევას წყვეტს და სწორედ მას გამოტოვებენ, როცა მომწოდებლის პრეზენტაციამ საუბარი უკვე შიფრების გარშემო ჩამოაყალიბა.
აქ გაჩერდით, თუ ვერ ასახელებთ იმ კომპონენტს, რომელიც იწყებს. დიზაინი, რომელიც ერთი გვირაბით ორივე შემთხვევის მომსახურებას ცდილობს, ჩვეულებრივ მთავრდება კლიენტის სესიით, რომელიც თავს კარიბჭედ აჩვენებს.
მეორე, რას ამოწმებს AWS
Client VPN-ის შემთხვევაში AWS ამოწმებს კონფიგურირებულ კლიენტის ან მომხმარებლის იდენტობას: სერტიფიკატებს, კატალოგს ან ფედერაციულ იდენტობას, კონფიგურაციის მიხედვით. Site-to-Site VPN-ის შემთხვევაში AWS ამოწმებს კარიბჭის პარტნიორის იდენტობას. ეს განსხვავება კოსმეტიკური არ არის. ერთი მოდელი მასშტაბირდება მომხმარებლების დამატებითა და მათი სერტიფიკატების გაუქმებით; მეორე — იმის ნდობით, რაც ერთი კარიბჭის უკან დგას.
კარიბჭის ავთენტიფიკაცია არ ამოწმებს მის უკან მდგარ ყოველ თანამშრომელს ან აპლიკაციას, ამიტომ შეინარჩუნეთ აპლიკაციების იდენტობები და რესურსის დონის წვდომა მაშინაც, როცა თავად გვირაბი სანდოდ ითვლება. ფილიალი, რომლის მარშრუტიზატორსაც სწორი პარტნიორის იდენტობა აქვს, ავტომატურად არ უნდა წაიკითხოს ისე, თითქოს ამ შენობის ყოველი მაგიდა ავტორიზებულია.
მესამე, როგორ უერთდება კავშირი
Client VPN უერთდება VPC ქვექსელის ასოციაციებით ან მხარდაჭერილი პირდაპირი Transit Gateway მიმაგრებით. Site-to-Site VPN უერთდება AWS VPN მიზანს, ჩვეულებრივ ვირტუალურ კერძო კარიბჭეს ან Transit Gateway-ს. Client VPN-ის არქიტექტურის სახელმძღვანელო აღწერს Transit Gateway-ის ვარიანტს და მისი არსებობა ლეპტოპის სესიას ფილიალის კარიბჭედ არ აქცევს და ზემოთ აღწერილ კლიენტის ავთენტიფიკაციასა და ავტორიზაციას არ აშორებს.
შეამოწმეთ, რომელ მიმაგრებას უჭერს მხარს თქვენი ანგარიში და რეგიონი სინამდვილეში, სანამ მის გარშემო მარშრუტებს დააპროექტებთ, შემდეგ შეამოწმეთ, ვის ეკუთვნის ეს მიმაგრება. ვარიანტი, რომელიც დოკუმენტაციაში არსებობს, მაგრამ ქსელში ზის, რომელსაც ვერ დააკონფიგურირებთ, ვარიანტი არ არის.
მეოთხე, რა მარშრუტიზაცია და პოლიტიკა მოდის მასთან ერთად
Client VPN მოაქვს კლიენტის კავშირების მართვა და ავტორიზაციის წესები იმ დანიშნულების ქსელებისთვის, რომლებსაც ნებას რთავთ. დაკავშირებულ მომხმარებელს მაინც სჭირდება განზრახული ბოლო წერტილის მარშრუტი, მისი დამშვები ავტორიზაციის წესი და ის წვდომა, რომელსაც თავად რესურსი ითხოვს. Site-to-Site VPN მარშრუტიზაციას ახდენს მომხმარებლის კარიბჭით წარმოდგენილ ქსელებს შორის, დიზაინის მიხედვით მხარდაჭერილი სტატიკური მარშრუტებით ან BGP-ით, ამიტომ ფილიალის მარშრუტიზატორის უკან მდგარ თითოეულ მანქანას კლიენტის შესვლა არ სჭირდება.
არც ერთი მიმართულებით ნუ გამოიტანთ კატეგორიიდან არამხარდაჭერილ ქცევას. დისტანციური წვდომის VPN-ები უნივერსალურად უძლური არ არიან დააბრუნონ ტრაფიკი ან დაუჭირონ მხარი კარიბჭის სქემებს და IPsec ავტომატურად არ იბლოკება NAT-ით — AWS აღწერს NAT-ის გავლას და მომხმარებლის კარიბჭის მოთხოვნებს და ნამდვილი შეზღუდვა მხარდაჭერილი კარიბჭის კონფიგურაციაა. შეამოწმეთ თქვენი ბოლო წერტილის შეზღუდვები, სანამ კლიენტებისკენ დაწყებულ კავშირებს მოითხოვთ ან ერთი სესიის უკან LAN-ს გადაამისამართებთ. იგივე სიფრთხილე ეხება მისამართების ოჯახებს: IPv4-ზე მომუშავე ბოლო წერტილი IPv6 გზას არ ნიშნავს, ამიტომ დაადასტურეთ ის ოჯახი, რომელზეც თქვენი კლიენტი ან კარიბჭე რეალურად იმოლაპარაკებს.
Site-to-Site VPN თითოეულ კავშირზე ორ გვირაბს გაძლევთ და ეს სიჭარბე დიზაინის ამოცანაა და არა ფუნქცია, რომლის ჩავარდნაც შეიძლება. მომხმარებლის კარიბჭის მუშაობა, მარშრუტების გადართვა ჩავარდნისას და ტესტური დაფარვა ყველა უნდა დაიგეგმოს; ერთი ლეპტოპის სესიის შედარება აბსტრაქტულ VPN სერვერთან არაფერს ამტკიცებს არც ერთ მათგანზე.
სად ხვდება ორი დიზაინი
სერვისები ერთმანეთს არ გამორიცხავს და ჩვეულებრივი წარმოების ფორმა ორივეს იყენებს: თანამშრომლები Client VPN-ზე, ფილიალების ქსელები Site-to-Site-ზე, ცხადი მარშრუტებით და წვდომის პოლიტიკით იმ დანიშნულებებს შორის, რომლებმაც უნდა ისაუბრონ. ცხრილი ოთხი შემოწმების შეჯამებაა და არა მათი შესრულების შემცვლელი.
| Question | AWS Client VPN | AWS Site-to-Site VPN |
|---|---|---|
| Who establishes it? | A client on a remote device | A customer gateway device or appliance |
| What is authenticated? | The client or user identity | The gateway peer identity |
| How does it attach? | VPC subnet association or Transit Gateway | Virtual private gateway or Transit Gateway |
| What carries the path? | An OpenVPN-based client tunnel | IPsec tunnels to AWS endpoints |
ერთი რამ, რასაც არც ერთი პროდუქტი არ ცვლის: TLS იმ აპლიკაციისკენ, რომლის დაშიფვრის მოთხოვნაც VPN-ის ბოლო წერტილს სცდება. თუ თქვენი შესაბამისობის არეალი აპლიკაციაზე მთავრდება, გვირაბი ტრანსპორტია და სერტიფიკატი კვლავ კონტროლია.
ჩამოწერეთ ოთხი პასუხი დიზაინის განხილვამდე, თითო ხაზში. როცა ორი მათგანი ეწინააღმდეგება ერთმანეთს — ვთქვათ, მომხმარებლით ავთენტიფიცირებული კლიენტის დიზაინი და ფილიალის ზომის მარშრუტიზაციის მოთხოვნა — სწორედ ეს წინააღმდეგობაა აღმოჩენა და მისი ახლა დანახვა უფრო იაფია, ვიდრე გადასვლის დროს.