AWS Client VPN o Site-to-Site: compruebe quién abre la conexión

Cuatro comprobaciones lo deciden, y ninguna de ellas es el nombre del protocolo. Quién abre la conexión, qué autentica AWS, cómo se acopla la conexión a su red y qué enrutamiento y qué política la acompañan. Respóndalas en orden y la elección de producto suele hacerse sola; respóndalas después de haber comprado un diseño y acabará defendiendo un túnel que resuelve la mitad equivocada del problema. Ninguna de las cuatro le pide elegir un cifrado, y por eso un diseño que empieza por el protocolo suele ser señal de que los requisitos nunca se escribieron.

Ejecute cada comprobación contra el punto de enlace, el cliente y la familia de direcciones que realmente piensa usar, no contra la categoría. Los productos VPN gestionados difieren de los bloques de construcción OpenVPN e IPsec a los que se parecen.

Primero, quién abre la conexión

Si lo que necesita acceso es un portátil, un teléfono o la estación de trabajo de un solo administrador, la conexión empieza en un dispositivo remoto y el diseño es acceso de cliente remoto. Si lo que necesita acceso es una sucursal llena de máquinas detrás de un solo enrutador, la conexión empieza en ese enrutador y el diseño es puerta de enlace a puerta de enlace. Esta es la comprobación que resuelve la mayoría de los casos, y es la que la gente omite cuando la presentación de un proveedor ya ha enmarcado la conversación en torno a cifrados.

Deténgase aquí si no puede nombrar el componente que inicia. Un diseño que intenta servir ambos casos con un solo túnel suele acabar con una sesión de cliente que se hace pasar por una puerta de enlace.

Segundo, qué autentica AWS

Con Client VPN, AWS autentica la identidad de cliente o de usuario configurada: certificados, un directorio o una identidad federada, según la configuración. Con Site-to-Site VPN, AWS autentica la identidad del par de la puerta de enlace. Esa diferencia no es cosmética. Un modelo escala añadiendo usuarios y revocando sus credenciales; el otro escala confiando en todo lo que está detrás de una sola puerta de enlace.

La autenticación de la puerta de enlace no autentica a cada empleado ni a cada aplicación que hay detrás, así que mantenga las identidades de aplicación y el acceso a nivel de recurso incluso cuando el túnel en sí sea de confianza. Una sucursal cuyo enrutador tiene una identidad de par válida no debe leerse automáticamente como si cada escritorio de ese edificio estuviera autorizado.

Tercero, cómo se acopla la conexión

Client VPN se acopla mediante asociaciones de subred de VPC o una conexión directa a Transit Gateway admitida. Site-to-Site VPN se acopla a un destino de AWS VPN, habitualmente una puerta de enlace privada virtual o una Transit Gateway. La guía de arquitectura de Client VPN documenta la opción de Transit Gateway, y su existencia no convierte una sesión de portátil en una puerta de enlace de sucursal ni elimina la autenticación y la autorización de cliente descritas arriba.

Compruebe el acoplamiento que su cuenta y su región admiten realmente antes de diseñar rutas a su alrededor, y luego compruebe de quién es ese acoplamiento. Una opción que existe en la documentación pero que se asienta en una red que usted no puede configurar no es una opción.

Cuarto, qué enrutamiento y qué política la acompañan

Client VPN aporta gestión de conexiones de cliente y reglas de autorización para las redes de destino que usted permite. Un usuario conectado sigue necesitando la ruta prevista hasta el punto de enlace, una regla de autorización que la permita y el acceso que el propio recurso exija. Site-to-Site VPN enruta entre redes representadas por una puerta de enlace de cliente, usando rutas estáticas admitidas o BGP según el diseño, de modo que las máquinas individuales detrás del enrutador de sucursal no necesitan cada una un inicio de sesión de cliente.

No deduzca comportamiento no admitido a partir de la categoría en ninguna dirección. Las VPN de acceso remoto no son universalmente incapaces de transportar tráfico de retorno ni de soportar disposiciones de puerta de enlace, y IPsec no queda bloqueado automáticamente por NAT — AWS documenta el atravesado de NAT y los requisitos de puerta de enlace de cliente, y la configuración de puerta de enlace admitida es la restricción real. Compruebe las restricciones de su punto de enlace antes de exigir conexiones iniciadas hacia los clientes o de reenviar una LAN detrás de una sesión. La misma precaución se aplica a las familias de direcciones: un punto de enlace que funciona sobre IPv4 no implica una ruta IPv6, así que confirme la familia que su cliente o su puerta de enlace negociará realmente.

Site-to-Site VPN le da dos túneles por conexión, y esa redundancia es una tarea de diseño más que una función que pueda dar por supuesta. El funcionamiento de la puerta de enlace de cliente, la conmutación por error de rutas y la cobertura de pruebas tienen que planificarse; comparar una sesión de portátil con un servidor VPN abstracto no demuestra nada sobre ninguno de los dos.

Donde se encuentran los dos diseños

Los servicios no son excluyentes, y la forma de producción habitual usa ambos: empleados en Client VPN, redes de sucursal en Site-to-Site, con rutas explícitas y política de acceso entre los destinos que deben hablar. La tabla es un resumen de las cuatro comprobaciones, no un sustituto de realizarlas.

Algo que ninguno de los dos productos sustituye: TLS hacia una aplicación cuyo requisito de cifrado va más allá del punto de enlace de la VPN. Si su alcance de cumplimiento termina en la aplicación, el túnel es transporte y el certificado sigue siendo el control.

Escriba las cuatro respuestas antes de la revisión de diseño, una línea cada una. Cuando dos de ellas no coinciden — por ejemplo, un diseño de cliente autenticado por usuario con un requisito de enrutamiento de tamaño de sucursal — esa discrepancia es el hallazgo, y es más barato verla ahora que durante la migración.