Planteamiento del problema
Tengo un requisito para el plan de continuidad del negocio utilizando AWS Cloud VPC con los siguientes requisitos:
- En la subred privada de AWS VPC de nuestro desarrollador, tendremos espacios de trabajo (es decir, escritorio como servicio seguro de AWS) para cada desarrollador.
- Desde estos espacios de trabajo, cada desarrollador puede conectarse a diferentes nubes remotas mediante VPN, es decir, nubes públicas GCP/AWS/Azure o incluso centros de datos locales. Estos diferentes centros de datos remotos o Nubes Públicas pueden tener rangos de direcciones IP superpuestos y no tenemos control sobre la gestión de estos rangos de IP.
- El desarrollador puede cambiar y conectarse fácilmente entre diferentes nubes desde el espacio de trabajo mediante VPN
Los servicios/características nativas de AWS no ayudan directamente
Sitio2Sitio VPN- Para satisfacer estos requisitos, la red VPN Transit de sitio a sitio de AWS está fuera de alcance porque no permite la superposición de rangos de IP.
De manera indirecta para resolver rangos de direcciones IP superpuestos, existe un plan VPN redundante de sitio a sitio en la documentación de AWS, pero es para un escenario de conmutación por error y necesito que todas las nubes remotas puedan conectarse en cualquier momento, es decir, que estén siempre activas.
Puerta de tránsito- AWS Transit Gateway no ayuda porque idealmente no permite la superposición de rangos de IP en redes multinube.
Hay una manera de realizar la segmentación de rutas, es decir, separar la ruta de enrutamiento para una combinación separada de nubes interconectadas, utilizando múltiples tablas de rutas en Transit Gateway, pero este enfoque requiere dicha segmentación utilizando el archivo adjunto de Transit Gateway, y AWS VPC no puede tener más de un archivo adjunto. .
Además, incluso si hacemos algo así, podemos usar software VPN en instancias EC2 (no estoy seguro si es posible), no estoy seguro de si podemos conectarnos fácilmente desde cada espacio de trabajo y cambiar a todas las nubes diferentes debido a la tabla de rutas de subred de AWS VPC del desarrollador. No se pueden superponer rangos de IP en el destino.
Mi enfoque para una solución
Mi plan de red
En la misma subred, estaba pensando en utilizar un enfoque VPN IPSec basado en software, es decir, en un caso en EC2 tendrá un servicio VPN como strongswan y reglas de Iptable para SNAT. Este enfoque está inspirado en la respuesta de AWS Support enConfigurar NAT para tráfico VPN.
Para cada nube/centro de datos, habrá una configuración de instancia EC2 con software IPSec VPN y reglas IPtable.
En el lado remoto también habrá una puerta de enlace para la VPN, al igual que el emparejamiento de AWS VGW y Customer Gateway.
Para que el tráfico vaya desde el espacio de trabajo a la nube remota correcta mediante VPN, tengo que realizar una entrada en la tabla de rutas de la subred con Destino como rango de direcciones IP de la nube remota y Destino como ID de eni de la instancia VPN EC2.
Problema con este enfoqueEs, nuevamente, que para nubes remotas con direcciones IP superpuestas, no puedo tener entradas en la tabla de rutas de subred de AWS VPC del desarrollador.
Para resolver este problema, Estaba pensando en hacer algo como manipulación del rango de IP en el que tendré rangos de IP completamente inventados o irreales para cada nube remota superpuesta, es decir, para una nube con un rango de IP real como 192.168.xy/16, el irreal será 10.10. pq/16.
Después de eso, tendré un servidor VPN EC2 independiente para cada una de estas nubes remotas. Luego, para la ruta para cualquiera de las nubes remotas, la entrada en la tabla de rutas será 10.10.pq/16 como destino y la identificación eni del servidor VPN EC2 como destino.
En el servidor VPN EC2, tendremos configuradas las reglas de Iptable, que harán algo como PREROUTING DNAT y POSTROUTING SNAT para reenvío solo de IP como se muestra en estePreguntas y respuestas sobre desbordamiento de pila.
El desarrollador de espacios de trabajo deberá conocer el mapeo entre IP reales y irreales y enviar tráfico utilizando IP irreales. Las reglas de Iptables del servidor VPN EC2 deberán actualizarse mediante scripts personalizados para que esta asignación se mantenga actualizada con la asignación más reciente.
No estoy seguro de la exactitud o eficacia de mi enfoque anterior.
Otro problema por implicación de mi enfoque anterior.
También genera dudas de que incluso si me conecto a instancias con IP específicas en la nube remota, ¿qué pasa con el acceso a otros servicios en la nube, como funciones sin servidor o API o servicios administrados/abstractos como DB/LB?
Aunque esto se puede hacer enviando tráfico usando IGW en la VPC del desarrollador o conectándose a un host bastión en la nube remota.
Otro enfoque, que busqué en internet.está configurando una red superpuesta multinube personalizada que parece desalentadora o científica.
Tampoco estoy seguro de si las VPN de código abierto como OpenVPN o pfsense como el software de firewall/red pueden ayudar con algunas de sus características nativas a resolver mi problema original.
Obtuve todos mis conocimientos sobre redes o VPN mientras trabajaba únicamente en la nube de AWS y no estoy bien versado en la profundidad de las redes en general en informática.
Por favor ayuda con estos problemas.