AWS Client VPN, nebo Site-to-Site: ověřte, kdo navazuje spojení

Rozhodují o tom čtyři kontroly a ani jedna z nich není název protokolu. Kdo spojení otevírá, co AWS autentizuje, jak se spojení připojuje k vaší síti a jaké směrování a zásady s ním přicházejí. Odpovězte na to v pořadí a volba produktu se obvykle udělá sama; odpovězte až poté, co jste už návrh koupili, a budete obhajovat tunel, který řeší špatnou polovinu problému. Ani jedna ze čtyř vás nežádá vybrat šifru, a proto je návrh začínající protokolem obvykle známkou toho, že požadavky nebyly nikdy sepsány.

Každou kontrolu proveďte proti skutečnému koncovému bodu, klientovi a rodině adres, kterou hodláte použít, ne proti kategorii. Spravované VPN produkty se liší od stavebních bloků OpenVPN a IPsec, kterým se podobají.

Za prvé, kdo spojení otevírá

Pokud je tím, co potřebuje přístup, notebook, telefon nebo pracovní stanice jediného správce, spojení začíná na vzdáleném zařízení a návrhem je vzdálený klientský přístup. Pokud je tím, co potřebuje přístup, pobočka plná strojů za jediným routerem, spojení začíná na tomto routeru a návrhem je brána k bráně. To je kontrola, která rozhoduje většinu případů, a právě ji lidé přeskakují, když prezentace dodavatele už zarámovala rozhovor kolem šifer.

Zastavte se zde, pokud nedokážete pojmenovat komponentu, která spojení iniciuje. Návrh, který se snaží obsloužit oba případy jediným tunelem, obvykle skončí klientskou relací, která předstírá, že je brána.

Za druhé, co AWS autentizuje

U Client VPN AWS autentizuje nakonfigurovanou klientskou nebo uživatelskou identitu: certifikáty, adresář nebo federovanou identitu, podle nastavení. U Site-to-Site VPN AWS autentizuje identitu partnerské brány. Ten rozdíl není kosmetický. Jeden model škáluje přidáváním uživatelů a odvoláváním jejich přihlašovacích údajů; druhý škáluje důvěrou ve vše, co stojí za jedinou bránou.

Autentizace brány neautentizuje každého zaměstnance ani aplikaci za ní, proto zachovejte identity aplikací a přístup na úrovni prostředků, i když je tunel sám považován za důvěryhodný. Pobočka, jejíž router má platnou identitu protějšku, by se neměla automaticky číst tak, že každý stůl v té budově je oprávněn.

Za třetí, jak se spojení připojuje

Client VPN se připojuje pomocí přidružení podsítí ve VPC nebo podporovaného přímého připojení k Transit Gateway. Site-to-Site VPN se připojuje k cíli AWS VPN, obvykle k virtuální privátní bráně nebo k Transit Gateway. Průvodce architekturou Client VPN dokumentuje volbu Transit Gateway a její existence nepromění relaci notebooku v pobočkovou bránu ani neodstraní výše popsanou autentizaci a autorizaci klienta.

Ověřte připojení, které váš účet a region skutečně podporují, než kolem něj navrhnete trasy, a poté ověřte, komu to připojení patří. Volba, která existuje v dokumentaci, ale leží v síti, kterou nemůžete konfigurovat, není volbou.

Za čtvrté, jaké směrování a zásady s ním přicházejí

Client VPN přináší správu klientských spojení a pravidla autorizace pro cílové sítě, které povolíte. Připojený uživatel stále potřebuje zamýšlenou trasu ke koncovému bodu, pravidlo autorizace, které ji povolí, a přístup, který vyžaduje sám prostředek. Site-to-Site VPN směruje mezi sítěmi zastoupenými zákaznickou bránou, s využitím podporovaných statických tras nebo BGP podle návrhu, takže jednotlivé stroje za pobočkovým routerem nepotřebují každý klientské přihlášení.

Neodvozujte nepodporované chování z kategorie v žádném směru. VPN pro vzdálený přístup nejsou univerzálně neschopné přenášet zpětný provoz nebo podporovat uspořádání s bránou a IPsec není automaticky blokován NAT — AWS dokumentuje průchod NAT a požadavky na zákaznickou bránu a skutečným omezením je podporovaná konfigurace brány. Ověřte omezení pro svůj koncový bod, než budete vyžadovat spojení iniciovaná směrem ke klientům nebo přeposílat LAN za jednou relací. Stejná opatrnost platí pro rodiny adres: koncový bod, který funguje přes IPv4, neznamená cestu IPv6, proto potvrďte rodinu, kterou váš klient nebo brána skutečně vyjednají.

Site-to-Site VPN vám dává dva tunely na spojení a tato redundance je úkol návrhu, nikoli funkce, kterou lze předpokládat. Provoz zákaznické brány, přepínání tras při selhání a pokrytí testy je třeba naplánovat; srovnání jedné relace notebooku s abstraktním VPN serverem nic nedokazuje ani o jednom z nich.

Kde se oba návrhy setkávají

Služby se nevylučují a běžná produkční podoba používá obě: zaměstnanci na Client VPN, pobočkové sítě na Site-to-Site, s výslovnými trasami a zásadami přístupu mezi cíli, které spolu musí komunikovat. Tabulka je shrnutím čtyř kontrol, nikoli náhradou za jejich provedení.

Jedna věc, kterou ani jeden z produktů nenahradí: TLS k aplikaci, jejíž požadavek na šifrování sahá za koncový bod VPN. Pokud váš rozsah shody končí u aplikace, tunel je transport a certifikát je stále kontrola.

Zapište čtyři odpovědi před revizí návrhu, každou na jeden řádek. Když si dvě odporují — řekněme klientský návrh s autentizací uživatele a požadavek na směrování v rozsahu pobočky — ten rozpor je zjištění a je levnější vidět ho teď než při přechodu.