¿En qué puertos escucha realmente OpenVPN Access Server?

Ejecuta ss -lntup en un host de Access Server y obtiene una lista el doble de larga de lo esperado. La mitad de las entradas son puertos con forma de demonio que nadie mencionó durante la instalación. El reflejo es cerrar todo lo que no sea 443 o 1194, y así es como la gente rompe su propio portal de clientes.

Access Server no es un solo oyente. Es un servicio VPN, un servicio web y un participante de clúster, y puede generar puertos adicionales específicos de demonio y redirecciones de firewall según cuántos demonios TCP haya configurado.

Recorra el inventario en orden: lea los sockets, mapee los conocidos, clasifique el resto por propietario y enlace, y luego compruebe qué los publica realmente.

Empiece con un solo comando de solo lectura

sudo ss -lntup le da transporte, dirección local, puerto y proceso propietario para cada socket en escucha. Los indicadores importan: -l escucha, -n numérico, -t TCP, -u UDP, -p proceso. Sin root obtiene los sockets pero no los nombres de proceso, y esa es exactamente la columna que necesita para clasificar.

Anote cuatro campos por fila antes de formarse cualquier opinión: protocolo, dirección de enlace, puerto y comando. Mantenga la versión de Access Server y el número de demonios configurado junto a esa lista, porque ambos cambian lo que se espera.

Dos filas que parecen idénticas no lo son. TCP y UDP en el mismo número son sockets separados con exposición separada, y 0.0.0.0 y :: son enlaces separados para familias de direcciones separadas. Un servicio enlazado solo a 127.0.0.1 no es accesible directamente desde otro host, aunque una redirección local todavía puede publicarlo.

Los oyentes que debería reconocer

Estos valores predeterminados cubren la mayoría de los despliegues y le dan una base con la que comparar. Son valores predeterminados, no una lista completa de permitidos.

Todo lo demás necesita una explicación, no una suposición. A menudo verá oyentes solo locales pertenecientes a componentes que el producto instala para sí mismo. Confírmelos por PID y configuración del servicio en lugar de por un número de puerto recordado, y no trate un puerto desconocido como hostil solo por ser desconocido.

Un socket fuera del par conocido tampoco es automáticamente un resto. Cuando se configuran varios demonios TCP, Access Server crea oyentes por demonio y redirige el tráfico hacia ellos, así que su número y valores de puerto siguen esa configuración.

Clasifique antes de cerrar nada

Para cada fila incierta, responda tres preguntas en este orden.

1. Propietario y propósito. Empareje el PID con una unidad o proceso y lea la configuración de ese servicio. Si no puede nombrar al propietario, no está listo para decidir nada sobre el socket.
2. Alcance del enlace. Loopback es local al espacio de nombres. Un enlace comodín solo es accesible si el enrutamiento, el filtrado del host y cualquier regla a nivel de nube lo permiten, así que la dirección de enlace es necesaria pero no suficiente. Compruebe IPv4 e IPv6 como decisiones separadas.
3. Ruta publicada. Busque el reenvío de servicio, las redirecciones específicas de demonio, un proxy externo y la política de firewall efectiva. Este es el paso que la gente se salta, y es el que convierte un puerto de backend aparentemente inofensivo en una ruta administrativa accesible.

La misma pregunta se lee distinto desde fuera del host. Un puerto sin regla de firewall del host todavía puede quedar cerrado por un grupo de seguridad de nube, y un puerto con una regla de host permisiva puede ser inaccesible porque nada enruta hacia él. Mire ambos extremos antes de escribir la conclusión del inventario.

Dónde la ruta publicada difiere de la lista de sockets

La propia documentación de Access Server cubre el caso que causa más confusión: cuando se ejecutan varios demonios TCP, el puerto frontal reenvía a puertos específicos de demonio, y la disposición visible deja de coincidir con la lista de sockets. El tutorial de filtrado de la interfaz web describe esas reglas y por qué un filtro escrito solo para el puerto obvio puede pasar por alto la ruta redirigida por completo.

El control de clúster es el segundo lugar donde la versión importa. En 3.0 y posteriores comparte 943; las configuraciones de clúster anteriores usaban 945. Abrir o bloquear uno de ellos sin comprobar la versión produce un inventario que parece ordenado y es incorrecto.

Así que la superficie visible desde fuera es la unión de tres cosas: sockets en escucha, reglas de reenvío que los vuelven a publicar y los controles de red delante del host. Cualquier inventario que registre solo lo primero es incompleto, y cualquier cambio que considere solo lo primero dejará una ruta abierta o cortará un servicio.

Verifique después de cualquier cambio

Cambie la configuración de los oyentes a través del propietario de configuración admitido y mantenga abierta una consola de recuperación mientras lo hace. Perder el acceso administrativo a una interfaz web en un host remoto no se recupera a través de la VPN que acaba de desactivar.

Luego valide las cuatro cosas que un despliegue suele necesitar: un cliente VPN se conecta, el portal de clientes carga, el acceso administrativo funciona y la comunicación de clúster sigue funcionando si ejecuta más de un nodo. Una prueba solo de VPN pasa cómodamente mientras el portal está roto.

Termine anotando la ruta permitida para cada servicio: qué socket, qué enlace, qué regla de reenvío, qué control de red. Ese documento es el resultado de seguridad útil. Un recuento mínimo de sockets no lo es, y tampoco lo es un restablecimiento masivo que cierra oyentes que nadie ha terminado de identificar.