EC2 Windows: klient VPN, serwer VPN czy brama AWS?
Instancja EC2 z Windows może uruchamiać oprogramowanie VPN, ale klient, samodzielnie zarządzany serwer i brama AWS to różne role z różnymi właścicielami.
Zespół potrzebuje łączności VPN dla aplikacji działającej na instancji EC2 z Windows, znajduje zgodne oprogramowanie klienckie, instaluje je, a potem pyta, dlaczego reszta VPC nie może go używać. Instalacja się udała; rola nigdy nie została ustalona. Oprogramowanie działające w gościu może być klientem dołączającym do czyjejś sieci, serwerem przyjmującym innych klientów albo żadnym z produktów VPN zarządzanych przez AWS, a każda rola zostawia ci inną pracę.
Objawem jest zwykle niewłaściwa rola
Typowym objawem jest działający tunel, który rozwiązuje niewłaściwy problem. Klient w maszynie wirtualnej daje jej ścieżkę wyjściową; nie daje laptopowi, biuru ani innej podsieci drogi do środka. Serwer w maszynie wirtualnej daje innym drogę do środka, ale teraz ty odpowiadasz za nasłuchiwacz, uwierzytelnianie i przekazywanie.
Usługi zarządzane przenoszą eksploatację usługi do AWS i zostawiają projektowanie tobie. Site-to-Site VPN łączy sieci przez bramę klienta i bramę AWS, a Client VPN daje urządzeniom zdalnym zarządzany punkt końcowy. W obu przypadkach trasy, reguły autoryzacji i źródło tożsamości to twoja konfiguracja, a żaden z produktów nie instaluje klienta ogólnego przeznaczenia w gościu Windows.
Możliwe są cztery kształty, a tabela rozdziela je według tego, co z czym się łączy i kto niesie obciążenie operacyjne.
| 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 |
Czytaj wiersz, a nie nazwę produktu: ta sama instancja Windows może stać w dwóch różnych wierszach w zależności od tego, jakie oprogramowanie w niej działa.
Klient w maszynie wirtualnej: maszyna dołącza do sieci
Klient wychodzący musi mieć sprawdzoną kompilację Windows, architekturę i wymagania sterowników, zanim cokolwiek zostanie zainstalowane. Klient zmieni trasy i DNS na instancji, co może wpłynąć na usługi już tam działające, w tym na ścieżkę używaną do administracji zdalnej. Zapisz nazwę adaptera i metrykę interfejsu ustawianą przez klienta, ponieważ nowy interfejs może uzyskać pierwszeństwo przed istniejącym. Jeśli instancja jest zarządzana przez menedżera sesji zamiast przez SSH lub RDP, potwierdź, że ta ścieżka nadal działa po połączeniu klienta.
Zdecyduj, jaki ruch klient ma przenosić, zanim go włączysz. Pełny tunel może przechwycić sesję administracyjną i zablokować cię na zewnątrz, a tunel dzielony może pozwolić instancji dotrzeć do sieci prywatnej, podczas gdy jej pozostały ruch wychodzi inną drogą. Testuj z dostępną drugą ścieżką administracyjną i zapisuj trasy instalowane przez klienta, aby późniejsza zmiana była wytłumaczalna.
Serwer w maszynie wirtualnej: inni klienci dołączają do niego
W przypadku serwera zarządzanego samodzielnie ty odpowiadasz za nasłuchiwacz, certyfikat lub materiał klucza, bazę użytkowników i reguły przekazywania. Jeśli serwer przekazuje ruch dla innych klientów, instancja staje się routerem, a to wymaga przekazywania na poziomie gościa oraz zmian tras i grup zabezpieczeń na poziomie AWS.
Sprawdź nasłuchiwacz z gościa i ponownie z innej podsieci, a następnie sprawdź host, do którego instancja przekazuje. Zdrowa usługa lokalna niczego nie dowodzi o przekazywanej ścieżce, więc zapisz oba wyniki w notatce o zmianie.
Zarządzane bramy zachowują usługę, a nie twój projekt dostępu
AWS Site-to-Site VPN dokumentuje role tuneli bramy klienta i bramy AWS, a zakup tego połączenia nie zastępuje każdego projektu dostępu zdalnego. Client VPN dokumentuje zarządzany punkt końcowy z personami klientów, podczas gdy reguły autoryzacji i trasy docelowe pozostają twoje. AWS utrzymuje punkt końcowy i jego certyfikaty w ruchu; kto może dotrzeć do której aplikacji, nadal jest regułą autoryzacji, którą piszesz i utrzymujesz.
Wybierz między produktami na pięciu osiach: jaką rolę pełni każdy, jakie protokoły akceptuje, jakiego źródła tożsamości oczekuje, jak przekazywany jest ruch i jak dostarczana jest dostępność. Zignoruj każdą pojedynczą liczbę przepustowości cytowaną w wątku forum, ponieważ publikowana pojemność zmienia się wraz z usługą. I nie zakładaj, że zarządzana para tuneli zmienia zachowanie dowolnego klienta gościa.
Wybierz rolę przed produktem
Napisz jedno zdanie, które nazywa kierunek: ta maszyna dołącza do sieci, ta maszyna przyjmuje klientów albo brama AWS łączy zdefiniowane sieci.
To zdanie decyduje o krótkiej liście produktów, właścicielu oprogramowania i trybach awarii, które będziesz debugować. Jeśli wymaganiem jest, aby użytkownicy zdalni docierali do aplikacji, klient zainstalowany w maszynie wirtualnej aplikacji jest niewłaściwym kształtem. Jeśli wymaganiem jest, aby jedna maszyna docierała do sieci partnera, zarządzana brama lokacja-do-lokacji to więcej mechanizmów, niż potrzebuje zadanie. Obie odpowiedzi są zasadne; tylko jedna pasuje do zdania, które napisałeś.