Grupo de seguridad en la nube para una VPN: abra el listener, no todo
Un grupo de seguridad es uno de los cuatro filtros entre el cliente y el demonio. Nombra el protocolo y luego revisa la ACL, el firewall del host y el reenvío.
El servidor VPN funciona, el cliente agota el tiempo de espera y el primer impulso es añadir una regla que lo permita todo al grupo de seguridad. A veces eso lo hace funcionar, y es el peor resultado, porque ahora nadie sabe qué frontera se cerró en realidad. Cuatro filtros separados se interponen entre el cliente y el demonio, y solo uno de ellos es el grupo de seguridad.
Nombra el protocolo antes que la regla
Una regla es un protocolo, un rango de puertos y un origen. WireGuard escucha en UDP, normalmente 51820. OpenVPN suele ser UDP o TCP 1194 según cómo se haya configurado. IPsec necesita su intercambio IKE en UDP 500 y 4500, además del propio protocolo ESP, que es un número de protocolo y no un puerto. Suponer TCP porque las demás reglas son TCP es como se acaba con una regla que parece correcta y no coincide con nada.
Lee el listener del servicio en ejecución, no de un tutorial. Un demonio ligado a una dirección no aceptará tráfico que llegue a otra.
Restringe el origen al rango de clientes que permite el diseño, en lugar de a todo internet.
Los grupos de seguridad tienen estado; las ACL de subred no
Los grupos de seguridad tienen estado y solo permiten: un flujo entrante permitido recibe sus respuestas automáticamente, y no hay ninguna regla de denegación sobre la que razonar. Las ACL de subred no tienen estado y se evalúan en ambos sentidos, así que un permiso entrante sin el rango efímero de salida correspondiente sigue fallando. Esa diferencia explica muchas reglas que parecen correctas en la consola.
Confirma también qué política está asociada al endpoint en ejecución, ya que una instancia puede tener más de un grupo y una regla en un grupo no asociado no cambia nada.
La política efectiva es la unión de lo asociado, no el archivo que editaste.
El firewall del host es una frontera aparte
La política de la nube admite el tráfico hacia la interfaz de red, y luego el sistema operativo decide si el demonio lo ve. Un firewall del host con política de denegación por defecto descartará un paquete que el grupo de seguridad permitió, y la consola de la nube no mostrará ninguna denegación porque nunca tuvo opinión. Comprueba ambos, en el orden en que el paquete los encuentra.
Si el host usa un frontend de firewall de la distribución, confirma las reglas subyacentes en lugar del nombre del perfil, porque un perfil puede estar activo mientras el puerto está cerrado.
Una captura en la interfaz te dice qué frontera descartó el paquete.
Admitir el listener no es enrutar a los clientes
Una puerta de enlace VPN que reenvía tráfico de clientes necesita más que un puerto abierto. Necesita reenvío IP, una política que permita el flujo desde la interfaz del túnel a la red de destino y, a menudo, la comprobación de origen y destino desactivada en la interfaz para que la plataforma no descarte tráfico que no va dirigido a ella. Nada de eso lo crea la regla del listener.
Aquí es donde se separan un handshake que funciona y una ruta de datos rota, y por eso el estado del túnel puede parecer sano mientras no carga nada.
Corrige el enrutamiento como un cambio aparte con su propia verificación, y ten en cuenta que una puerta de enlace que reenvía también necesita una política de salida que permita el destino.
Mantén una vía de retorno y luego estrecha la regla
Antes de cambiar la política del firewall remoto, confirma que existe una vía de gestión independiente, como un gestor de sesiones, una consola serie o una red fuera de banda. Si la única vía de gestión pasa por la regla que estás editando, no tienes recuperación. Después aplica la regla estrecha, prueba desde un cliente real y correlaciona el intento con pruebas del lado del servidor. Una respuesta de otro servicio en la misma máquina no es prueba de que se alcanzara el listener.
Elimina cualquier permiso amplio experimental en cuanto funcione el estrecho, y anota por qué existe la regla. AWS documenta el comportamiento con estado de los grupos de seguridad, y ese es el documento que hay que citar cuando alguien propone un rango amplio como atajo.
Documenta también la asociación, o una interfaz de reemplazo perderá la política en silencio.