En que portos escoita realmente OpenVPN Access Server?
Percorra a lista de sockets nun host de Access Server: recoñeza os oíntes predeterminados, distinga loopback dos publicados e comprobe o reenvío antes de pechar un porto.
Executa ss -lntup nun host de Access Server e obtén unha lista o dobre de longa do esperado. A metade das entradas son portos con forma de daemon que ninguén mencionou durante a instalación. O reflexo é pechar todo o que non sexa 443 ou 1194, e así é como a xente rompe o seu propio portal de clientes.
Access Server non é un único oínte. É un servizo VPN, un servizo web e un participante de clúster, e pode xerar portos adicionais específicos de daemon e redireccións de firewall segundo cantos daemons TCP configurase.
Percorra o inventario en orde: lea os sockets, mapee os coñecidos, clasifique o resto por propietario e enlace, e despois comprobe que os publica realmente.
Comece cun único comando de só lectura
sudo ss -lntup dálle transporte, enderezo local, porto e proceso propietario para cada socket en escoita. Os indicadores importan: -l escoita, -n numérico, -t TCP, -u UDP, -p proceso. Sen root obtén os sockets pero non os nomes de proceso, e esa é exactamente a columna que necesita para clasificar.
Anote catro campos por fila antes de formarse calquera opinión: protocolo, enderezo de enlace, porto e comando. Manteña a versión de Access Server e o número de daemons configurado xunto a esa lista, porque ambos cambian o que se espera.
Dúas filas que parecen idénticas non o son. TCP e UDP no mesmo número son sockets separados con exposición separada, e 0.0.0.0 e :: son enlaces separados para familias de enderezos separadas. Un servizo enlazado só a 127.0.0.1 non é accesible directamente desde outro host, aínda que unha redirección local aínda pode publicalo.
Os oíntes que debería recoñecer
Estes valores predeterminados cobren a maioría dos despregamentos e danlle unha base coa que comparar. Son valores predeterminados, non unha lista completa de permitidos.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
Todo o demais necesita unha explicación, non unha suposición. A miúdo verá oíntes só locais pertencentes a compoñentes que o produto instala para si mesmo. Confírmelos por PID e configuración do servizo en lugar dun número de porto recordado, e non trate un porto descoñecido como hostil só por ser descoñecido.
Un socket fóra do par coñecido tampouco é automaticamente un resto. Cando se configuran varios daemons TCP, Access Server crea oíntes por daemon e redirixe o tráfico cara a eles, así que o seu número e valores de porto seguen esa configuración.
Clasifique antes de pechar nada
Para cada fila incerta, responda tres preguntas nesta orde.
- Propietario e propósito. Emparexe o PID cunha unidade ou proceso e lea a configuración dese servizo. Se non pode nomear o propietario, non está listo para decidir nada sobre o socket.
- Alcance do enlace. Loopback é local ao espazo de nomes. Un enlace comodín só é accesible se o enrutamento, o filtrado do host e calquera regra a nivel de nube o permiten, así que o enderezo de enlace é necesario pero non suficiente. Comprobe IPv4 e IPv6 como decisións separadas.
- Ruta publicada. Busque o reenvío de servizo, as redireccións específicas de daemon, un proxy externo e a política de firewall efectiva. Este é o paso que a xente salta, e é o que converte un porto de backend aparentemente inofensivo nunha ruta administrativa accesible.
A mesma pregunta lese distinto desde fóra do host. Un porto sen regra de firewall do host aínda pode quedar pechado por un grupo de seguridade de nube, e un porto cunha regra de host permisiva pode ser inaccesible porque nada enruta cara a el. Mire ambos os extremos antes de escribir a conclusión do inventario.
Onde a ruta publicada difire da lista de sockets
A propia documentación de Access Server cobre o caso que causa máis confusión: cando se executan varios daemons TCP, o porto frontal reenvía a portos específicos de daemon, e a disposición visible deixa de coincidir coa lista de sockets. O titorial de filtrado da interface web describe esas regras e por que un filtro escrito só para o porto obvio pode pasar por alto a ruta redirixida por completo.
O control de clúster é o segundo lugar onde a versión importa. En 3.0 e posteriores comparte 943; as configuracións de clúster anteriores usaban 945. Abrir ou bloquear un deles sen comprobar a versión produce un inventario que parece ordenado e é incorrecto.
Así que a superficie visible desde fóra é a unión de tres cousas: sockets en escoita, regras de reenvío que os volven publicar e os controis de rede diante do host. Calquera inventario que rexistre só o primeiro é incompleto, e calquera cambio que considere só o primeiro deixará unha ruta aberta ou cortará un servizo.
Verifique despois de calquera cambio
Cambie a configuración dos oíntes a través do propietario de configuración admitido e manteña aberta unha consola de recuperación mentres o fai. Perder o acceso administrativo a unha interface web nun host remoto non se recupera a través da VPN que acaba de desactivar.
Despois valide as catro cousas que un despregamento adoita necesitar: un cliente VPN conéctase, o portal de clientes carga, o acceso administrativo funciona e a comunicación de clúster segue funcionando se executa máis dun nodo. Unha proba só de VPN pasa comodamente mentres o portal está roto.
Remate anotando a ruta permitida para cada servizo: que socket, que enlace, que regra de reenvío, que control de rede. Ese documento é o resultado de seguridade útil. Un reconto mínimo de sockets non o é, e tampouco o é un restablecemento masivo que pecha oíntes que ninguén rematou de identificar.