AWS Client VPN of Site-to-Site: controleer wie de verbinding opent

Vier controles beslissen dit, en geen ervan is de naam van het protocol. Wie de verbinding opent, wat AWS authenticeert, hoe de verbinding aan uw netwerk wordt gekoppeld, en welke routering en welk beleid ermee komen. Beantwoord ze in volgorde en de productkeuze maakt zich meestal zelf; beantwoord ze nadat u al een ontwerp hebt gekocht en u verdedigt een tunnel die de verkeerde helft van het probleem oplost. Geen van de vier vraagt u een cipher te kiezen, en daarom is een protocol-eerst ontwerp meestal een teken dat de eisen nooit zijn opgeschreven.

Voer elke controle uit tegen het werkelijke eindpunt, de client en de adresfamilie die u wilt gebruiken, niet tegen de categorie. Beheerde VPN-producten verschillen van de OpenVPN- en IPsec-bouwstenen waarop ze lijken.

Eerst, wie de verbinding opent

Als datgene wat toegang nodig heeft een laptop, een telefoon of de werkplek van één beheerder is, begint de verbinding op een apparaat op afstand en is het ontwerp toegang op afstand voor clients. Als datgene wat toegang nodig heeft een filiaal vol machines achter één router is, begint de verbinding op die router en is het ontwerp gateway-naar-gateway. Dit is de controle die de meeste gevallen beslecht, en het is degene die mensen overslaan wanneer een leverancierspresentatie het gesprek al rond cijfers heeft gekaderd.

Stop hier als u het onderdeel dat de verbinding start niet kunt benoemen. Een ontwerp dat beide gevallen met één tunnel probeert te bedienen, eindigt meestal met een clientsessie die zich voordoet als een gateway.

Ten tweede, wat AWS authenticeert

Bij Client VPN authenticeert AWS de geconfigureerde client- of gebruikersidentiteit: certificaten, een directory of een federatieve identiteit, afhankelijk van de opzet. Bij Site-to-Site VPN authenticeert AWS de identiteit van de gateway-peer. Dat verschil is niet cosmetisch. Het ene model schaalt door gebruikers toe te voegen en hun inloggegevens in te trekken; het andere schaalt door alles te vertrouwen wat achter één gateway staat.

Gateway-authenticatie authenticeert niet elke medewerker of applicatie erachter, dus houd applicatie-identiteiten en toegang op resourceniveau in stand, ook wanneer de tunnel zelf vertrouwd is. Een filiaal waarvan de router een geldige peer-identiteit heeft, moet niet automatisch worden gelezen alsof elk bureau in dat gebouw is geautoriseerd.

Ten derde, hoe de verbinding wordt gekoppeld

Client VPN wordt gekoppeld via VPC-subnetkoppelingen of een ondersteunde directe Transit Gateway-koppeling. Site-to-Site VPN wordt gekoppeld aan een AWS VPN-doel, meestal een virtuele particuliere gateway of een Transit Gateway. De architectuurgids voor Client VPN documenteert de Transit Gateway-optie, en het bestaan ervan maakt van een laptopsessie geen filiaalgateway en verwijdert niet de hierboven beschreven clientauthenticatie en -autorisatie.

Controleer welke koppeling uw account en regio feitelijk ondersteunen voordat u routes eromheen ontwerpt, en controleer daarna wie eigenaar is van die koppeling. Een optie die in de documentatie bestaat maar op een netwerk zit dat u niet kunt configureren, is geen optie.

Ten vierde, welke routering en welk beleid ermee komen

Client VPN brengt beheer van clientverbindingen en autorisatieregels voor de doellocaties die u toestaat. Een verbonden gebruiker heeft nog steeds de bedoelde route naar het eindpunt nodig, een autorisatieregel die die route toestaat, en de toegang die de resource zelf vereist. Site-to-Site VPN routeert tussen netwerken die door een klantgateway worden vertegenwoordigd, met ondersteunde statische routes of BGP afhankelijk van het ontwerp, zodat individuele machines achter de filiaalrouter niet elk een clientlogin nodig hebben.

Leid in geen enkele richting niet-ondersteund gedrag af uit de categorie. VPN's voor toegang op afstand zijn niet universeel ongeschikt om retourverkeer te dragen of gatewayopstellingen te ondersteunen, en IPsec wordt niet automatisch door NAT geblokkeerd — AWS documenteert NAT-traversal en klantgateway-eisen, en de ondersteunde gatewayconfiguratie is de echte beperking. Controleer de beperkingen voor uw eindpunt voordat u verbindingen eist die naar clients toe worden gestart of een LAN achter één sessie doorstuurt. Dezelfde voorzichtigheid geldt voor adresfamilies: een eindpunt dat over IPv4 werkt, impliceert geen IPv6-pad, dus bevestig de familie die uw client of gateway feitelijk zal onderhandelen.

Site-to-Site VPN geeft u twee tunnels per verbinding, en die redundantie is een ontwerptaak in plaats van een functie die u kunt aannemen. Bediening van de klantgateway, route-failover en testdekking moeten allemaal worden gepland; het vergelijken van één laptopsessie met een abstracte VPN-server bewijst niets over beide.

Waar de twee ontwerpen samenkomen

De diensten sluiten elkaar niet uit, en de gebruikelijke productievorm gebruikt beide: medewerkers op Client VPN, filiaalnetwerken op Site-to-Site, met expliciete routes en toegangsbeleid tussen de bestemmingen die moeten communiceren. De tabel is een samenvatting van de vier controles, geen vervanging voor het uitvoeren ervan.

Iets wat geen van beide producten vervangt: TLS naar een applicatie waarvan de versleutelingseis verder reikt dan het VPN-eindpunt. Als uw compliancebereik bij de applicatie eindigt, is de tunnel transport en blijft het certificaat de beheersmaatregel.

Schrijf de vier antwoorden op vóór de ontwerpbeoordeling, elk op één regel. Wanneer twee ervan met elkaar in tegenspraak zijn — bijvoorbeeld een door gebruikers geauthenticeerd clientontwerp met een routeringsbehoefte van filiaalformaat — is die tegenspraak de bevinding, en het is goedkoper om die nu te zien dan tijdens de overgang.