AWS Client VPN eller Site-to-Site: kontrollera vem som öppnar anslutningen

Fyra kontroller avgör detta, och ingen av dem är protokollets namn. Vem som öppnar anslutningen, vad AWS autentiserar, hur anslutningen kopplas till ditt nätverk och vilken routning och policy som följer med. Svara i ordning och produktvalet brukar göra sig självt; svara efter att du redan köpt en design och du kommer att försvara en tunnel som löser fel halva av problemet. Ingen av de fyra ber dig välja ett chiffer, och därför är en protokoll-först-design oftast ett tecken på att kraven aldrig skrevs ned.

Kör varje kontroll mot den faktiska slutpunkten, klienten och den adressfamilj du planerar att använda, inte mot kategorin. Hanterade VPN-produkter skiljer sig från de OpenVPN- och IPsec-byggstenar de liknar.

Först, vem som öppnar anslutningen

Om det som behöver åtkomst är en laptop, en telefon eller en enskild administratörs arbetsstation börjar anslutningen på en fjärrenhet och designen är fjärrklientåtkomst. Om det som behöver åtkomst är en filial full av maskiner bakom en enda router börjar anslutningen på den routern och designen är gateway-till-gateway. Det är kontrollen som avgör de flesta fallen, och det är den folk hoppar över när en leverantörspresentation redan har ramat in samtalet kring chiffer.

Stanna här om du inte kan namnge komponenten som initierar. En design som försöker betjäna båda fallen med en enda tunnel slutar oftast med en klientsession som utger sig för att vara en gateway.

Sedan, vad AWS autentiserar

Med Client VPN autentiserar AWS den konfigurerade klient- eller användaridentiteten: certifikat, en katalog eller en federerad identitet, beroende på uppsättningen. Med Site-to-Site VPN autentiserar AWS gateway-peerns identitet. Den skillnaden är inte kosmetisk. Den ena modellen skalar genom att lägga till användare och återkalla deras uppgifter; den andra skalar genom att lita på allt som står bakom en enda gateway.

Gateway-autentisering autentiserar inte varje anställd eller applikation bakom den, så behåll applikationsidentiteter och åtkomst på resursnivå även när själva tunneln är betrodd. En filial vars router har en giltig peer-identitet bör inte automatiskt läsas som om varje skrivbord i den byggnaden är auktoriserat.

För det tredje, hur anslutningen kopplas

Client VPN kopplas via VPC-subnätsassociationer eller en stödd direkt Transit Gateway-anslutning. Site-to-Site VPN kopplas till ett AWS VPN-mål, oftast en virtuell privat gateway eller en Transit Gateway. Client VPN-arkitekturhandboken dokumenterar Transit Gateway-alternativet, och att det finns gör inte en laptopsession till en filialgateway och tar inte bort den klientautentisering och auktorisering som beskrivs ovan.

Kontrollera vilken anslutning ditt konto och din region faktiskt stöder innan du designar rutter kring den, och kontrollera sedan vem som äger den anslutningen. Ett alternativ som finns i dokumentationen men ligger på ett nätverk du inte kan konfigurera är inte ett alternativ.

För det fjärde, vilken routning och policy som följer med

Client VPN ger klientanslutningshantering och auktoriseringsregler för de destinationsnätverk du tillåter. En ansluten användare behöver fortfarande den avsedda rutten till slutpunkten, en auktoriseringsregel som tillåter den och den åtkomst som resursen själv kräver. Site-to-Site VPN routar mellan nätverk som representeras av en kundgateway, med stödda statiska rutter eller BGP beroende på designen, så enskilda maskiner bakom filialroutern behöver inte var och en en klientinloggning.

Härled inte icke-stött beteende från kategorin i någon riktning. Fjärråtkomst-VPN:er är inte universellt oförmögna att bära returtrafik eller stödja gatewayupplägg, och IPsec blockeras inte automatiskt av NAT — AWS dokumenterar NAT-traversering och kundgatewaykrav, och den stödda gatewaykonfigurationen är den verkliga begränsningen. Kontrollera begränsningarna för din slutpunkt innan du kräver anslutningar som startas mot klienter eller vidarebefordrar ett LAN bakom en session. Samma försiktighet gäller adressfamiljer: en slutpunkt som fungerar över IPv4 innebär inte en IPv6-väg, så bekräfta den familj som din klient eller gateway faktiskt kommer att förhandla om.

Site-to-Site VPN ger dig två tunnlar per anslutning, och den redundansen är en designuppgift snarare än en funktion du kan ta för given. Drift av kundgateway, rutt-failover och testtäckning måste alla planeras; att jämföra en laptopsession med en abstrakt VPN-server bevisar ingenting om någon av dem.

Där de två designerna möts

Tjänsterna utesluter inte varandra, och den vanliga produktionsformen använder båda: anställda på Client VPN, filialnätverk på Site-to-Site, med explicita rutter och åtkomstpolicy mellan de destinationer som måste kommunicera. Tabellen är en sammanfattning av de fyra kontrollerna, inte en ersättning för att utföra dem.

En sak som ingen av de två produkterna ersätter: TLS till en applikation vars krypteringskrav sträcker sig bortom VPN-slutpunkten. Om ditt regelefterlevnadsomfång slutar vid applikationen är tunneln transport och certifikatet är fortfarande kontrollen.

Skriv ned de fyra svaren före designgenomgången, ett på varje rad. När två av dem är oense — säg en användarautentiserad klientdesign med ett ruttbehov i filialstorlek — är den oenigheten fyndet, och det är billigare att se det nu än under övergången.