Actualmente estamos ejecutando funciones de AWS Lambda dentro de una VPC y, por ejemplo, ya tenemos una conexión de intercambio de tráfico configurada con MongoDB Atlas para que nuestros AWS Lambda dentro de la VPC se comuniquen con nuestra base de datos alojada en MongoDB Atlas.
Ahora ha surgido el requisito de que un servicio específico dentro de nuestra VPC que activamos mediante AWS Lambda y que también se ejecuta dentro de la misma VPC tiene que acceder a una función/host de red local a través de VPN. Además, esa red debe poder responder a los mensajes de ese servicio, por lo que supongo que se necesita una conexión de sitio a sitio.
El cliente nos ha proporcionado los parámetros de IKE fase uno, los parámetros de IKE fase dos (IPSEC), sus direcciones IP de pares locales, los puertos de comunicación VPN aceptados y los dominios de cifrado locales.
Ahora solicitan nuestras direcciones IP de pares remotos y dominios de cifrado remotos.
Pregunta 1: ¿Es factible lo que estamos tratando de lograr en AWS en una VPC (estoy leyendo publicaciones contradictorias sobre esto?
Pregunta 2: ¿Estoy en lo cierto al suponer que el inicio del túnel tendrá que ocurrir desde el lado del cliente y que luego usaremos el sondeo de monitoreo de red para mantener el túnel activo?
Respuesta1
Respecto a la pregunta 1.
Suponiendo que se refiere a la capacidad de conectarse a través de una VPN basada en IPSec para conectarse de forma segura a recursos ubicados fuera de AWS. La respuesta es sí. Sin embargo, la implementación nativa de AWS de esto tiene algunas restricciones. La primera es que no es posible especificar ningún aspecto de los ajustes de configuración de la fase 1 o la fase 2. En cambio, AWS le brinda la posibilidad de descargar configuraciones preconfiguradas para una variedad de fabricantes, pero también brinda algunos buenos ejemplos genéricos.
Algunos buenos recursos son:
Conexiones VPN administradas por AWS- proporciona detalles sobre el servicio AWS VPN Gateway
Su puerta de enlace para el cliente- proporciona información sobre la configuración requerida en el dispositivo fuera de AWS
Respecto a la pregunta 2.
Esto es cierto, si el túnel cae por algún motivo, el lado de AWS no puede iniciarlo (esta es una limitación MUY molesta si me preguntas). Sin embargo, hay formas de evitarlo. Algunos dispositivos admiten el envío de paquetes de mantenimiento de actividad para mantener el túnel activo. Por ejemplo, Cisco ASA puede utilizar la función IP SLA para enviar mensajes SLA a lo largo del túnel para mantenerlo activo. Extraer dela configuración de ASA de muestra:
Para mantener el túnel en un estado activo o siempre activo, el ASA necesita enviar tráfico a la subred definida en acl-amzn. El monitoreo de SLA se puede configurar para enviar pings a un destino en la subred y mantendrá el túnel activo. Este tráfico debe enviarse a un objetivo que devolverá una respuesta. Esto se puede probar manualmente enviando un ping al destino desde el ASA procedente de la interfaz externa. Un posible destino para el ping es una instancia dentro de la VPC. Para obtener redundancia, se pueden configurar varios monitores SLA en varias instancias para proteger contra un único punto de falla.
O simplemente puede hacer arreglos para que un sistema en un lado envíe periódicamente un ping, a través de un trabajo cron o una tarea programada.
Sin embargo, otra opción es implementar su propia puerta de enlace IPSec en AWS; ya sea ejecutándola en la instancia misma o en otra instancia, luego puede actualizar la tabla de rutas en su subred para enrutarla a las subredes fuera de AWS a través de esta instancia. Esto le permite tener más control sobre la configuración y el comportamiento de IPSec, pero podría decirse que es más complejo de administrar en comparación con el servicio nativo de AWS.