Em que portas o OpenVPN Access Server realmente escuta?

Você executa ss -lntup num host Access Server e obtém uma lista duas vezes mais longa do que o esperado. Metade das entradas são portas em forma de daemon que ninguém mencionou durante a instalação. O reflexo é fechar tudo o que não seja 443 ou 1194, e é assim que as pessoas quebram o próprio portal de clientes.

O Access Server não é um único ouvinte. É um serviço VPN, um serviço web e um participante de cluster, e pode gerar portas adicionais específicas de daemon e redirecionamentos de firewall conforme quantos daemons TCP você configurou.

Percorra o inventário em ordem: leia os sockets, mapeie os conhecidos, classifique o resto por proprietário e vinculação, e depois verifique o que realmente os publica.

Comece com um único comando somente de leitura

sudo ss -lntup dá transporte, endereço local, porta e processo proprietário para cada socket em escuta. Os sinalizadores importam: -l escuta, -n numérico, -t TCP, -u UDP, -p processo. Sem root você obtém os sockets mas não os nomes dos processos, e essa é exatamente a coluna que precisa para classificar.

Anote quatro campos por linha antes de formar qualquer opinião: protocolo, endereço de vinculação, porta e comando. Mantenha a versão do Access Server e o número de daemons configurado ao lado dessa lista, porque ambos mudam o que se espera.

Duas linhas que parecem idênticas não são. TCP e UDP no mesmo número são sockets separados com exposição separada, e 0.0.0.0 e :: são vinculações separadas para famílias de endereços separadas. Um serviço vinculado apenas a 127.0.0.1 não é acessível diretamente de outro host, embora um redirecionamento local ainda possa publicá-lo.

Os ouvintes que você deve reconhecer

Estes valores padrão cobrem a maioria das implantações e dão uma base de comparação. São valores padrão, não uma lista completa de permitidos.

Tudo além disso precisa de explicação, não de suposição. Muitas vezes você verá ouvintes apenas locais pertencentes a componentes que o produto instala para si mesmo. Confirme-os por PID e configuração do serviço em vez de por um número de porta memorizado, e não trate uma porta desconhecida como hostil só por ser desconhecida.

Um socket fora do par conhecido também não é automaticamente um resto. Quando vários daemons TCP estão configurados, o Access Server cria ouvintes por daemon e redireciona o tráfego para eles, portanto o número e os valores de porta seguem essa configuração.

Classifique antes de fechar qualquer coisa

Para cada linha incerta, responda a três perguntas nesta ordem.

1. Proprietário e finalidade. Associe o PID a uma unidade ou processo e leia a configuração desse serviço. Se não conseguir nomear o proprietário, não está pronto para decidir nada sobre o socket.
2. Escopo da vinculação. Loopback é local ao espaço de nomes. Uma vinculação wildcard só é acessível se o roteamento, a filtragem do host e qualquer regra em nível de nuvem permitirem, portanto o endereço de vinculação é necessário mas não suficiente. Verifique IPv4 e IPv6 como decisões separadas.
3. Caminho publicado. Procure o encaminhamento de serviço, os redirecionamentos específicos de daemon, um proxy externo e a política de firewall efetiva. Este é o passo que as pessoas pulam, e é o que transforma uma porta de backend aparentemente inofensiva num caminho administrativo acessível.

A mesma pergunta lê-se de forma diferente de fora do host. Uma porta sem regra de firewall do host ainda pode ser fechada por um grupo de segurança de nuvem, e uma porta com uma regra de host permissiva pode ser inacessível porque nada roteia para ela. Olhe para as duas pontas antes de escrever a conclusão do inventário.

Onde o caminho publicado difere da lista de sockets

A própria documentação do Access Server cobre o caso que causa mais confusão: quando vários daemons TCP correm, a porta frontal encaminha para portas específicas de daemon, e a disposição visível deixa de corresponder à lista de sockets. O tutorial de filtragem da interface web descreve essas regras e por que um filtro escrito apenas para a porta óbvia pode perder completamente o caminho redirecionado.

O controlo de cluster é o segundo lugar onde a versão importa. A partir da 3.0 partilha a 943; configurações de cluster mais antigas usavam a 945. Abrir ou bloquear uma delas sem verificar a versão produz um inventário que parece arrumado e está errado.

Portanto, a superfície visível de fora é a união de três coisas: sockets em escuta, regras de encaminhamento que os republicam e os controlos de rede à frente do host. Qualquer inventário que registe apenas a primeira está incompleto, e qualquer alteração que considere apenas a primeira deixará um caminho aberto ou cortará um serviço.

Verifique após qualquer alteração

Altere as definições dos ouvintes através do proprietário de configuração suportado e mantenha uma consola de recuperação aberta enquanto o faz. Perder o acesso administrativo a uma interface web num host remoto não é recuperável através da VPN que acabou de desativar.

Depois valide as quatro coisas de que uma implantação normalmente precisa: um cliente VPN liga-se, o portal de clientes carrega, o acesso administrativo funciona e a comunicação de cluster continua a funcionar se executar mais de um nó. Um teste apenas de VPN passa confortavelmente enquanto o portal está avariado.

Termine escrevendo o caminho permitido para cada serviço: que socket, que vinculação, que regra de encaminhamento, que controlo de rede. Esse documento é o resultado de segurança útil. Uma contagem mínima de sockets não o é, e um reset massivo que fecha ouvintes que ninguém terminou de identificar também não.