Acceso intermitente con AWS Client VPN: audite cada subred asociada

Un usuario se conecta, abre la aplicación interna y obtiene respuesta; un compañero en el mismo punto de enlace recibe un tiempo de espera desde un portátil idéntico en la misma Wi-Fi. Ese patrón es la firma de un punto de enlace de client VPN con más de una subred asociada, donde los caminos no son equivalentes. Recorro esto desde la consola hacia fuera, porque dos pestañas deciden si merece la pena el resto de la investigación. Nada en la configuración del cliente lo explica.

Empiece por el punto de enlace y enumere las asociaciones

En la consola de VPC, abra Client VPN endpoints, elija el punto de enlace y lea la pestaña Associations. Cada asociación es una subred en una zona de disponibilidad, y el cliente aterriza en la que elija el servicio cuando se construye la conexión. Anote los identificadores de subred y la tabla de rutas que realmente usa cada una, porque esas dos listas son la comparación que está a punto de hacer.

Si el punto de enlace muestra una sola asociación, esta teoría es falsa y el cliente es el mejor sospechoso.

Compare la tabla de rutas del punto de enlace con cada asociación

Abra la pestaña Route table en el mismo punto de enlace. Cada CIDR de destino allí tiene un objetivo, y en un client VPN el objetivo es una asociación y no una puerta de enlace. AWS exige una entrada de destino para cada subred asociada, así que una ruta que solo apunta a una de ellas hace que el acceso dependa de dónde aterrizó la sesión. Revise el destino que realmente le importa y luego su regla de autorización, porque la ruta aporta el camino y la regla decide quién puede usarlo.

Cuando tabula ambas capas, el fallo es difícil de pasar por alto.

La segunda fila es todo el fallo en la mayoría de los tiques. La ruta del punto de enlace está ahí, así que nadie mira más allá, y el paquete muere un salto después dentro de la VPC.

Siga cada subred hasta su tabla de rutas efectiva

Una subred sin asociación explícita a una tabla de rutas hereda la tabla principal de la VPC. Lea la tabla que realmente está en vigor, no la que parece tener el nombre correcto, y compare destino y objetivo en lugar de la etiqueta de la fila.

La guía de AWS sobre acceso intermitente lo plantea como cobertura de rutas entre asociaciones, que es el modelo correcto. El punto de enlace lleva el paquete a una subred, y la tabla de esa subred todavía tiene que saber dónde vive la red de la aplicación.

Corrija la fila que falta en la tabla que la posee. Copiar una tabla de rutas entera de una subred que funciona también copia decisiones de internet, dispositivos y aislamiento que nunca estuvieron pensadas para esta, y ese intercambio suele ser peor que la caída con la que empezó.

Revise las reglas de autorización y luego el camino de vuelta

Las reglas de autorización son por destino y por grupo, y se evalúan por separado de las rutas. Un destino con rutas por todas partes pero sin regla para el grupo del usuario se comporta como un agujero negro con una tabla de rutas que parece sana.

El camino de vuelta merece la misma atención. Una conexión de peering necesita una ruta en la VPC de la aplicación que apunte de vuelta al CIDR del cliente, reglas de grupo de seguridad que permitan el tráfico en ambos extremos y ACL de red que no lo descarten. La alcanzabilidad en un solo sentido, donde ping funciona y el apretón de manos TCP no, suele apuntar a una ACL o a un grupo de seguridad y no a la VPN.

Los grupos de seguridad del propio punto de enlace se asientan sobre las interfaces de red elásticas de la asociación, así que una regla que permita el puerto de la aplicación desde el CIDR del cliente debe adjuntarse a la asociación, no solo a la instancia.

Verifique con una reconexión, no con una petición afortunada

Con túnel dividido, las rutas del punto de enlace se envían cuando se establece la conexión, así que un conjunto de rutas cambiado nunca llega a un cliente que permanece conectado. Desconecte y vuelva a conectar con el cliente compatible, y luego confirme que las rutas nuevas están en la máquina.

Por último, correlacione el registro de conexiones con la dirección que recibió el cliente y repita la prueba las veces suficientes para topar con más de una asociación. Una sola petición correcta tras una corrección demuestra que un camino funciona, y el tique era sobre el otro.