Cortafuegos en la nube frente al cortafuegos del host para un servidor VPN

Permita el puerto VPN en la política de la nube y el handshake aún puede morir en la instancia: el invitado ejecuta su propio filtro y su propia vinculación de listener, y cualquiera de los dos puede descartar lo que la nube aprobó. También ocurre lo contrario, cuando una regla del host permite el puerto y una política superior lo descarta primero. Dos propietarios, dos conjuntos de reglas, una ruta de paquetes. Recórrala en orden en lugar de adivinar en la capa más sospechosa.

Empiece por el borde y avance hacia dentro

El orden es fijo: punto de conexión público, interfaz del recurso, política de la nube asociada, dirección del invitado, listener del proceso, reglas locales de entrada. Cada etapa deja pasar el paquete o termina la investigación, y por eso empezar por el invitado es lo que más tiempo hace perder.

El tráfico de cliente reenviado es una etapa aparte, que se inspecciona tras desencapsular el túnel. La capa de la nube solo ve el túnel exterior, así que puede aprobar una conexión y no tener nada que ver con una petición de servicio interna. Un túnel que conecta pero no llega a un host interno suele apuntar al reenvío, no a un puerto cerrado.

Lea la política de la nube antes de tocar el invitado

Confirme la regla de entrada del puerto VPN, su protocolo y el ámbito de origen que coincide con su cliente de prueba. Revise también la lista de control de acceso de la subred: un segundo filtro con sus propias reglas y valores por defecto. Ambos deben permitir el flujo antes de que un paquete llegue a la instancia. Un permiso en uno y una denegación en el otro es la forma habitual de este fallo.

Estreche el ámbito hasta que signifique algo. Abrir el puerto VPN a todo internet es fácil de demostrar y difícil de defender, mientras que una regla fijada a una dirección se rompe cuando su cliente de prueba cambia de red. Anote el identificador de la regla y el propietario de la política, para que el siguiente cambio sea rastreable hasta una persona.

Confirme el listener y luego la cadena de entrada

En la instancia, compruebe que el proceso VPN está vinculado a la dirección y el puerto que espera, por ejemplo con ss -lntp 'sport = :1194'. Un demonio vinculado solo a 127.0.0.1 acepta clientes locales y nada a través del túnel, lo que desde fuera parece exactamente un puerto filtrado.

Después lea las reglas locales con la sintaxis que usaría para cambiarlas, como iptables -S INPUT o nft list chain inet filter input. Una regla escrita en un archivo pero nunca cargada, o un descarte por defecto sin ningún permiso que encaje, descarta paquetes en silencio. Para una pasarela que reenvía, revise también los ajustes de reenvío y de ruta inversa. Deciden qué ocurre con los paquetes encaminados a través de la instancia y no dirigidos a ella.

Con estado en una capa, sin estado en la siguiente

Los grupos de seguridad recuerdan los flujos que permitieron y dejan volver las respuestas. Las listas de control de acceso de subred y muchos cortafuegos del host no guardan ese estado, así que una regla que solo cubre la dirección de salida deja pasar la petición y descarta la respuesta. Nunca lleve una suposición sobre tráfico de retorno entre capas sin leer la regla de la segunda capa (second layer's rule).

Los contadores lo resuelven más rápido que leer cada regla de la cuenta. Un contador que sube significa que el paquete llegó y allí se descartó, mientras que uno congelado en cero significa que nunca llegó tan lejos; iptables -vnL INPUT y nft list ruleset muestran esos recuentos cuando las reglas se cargaron con contadores.

Pruebe con una sesión nueva, no con una viva

Deje intactas la red de origen y el perfil de prueba mientras compara vistas, y abra una conexión nueva después de cada cambio. Llegar a la consola web en el 443 no dice nada sobre si el demonio VPN está vinculado al 1194, así que pruebe el puerto que necesita. Una sesión existente es el peor testigo aquí. Sigue funcionando mientras se rechaza cada inicio de sesión nuevo.

Antes de editar una política remota, asegúrese una vía de vuelta que no dependa del camino que está cambiando. Luego abra una segunda sesión de administración junto a la prueba VPN: una establecida antes puede sobrevivir a la regla que bloquea las nuevas. Anote los dos propietarios de las políticas para que ninguna reconstrucción restaure medio camino; si ambas capas coinciden y el túnel sigue fallando, capture en la interfaz del invitado y compruebe la dirección y el puerto que el cliente usa de verdad.