AWS Client VPN ou Site-to-Site: comprobe quen abre a conexión

Catro comprobacións deciden isto, e ningunha delas é o nome do protocolo. Quen abre a conexión, que autentica AWS, como se acopla a conexión á súa rede e que encamiñamento e que política a acompañan. Respóndallas en orde e a elección de produto adoita facerse soa; respóndallas despois de ter comprado un deseño e acabará defendendo un túnel que resolve a metade equivocada do problema. Ningunha das catro pídelle elixir un cifrado, e por iso un deseño que comeza polo protocolo adoita ser sinal de que os requisitos nunca se escribiron.

Execute cada comprobación contra o punto final, o cliente e a familia de enderezos que realmente pensa usar, non contra a categoría. Os produtos VPN xestionados difiren dos bloques de construción OpenVPN e IPsec aos que se parecen.

Primeiro, quen abre a conexión

Se o que precisa acceso é un portátil, un teléfono ou a estación de traballo dun só administrador, a conexión comeza nun dispositivo remoto e o deseño é acceso de cliente remoto. Se o que precisa acceso é unha sucursal chea de máquinas detrás dun só encamiñador, a conexión comeza nese encamiñador e o deseño é pasarela a pasarela. Esta é a comprobación que resolve a maioría dos casos, e é a que a xente omite cando a presentación dun provedor xa enmarcou a conversa arredor de cifrados.

Detéñase aquí se non pode nomear o compoñente que inicia. Un deseño que intenta servir ambos os casos cun só túnel adoita acabar cunha sesión de cliente que se fai pasar por unha pasarela.

Segundo, que autentica AWS

Con Client VPN, AWS autentica a identidade de cliente ou de usuario configurada: certificados, un directorio ou unha identidade federada, segundo a configuración. Con Site-to-Site VPN, AWS autentica a identidade do par da pasarela. Esa diferenza non é cosmética. Un modelo escala engadindo usuarios e revogando as súas credenciais; o outro escala confiando en todo o que está detrás dunha soa pasarela.

A autenticación da pasarela non autentica a cada empregado nin a cada aplicación que hai detrás, así que manteña as identidades de aplicación e o acceso a nivel de recurso mesmo cando o túnel en si sexa de confianza. Unha sucursal cuxo encamiñador ten unha identidade de par válida non debe lerse automaticamente como se cada escritorio dese edificio estivese autorizado.

Terceiro, como se acopla a conexión

Client VPN acóplase mediante asociacións de subrede de VPC ou unha conexión directa a Transit Gateway admitida. Site-to-Site VPN acóplase a un destino de AWS VPN, habitualmente unha pasarela privada virtual ou unha Transit Gateway. A guía de arquitectura de Client VPN documenta a opción de Transit Gateway, e a súa existencia non converte unha sesión de portátil nunha pasarela de sucursal nin elimina a autenticación e a autorización de cliente descritas arriba.

Comprobe o acoplamento que a súa conta e a súa rexión admiten realmente antes de deseñar rutas ao seu redor, e despois comprobe de quen é ese acoplamento. Unha opción que existe na documentación pero que se asenta nunha rede que vostede non pode configurar non é unha opción.

Cuarto, que encamiñamento e que política a acompañan

Client VPN achega xestión de conexións de cliente e regras de autorización para as redes de destino que vostede permite. Un usuario conectado segue necesitando a ruta prevista ata o punto final, unha regra de autorización que a permita e o acceso que o propio recurso esixa. Site-to-Site VPN encamiña entre redes representadas por unha pasarela de cliente, usando rutas estáticas admitidas ou BGP segundo o deseño, de modo que as máquinas individuais detrás do encamiñador de sucursal non necesitan cada unha un inicio de sesión de cliente.

Non deduza comportamento non admitido a partir da categoría en ningunha dirección. As VPN de acceso remoto non son universalmente incapaces de transportar tráfico de retorno nin de soster disposicións de pasarela, e IPsec non queda bloqueado automaticamente polo NAT — AWS documenta o atravesamento de NAT e os requisitos de pasarela de cliente, e a configuración de pasarela admitida é a restrición real. Comprobe as restricións do seu punto final antes de esixir conexións iniciadas cara aos clientes ou de reenviar unha LAN detrás dunha sesión. A mesma precaución vale para as familias de enderezos: un punto final que funciona sobre IPv4 non implica unha ruta IPv6, así que confirme a familia que o seu cliente ou a súa pasarela negociará realmente.

Site-to-Site VPN dálle dous túneles por conexión, e esa redundancia é unha tarefa de deseño máis que unha función que poida dar por suposta. A operación da pasarela de cliente, a conmutación por erro de rutas e a cobertura de probas teñen que planificarse; comparar unha sesión de portátil cun servidor VPN abstracto non demostra nada sobre ningún dos dous.

Onde se atopan os dous deseños

Os servizos non son excluíntes, e a forma de produción habitual usa ambos: empregados en Client VPN, redes de sucursal en Site-to-Site, con rutas explícitas e política de acceso entre os destinos que deben falar. A táboa é un resumo das catro comprobacións, non un substituto de realizalas.

Algo que ningún dos dous produtos substitúe: TLS cara a unha aplicación cuxo requisito de cifrado vai máis alá do punto final da VPN. Se o seu alcance de cumprimento remata na aplicación, o túnel é transporte e o certificado segue sendo o control.

Escriba as catro respostas antes da revisión de deseño, unha liña cada unha. Cando dúas delas non coinciden — por exemplo, un deseño de cliente autenticado por usuario cun requisito de encamiñamento de tamaño de sucursal — esa discrepanza é o achado, e é máis barato vela agora que durante a migración.