AWS Client VPN czy VPN na EC2: podręcznik operacyjny

Oba warianty dają zespołowi VPN dostępu zdalnego, więc ciekawe pytanie nie brzmi, który istnieje, ale który potraficie utrzymać. Różnica polega na tym, kto jest właścicielem punktu końcowego o 3 w nocy i do jakich mechanizmów sterowania dotrzecie, gdy coś się zepsuje. Przejdźcie pięć kroków poniżej po kolei, bo każdy może wcześniej zakończyć porównanie. Pominięcie kroku inwentaryzacji to właśnie sposób, w jaki zespoły migrują dwa razy.

Krok 1: zapiszcie wymaganie przed rachunkiem

Potrzebujecie pięciu faktów na jednej stronie: kto i wobec czego się uwierzytelnia, które platformy klienckie muszą działać, które cele prywatne są osiągalne, jaką dostępność obiecaliście i jak ruch wygląda naprawdę. Bez tego każde późniejsze porównanie zamienia się w spór o listę funkcji.

Bądźcie konkretni co do celów. „Dostęp do VPC” zwykle oznacza trzy różne rzeczy: CIDR VPC, sieć połączoną peeringiem i zakres lokalny za Transit Gateway. Zarządzany punkt końcowy osiąga wszystkie trzy, ale każdy wymaga trasy i reguły autoryzacji, a każdy jest osobnym wierszem w waszym wymaganiu.

Krok 2: wypiszcie to, co już działa

Zanim cokolwiek zaprojektujecie, wypiszcie istniejące punkty końcowe i każdy serwer hostowany na EC2 wraz z jego grupami zabezpieczeń. Te wywołania są tylko do odczytu i bezpieczne z konta z uprawnieniami describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Czytajcie wynik jako mapę tego, do czego klienci już docierają. Brakująca reguła autoryzacji wyjaśnia awarię, która wygląda jak problem z routingiem, a punkt końcowy powiązany z jedną podsiecią wyjaśnia, dlaczego awaria strefy położyła całą usługę.

Zapiszcie też grupy zabezpieczeń przypięte do każdej własnej instancji. Te reguły są częścią modelu dostępu i są pierwszą rzeczą, która po cichu się psuje, gdy ktoś odtwarza instancję z szablonu.

Krok 3: podzielcie odpowiedzialność

Usługa zarządzana jest właścicielem floty punktów końcowych, jej łatania i dostępności w regionie. Wy jesteście właścicielami rejestracji tożsamości, reguł autoryzacji, ścieżek sieciowych za punktem końcowym, konfiguracji logowania i decyzji, ile podsieci podłączyć.

Hostowanie własne odwraca to. Wy jesteście właścicielami systemu operacyjnego gościa, demona VPN i jego konfiguracji, certyfikatów i kluczy, kopii zapasowych, monitorowania i odtwarzania. Model bezpieczeństwa EC2 przenosi bezpieczeństwo gościa i aplikacji na klienta, a serwer VPN jest gościem jak każdy inny.

Zapiszcie podział jako tabelę z nazwiskami w prawej kolumnie. Jeśli obok odnawiania certyfikatów nie pojawi się niczyje nazwisko, to jest właśnie ustalenie i waży więcej niż różnica godzinowa.

Krok 4: porównajcie z obciążeniem, które umiecie opisać

Koszt idzie za kształtem, nie za rozmiarem. Dla wariantu zarządzanego policzcie godziny powiązania punktów końcowych, godziny połączeń klientów, transfer oraz włączone usługi tożsamości i logowania. Dla hostowania własnego policzcie moc obliczeniową, pamięć masową, sieć, licencje i czas inżynierów, który utrzymuje serwer w stanie załatania. Umieśćcie oba zestawy liczb w jednym arkuszu o tym samym horyzoncie czasowym. Trzyletnie porównanie, które pomija godziny łatania, zawsze będzie faworyzować serwer, który już macie.

Porównania wydajności wymagają tej samej dyscypliny. Jedna interaktywna sesja pulpitu, jeden duży transfer i pięćdziesiąt równoczesnych małych żądań obciążają różne części ścieżki: procesor do szyfrowania, możliwości sieciowe instancji, własny stos klienta i miejsce docelowe. Testujcie z reprezentatywnymi klientami i tym samym zadaniem w obu projektach.

Większa instancja nie jest dowodem, że transfer będzie szybszy, a jedna udana sesja nie jest planem pojemności. Każde odziedziczone opowieści o rodzinach instancji traktujcie jako hipotezę do sprawdzenia, nie jako regułę zakupową.

Krok 5: przełączcie się z wycofaniem, które już przećwiczyliście

Uruchomcie oba punkty końcowe równolegle przez określony czas, najpierw rozdajcie nowy profil klienta małej grupie i nie ruszajcie reguł autoryzacji starego punktu końcowego, dopóki grupa nie użyje nowego w rzeczywistej pracy. Wycofanie to zmiana profilu, nie przebudowa, więc zdecydujcie teraz, gdzie mieszka stary profil.

Sprawdzajcie w tej kolejności: uwierzytelnianie się udaje, klient otrzymuje oczekiwane trasy, autoryzowany cel odpowiada, a nieautoryzowany cel zawodzi, i logi pokazują oba zdarzenia. Jeśli którykolwiek krok zawiedzie, zatrzymajcie się i naprawcie ten krok, zamiast przechodzić do następnej grupy klientów. Zapisujcie wynik każdego sprawdzenia, bo przełączenia pamiętanego tylko jako „zadziałało” nie da się zdebugować miesiąc później.

Po przełączeniu zaplanujcie nudne kontrole: wygaśnięcie certyfikatów, liczbę powiązań, reguły autoryzacji, które nie pasują już do grupy, oraz liczbę połączeń wobec waszych oczekiwań. Przewodnik administracji Client VPN jest referencją dla skonfigurowanych przez was części punktu końcowego, uwierzytelniania i routingu.