EC2 Windows: VPN კლიენტი, VPN სერვერი თუ AWS კარიბჭე?
Windows EC2 ინსტანსს შეუძლია VPN პროგრამული უზრუნველყოფის გაშვება, მაგრამ კლიენტი, თვითმართული სერვერი და AWS კარიბჭე სხვადასხვა როლია სხვადასხვა მფლობელით.
გუნდს სჭირდება VPN კავშირი Windows EC2 ინსტანსზე მომუშავე აპისთვის, პოულობს თავსებად კლიენტურ პროგრამას, აყენებს მას და შემდეგ კითხულობს, რატომ ვერ იყენებს დანარჩენი VPC მას. ინსტალაციამ იმუშავა; როლი არასოდეს გადაწყვეტილა. სტუმრის შიგნით მომუშავე პროგრამა შეიძლება იყოს კლიენტი, რომელიც სხვის ქსელს უერთდება, სერვერი, რომელიც სხვა კლიენტებს იღებს, ან AWS-ის მიერ მართული VPN პროდუქტებიდან არცერთი, და თითოეული როლი განსხვავებულ სამუშაოს ტოვებს თქვენთან.
სიმპტომი ჩვეულებრივ არასწორი როლია
გავრცელებული სიმპტომია მომუშავე გვირაბი, რომელიც არასწორ პრობლემას წყვეტს. ვირტუალურ მანქანაში არსებული კლიენტი ამ მანქანას გამავალ გზას აძლევს; ის თქვენს ლეპტოპს, ოფისს ან სხვა ქვექსელს შემავალ გზას არ აძლევს. მანქანაში არსებული სერვერი სხვებს შემავალ გზას აძლევს, მაგრამ ახლა მსმენელი, ავთენტიფიკაცია და გადაცემა თქვენია.
მართული სერვისები სერვისის ოპერირებას AWS-ზე გადააქვს და დიზაინს თქვენთან ტოვებს. Site-to-Site VPN ქსელებს აკავშირებს მომხმარებლის კარიბჭისა და AWS კარიბჭის მეშვეობით, ხოლო Client VPN დისტანციურ მოწყობილობებს მართულ საბოლოო წერტილს აძლევს. ორივე შემთხვევაში მარშრუტები, ავტორიზაციის წესები და იდენტობის წყარო თქვენი კონფიგურაციაა და არცერთი პროდუქტი არ აყენებს ზოგადი დანიშნულების კლიენტს Windows სტუმრის შიგნით.
ოთხი ფორმა შესაძლებელია და ცხრილი მათ აცალკევებს იმის მიხედვით, რა რას უკავშირდება და ვინ ატარებს ოპერაციულ ტვირთს.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
წაიკითხეთ სტრიქონი და არა პროდუქტის სახელი: იგივე Windows ინსტანსი შეიძლება ორ სხვადასხვა სტრიქონში იყოს იმის მიხედვით, თუ რა პროგრამა მუშაობს მასში.
კლიენტი ვირტუალური მანქანის შიგნით: მანქანა ქსელს უერთდება
გამავალ კლიენტს სჭირდება Windows-ის ვერსიის, არქიტექტურისა და დრაივერის მოთხოვნების შემოწმება, სანამ რამე დაყენდება. კლიენტი შეცვლის მარშრუტებსა და DNS-ს ინსტანსზე, რაც შეიძლება იქ უკვე მომუშავე სერვისებზე იმოქმედოს, მათ შორის დისტანციური ადმინისტრირებისთვის გამოყენებულ გზაზე. ჩაწერეთ ადაპტერის სახელი და ინტერფეისის მეტრიკა, რომელსაც კლიენტი აყენებს, რადგან ახალმა ინტერფეისმა შეიძლება არსებულზე უპირატესობა მიიღოს. თუ ინსტანსი იმართება სესიის მენეჯერის მეშვეობით და არა SSH-ით ან RDP-ით, დაადასტურეთ, რომ ეს გზა კლიენტის დაკავშირების შემდეგაც მუშაობს.
გადაწყვიტეთ, რა ტრაფიკი უნდა ატაროს კლიენტმა, სანამ ჩართავთ. სრულმა გვირაბმა შეიძლება მართვის სესია დაიჭიროს და გარეთ ჩაკეტოს, ხოლო გაყოფილმა გვირაბმა შეიძლება ინსტანსს კერძო ქსელამდე მისვლა დაუშვას, სანამ მისი სხვა ტრაფიკი სხვა გასასვლელს იღებს. გამოსცადეთ მეორე მართვის გზის არსებობისას და ჩაწერეთ მარშრუტები, რომლებსაც კლიენტი აყენებს, რომ მოგვიანებით ცვლილება ახსნადი იყოს.
სერვერი ვირტუალური მანქანის შიგნით: სხვა კლიენტები მას უერთდებიან
თვითმართული სერვერისთვის მსმენელი, სერტიფიკატი ან გასაღების მასალა, მომხმარებლების მონაცემთა ბაზა და გადაცემის წესები თქვენია. თუ სერვერი სხვა კლიენტებისთვის ტრაფიკს გადასცემს, ინსტანსი როუტერად იქცევა და ეს მოითხოვს სტუმრის დონეზე გადაცემას და AWS-ის დონეზე მარშრუტებისა და უსაფრთხოების ჯგუფების ცვლილებებს.
შეამოწმეთ მსმენელი სტუმრიდან და შემდეგ სხვა ქვექსელიდან, შემდეგ შეამოწმეთ ჰოსტი, რომლისთვისაც ინსტანსი გადასცემს. ჯანსაღი ლოკალური სერვისი არაფერს ამტკიცებს გადაცემულ გზაზე, ამიტომ ორივე შედეგი ჩაწერეთ ცვლილების ჩანაწერში.
მართული კარიბჭეები ინარჩუნებენ სერვისს და არა თქვენს წვდომის დიზაინს
AWS Site-to-Site VPN აღწერს მომხმარებლის კარიბჭისა და AWS კარიბჭის გვირაბის როლებს და ამ კავშირის შეძენა არ ცვლის დისტანციური წვდომის ყველა დიზაინს. Client VPN აღწერს მართულ საბოლოო წერტილს კლიენტის პერსონებით, ხოლო ავტორიზაციის წესები და სამიზნე მარშრუტები თქვენი რჩება. AWS ინარჩუნებს საბოლოო წერტილსა და მის სერტიფიკატებს მუშა მდგომარეობაში; ვის რომელ აპზე შეუძლია მისვლა, კვლავ ავტორიზაციის წესია, რომელსაც თქვენ წერთ და ინარჩუნებთ.
აირჩიეთ პროდუქტებს შორის ხუთ ღერძზე: რა როლს თამაშობს თითოეული, რომელ პროტოკოლებს იღებს, რომელ იდენტობის წყაროს ელოდება, როგორ გადაეცემა ტრაფიკი და როგორ მიეწოდება ხელმისაწვდომობა. უგულებელყავით ფორუმის თემაში ციტირებული ნებისმიერი ერთი გამტარუნარიანობის რიცხვი, რადგან გამოქვეყნებული მოცულობა სერვისთან ერთად იცვლება. და ნუ ჩათვლით, რომ მართული გვირაბების წყვილი ცვლის თვითნებური სტუმარ-კლიენტის ქცევას.
აირჩიეთ როლი პროდუქტამდე
დაწერეთ ერთი წინადადება, რომელიც მიმართულებას ასახელებს: ეს ვირტუალური მანქანა ქსელს უერთდება, ეს მანქანა კლიენტებს იღებს, ან AWS კარიბჭე განსაზღვრულ ქსელებს აკავშირებს.
ეს წინადადება განსაზღვრავს პროდუქტების მოკლე სიას, პროგრამის მფლობელს და იმ მარცხის რეჟიმებს, რომლებსაც გამართავთ. თუ მოთხოვნაა, რომ დისტანციურმა მომხმარებლებმა აპამდე მიაღწიონ, აპის ვირტუალურ მანქანაში დაყენებული კლიენტი არასწორი ფორმაა. თუ მოთხოვნაა, რომ ერთმა მანქანამ პარტნიორის ქსელამდე მიაღწიოს, მართული საიტ-საიტ კარიბჭე უფრო მეტი მექანიზმია, ვიდრე დავალებას სჭირდება. ორივე პასუხი ლეგიტიმურია; მხოლოდ ერთი შეესაბამება თქვენ მიერ დაწერილ წინადადებას.