EC2 entre zonas de disponibilidad: compruebe el enrutamiento antes de una VPN

Antes de instalar software VPN entre dos instancias EC2, responda una pregunta: ¿están en la misma VPC? Si lo están, la ruta privada ya existe y una ubicación entre zonas no lo cambia. La mayor parte del trabajo en esta situación es confirmar qué tabla de rutas utiliza realmente cada subred y después averiguar si el fallo era siquiera un problema de enrutamiento. Un túnel suele ser la respuesta equivocada a esta pregunta concreta.

Comprobación 1: misma VPC o VPC distintas

Una VPC es regional y abarca zonas de disponibilidad, mientras que cada subred pertenece exactamente a una zona. Dos instancias en zonas distintas de una misma VPC siguen dentro del mismo dominio de enrutamiento privado.

Las VPC distintas nunca obtienen una ruta privada por compartir una región o una etiqueta de zona. Ese caso necesita una conexión admitida y su propio trabajo de rutas y permisos, que es una decisión aparte.

Comprobación 2: qué dicen las tablas de rutas de las subredes

Escriba el diseño con valores reales. Una VPC en 10.60.0.0/16 con subredes 10.60.1.0/24 y 10.60.2.0/24 da a las instancias 10.60.1.10 y 10.60.2.20 una ruta por la ruta local de la VPC.

Después revise las tablas asociadas a ambas subredes, no solo la que encontró primero. Una ruta de inspección o de dispositivo más específica puede anular la ruta base, y el destino de la ruta local puede reemplazarse en configuraciones más nuevas. Una ruta local visible en algún lugar de la consola no demuestra que ambas cargas de trabajo la usen.

Use las direcciones y los nombres privados que la VPC asigna realmente. Una dirección privada no tiene que empezar por 10, e inventar una de memoria es como se diagnostica mal un entorno que funciona.

Comprobación 3: enrutamiento o autorización

El enrutamiento solo lleva el paquete hasta la interfaz de red del destino. El grupo de seguridad del destino todavía debe admitir el origen y el servicio, las reglas de salida del origen tienen que permitir la petición, y cualquier ACL de red debe permitir ambas direcciones porque las ACL no guardan estado.

Detrás están el cortafuegos del invitado, la vinculación del listener y la identidad propia de la aplicación. Cada uno puede rechazar una petición que el enrutamiento entregó perfectamente.

La aceptación tiene que ser la operación real de la aplicación. Un ping correcto no concede acceso a la aplicación ni demuestra que el nombre TLS y las credenciales sean correctos, y un ping bloqueado no establece que todos los servicios privados estén caídos.

Comprobación 4: ¿hace falta realmente una conexión aparte?

Una VPN puede seguir formando parte del diseño, pero por un motivo declarado: conectar esta VPC a una oficina, admitir portátiles o cumplir un requisito de superposición. Ese motivo es distinto de la comunicación normal dentro de la misma VPC.

Recuerde también qué no es una VPC. No es una extensión de un segmento Ethernet doméstico. Una aplicación que depende del descubrimiento por difusión tiene un requisito aparte que evaluar. Eso es una laguna de diseño y no un error de enrutamiento.

Comprobación 5: la cuestión del cifrado

Una dirección privada y una regla de permiso no dicen nada sobre la protección criptográfica en la capa de aplicación. Si los datos necesitan protección de extremo a extremo, esta procede del protocolo y del modelo de identidad que el servicio admite realmente.

Mantenga separadas las afirmaciones sobre la capa de red y la capa de aplicación en la nota de diseño, porque fusionarlas es como una revisión acaba afirmando una protección que nadie implementó.

Qué conviene registrar

Registre los dos identificadores de subred, la tabla de rutas asociada a cada una, las referencias de los grupos de seguridad y la operación de aplicación que probó. Son cuatro datos y resuelven la mayoría de las discusiones futuras sobre esta ruta.

La ubicación en una zona por sí sola nunca le dice que añada una VPN y nunca explica por qué falló una petición privada.