AWS Client VPN czy Site-to-Site: sprawdź, kto otwiera połączenie

Rozstrzygają to cztery kontrole i żadna z nich nie jest nazwą protokołu. Kto otwiera połączenie, co uwierzytelnia AWS, jak połączenie podłącza się do twojej sieci oraz jakie routowanie i polityka mu towarzyszą. Odpowiedz na te pytania po kolei, a wybór produktu zwykle dokona się sam; odpowiedz po kupieniu projektu i będziesz bronić tunelu, który rozwiązuje niewłaściwą połowę problemu. Żadna z czterech nie każe ci wybrać szyfru, dlatego projekt zaczynający się od protokołu jest zwykle znakiem, że wymagania nigdy nie zostały spisane.

Każdą kontrolę przeprowadź wobec rzeczywistego punktu końcowego, klienta i rodziny adresów, których zamierzasz używać, a nie wobec kategorii. Zarządzane produkty VPN różnią się od klocków OpenVPN i IPsec, do których są podobne.

Po pierwsze, kto otwiera połączenie

Jeśli tym, co potrzebuje dostępu, jest laptop, telefon lub stacja robocza jednego administratora, połączenie zaczyna się na urządzeniu zdalnym, a projektem jest dostęp zdalnego klienta. Jeśli tym, co potrzebuje dostępu, jest oddział pełen maszyn za jednym routerem, połączenie zaczyna się na tym routerze, a projektem jest brama do bramy. To kontrola, która rozstrzyga większość przypadków, i to ją ludzie pomijają, gdy prezentacja dostawcy już ujęła rozmowę w ramy wokół szyfrów.

Zatrzymaj się tutaj, jeśli nie potrafisz nazwać komponentu, który inicjuje połączenie. Projekt, który próbuje obsłużyć oba przypadki jednym tunelem, zwykle kończy się sesją klienta udającą bramę.

Po drugie, co uwierzytelnia AWS

W Client VPN AWS uwierzytelnia skonfigurowaną tożsamość klienta lub użytkownika: certyfikaty, katalog lub tożsamość federacyjną, zależnie od konfiguracji. W Site-to-Site VPN AWS uwierzytelnia tożsamość partnera bramy. Ta różnica nie jest kosmetyczna. Jeden model skaluje się przez dodawanie użytkowników i odbieranie im poświadczeń; drugi przez zaufanie do wszystkiego, co stoi za jedną bramą.

Uwierzytelnienie bramy nie uwierzytelnia każdego pracownika ani aplikacji za nią, więc utrzymuj tożsamości aplikacji i dostęp na poziomie zasobów, nawet gdy sam tunel jest zaufany. Oddział, którego router ma ważną tożsamość partnera, nie powinien być automatycznie czytany tak, jakby każde biurko w tym budynku było upoważnione.

Po trzecie, jak połączenie się podłącza

Client VPN podłącza się przez skojarzenia podsieci VPC lub obsługiwane bezpośrednie przyłączenie Transit Gateway. Site-to-Site VPN podłącza się do celu AWS VPN, zwykle wirtualnej bramy prywatnej lub Transit Gateway. Przewodnik po architekturze Client VPN dokumentuje opcję Transit Gateway, a jej istnienie nie zamienia sesji laptopa w bramę oddziału ani nie usuwa opisanych wyżej uwierzytelnienia i autoryzacji klienta.

Sprawdź przyłączenie, które twoje konto i region rzeczywiście obsługują, zanim zaprojektujesz wokół niego trasy, a potem sprawdź, do kogo należy to przyłączenie. Opcja, która istnieje w dokumentacji, ale znajduje się w sieci, której nie możesz skonfigurować, nie jest opcją.

Po czwarte, jakie routowanie i polityka mu towarzyszą

Client VPN wnosi zarządzanie połączeniami klientów i reguły autoryzacji dla sieci docelowych, które zezwalasz. Połączony użytkownik nadal potrzebuje zamierzonej trasy do punktu końcowego, reguły autoryzacji, która na nią pozwala, oraz dostępu, którego wymaga sam zasób. Site-to-Site VPN routuje między sieciami reprezentowanymi przez bramę klienta, używając obsługiwanych tras statycznych lub BGP w zależności od projektu, więc poszczególne maszyny za routerem oddziału nie potrzebują każda własnego logowania klienta.

Nie wnioskuj o nieobsługiwanym zachowaniu z kategorii w żadną stronę. VPN dostępu zdalnego nie są uniwersalnie niezdolne do przenoszenia ruchu powrotnego ani do obsługi układów z bramą, a IPsec nie jest automatycznie blokowany przez NAT — AWS dokumentuje przechodzenie przez NAT i wymagania dotyczące bramy klienta, a rzeczywistym ograniczeniem jest obsługiwana konfiguracja bramy. Sprawdź ograniczenia swojego punktu końcowego, zanim zażądasz połączeń inicjowanych w stronę klientów albo przekażesz LAN za jedną sesją. Ta sama ostrożność dotyczy rodzin adresów: punkt końcowy działający przez IPv4 nie oznacza ścieżki IPv6, więc potwierdź rodzinę, o której twój klient lub brama rzeczywiście będą negocjować.

Site-to-Site VPN daje dwa tunele na połączenie, a ta nadmiarowość jest zadaniem projektowym, a nie funkcją, którą można założyć. Eksploatacja bramy klienta, przełączanie tras przy awarii i pokrycie testami muszą być zaplanowane; porównanie jednej sesji laptopa z abstrakcyjnym serwerem VPN niczego nie dowodzi o żadnym z nich.

Gdzie spotykają się oba projekty

Usługi się nie wykluczają, a typowa forma produkcyjna używa obu: pracownicy na Client VPN, sieci oddziałów na Site-to-Site, z jawnymi trasami i polityką dostępu między celami, które muszą się komunikować. Tabela jest podsumowaniem czterech kontroli, a nie zamiennikiem ich przeprowadzenia.

Jedna rzecz, której nie zastępuje żaden z dwóch produktów: TLS do aplikacji, której wymóg szyfrowania wykracza poza punkt końcowy VPN. Jeśli zakres zgodności kończy się na aplikacji, tunel jest transportem, a certyfikat nadal jest kontrolą.

Zapisz cztery odpowiedzi przed przeglądem projektu, każdą w jednej linii. Gdy dwie z nich się nie zgadzają — na przykład projekt klienta z uwierzytelnianiem użytkownika i wymóg routowania w skali oddziału — ta sprzeczność jest ustaleniem, a taniej zobaczyć ją teraz niż podczas przełączenia.