Sur quels ports OpenVPN Access Server écoute-t-il réellement ?

Vous exécutez ss -lntup sur un hôte Access Server et obtenez une liste deux fois plus longue que prévu. La moitié des entrées sont des ports en forme de démon que personne n’a mentionnés lors de l’installation. Le réflexe est de fermer tout ce qui n’est ni 443 ni 1194, et c’est ainsi que les gens cassent leur propre portail client.

Access Server n’est pas un seul écouteur. C’est un service VPN, un service web et un participant de cluster, et il peut générer des ports supplémentaires propres aux démons et des redirections de pare-feu selon le nombre de démons TCP que vous avez configurés.

Parcourez l’inventaire dans l’ordre : lisez les sockets, cartographiez les connus, classez le reste par propriétaire et liaison, puis vérifiez ce qui les publie réellement.

Commencez par une seule commande en lecture seule

sudo ss -lntup vous donne le transport, l’adresse locale, le port et le processus propriétaire de chaque socket en écoute. Les options comptent : -l écoute, -n numérique, -t TCP, -u UDP, -p processus. Sans root, vous obtenez les sockets mais pas les noms de processus, et c’est précisément la colonne dont vous avez besoin pour classer.

Notez quatre champs par ligne avant de vous forger une opinion : protocole, adresse de liaison, port et commande. Gardez la version d’Access Server et le nombre de démons configuré à côté de cette liste, car les deux changent ce qui est attendu.

Deux lignes qui semblent identiques ne le sont pas. TCP et UDP sur le même numéro sont des sockets distincts avec une exposition distincte, et 0.0.0.0 et :: sont des liaisons distinctes pour des familles d’adresses distinctes. Un service lié uniquement à 127.0.0.1 n’est pas directement joignable depuis un autre hôte, même si une redirection locale peut encore le publier.

Les écouteurs que vous devriez reconnaître

Ces valeurs par défaut couvrent la plupart des déploiements et vous donnent une base de comparaison. Ce sont des valeurs par défaut, pas une liste d’autorisations complète.

Tout ce qui va au-delà demande une explication, pas une supposition. Vous verrez souvent des écouteurs locaux appartenant à des composants que le produit installe pour lui-même. Confirmez-les par PID et configuration du service plutôt que par un numéro de port mémorisé, et ne traitez pas un port inconnu comme hostile simplement parce qu’il est inconnu.

Un socket hors de la paire connue n’est pas non plus automatiquement un reliquat. Lorsque plusieurs démons TCP sont configurés, Access Server crée des écouteurs par démon et y redirige le trafic, donc leur nombre et leurs valeurs de port suivent cette configuration.

Classez avant de fermer quoi que ce soit

Pour chaque ligne incertaine, répondez à trois questions dans cet ordre.

1. Propriétaire et objectif. Associez le PID à une unité ou à un processus et lisez la configuration de ce service. Si vous ne pouvez pas nommer le propriétaire, vous n’êtes pas prêt à décider quoi que ce soit au sujet du socket.
2. Portée de la liaison. Loopback est local à l’espace de noms. Une liaison générique n’est joignable que si le routage, le filtrage de l’hôte et d’éventuelles règles au niveau du cloud le permettent, donc l’adresse de liaison est nécessaire mais pas suffisante. Vérifiez IPv4 et IPv6 comme des décisions distinctes.
3. Chemin publié. Cherchez le transfert de service, les redirections propres aux démons, un proxy externe et la politique de pare-feu effective. C’est l’étape que les gens sautent, et c’est elle qui transforme un port backend apparemment inoffensif en chemin administratif joignable.

La même question se lit différemment depuis l’extérieur de l’hôte. Un port sans règle de pare-feu d’hôte peut toujours être fermé par un groupe de sécurité cloud, et un port avec une règle d’hôte permissive peut être injoignable parce que rien ne route vers lui. Regardez les deux extrémités avant d’écrire la conclusion de l’inventaire.

Où le chemin publié diffère de la liste des sockets

La documentation d’Access Server elle-même couvre le cas qui prête le plus à confusion : lorsque plusieurs démons TCP tournent, le port frontal redirige vers des ports propres aux démons, et la disposition visible cesse de correspondre à la liste des sockets. Le tutoriel de filtrage de l’interface web décrit ces règles et pourquoi un filtre écrit uniquement pour le port évident peut manquer entièrement le chemin redirigé.

Le contrôle de cluster est le second endroit où la version compte. À partir de 3.0, il partage 943 ; les configurations de cluster plus anciennes utilisaient 945. Ouvrir ou bloquer l’un d’eux sans vérifier la version produit un inventaire qui semble propre et qui est faux.

La surface visible de l’extérieur est donc l’union de trois choses : les sockets en écoute, les règles de transfert qui les republient et les contrôles réseau devant l’hôte. Tout inventaire qui n’enregistre que la première est incomplet, et tout changement qui ne considère que la première laissera un chemin ouvert ou coupera un service.

Vérifiez après tout changement

Modifiez les paramètres d’écoute via le propriétaire de configuration pris en charge et gardez une console de récupération ouverte pendant l’opération. Perdre l’accès administratif à une interface web sur un hôte distant ne se récupère pas via le VPN que vous venez de désactiver.

Validez ensuite les quatre choses dont un déploiement a généralement besoin : un client VPN se connecte, le portail client se charge, l’accès administratif fonctionne et la communication de cluster fonctionne toujours si vous exploitez plus d’un nœud. Un test uniquement VPN passe confortablement alors que le portail est cassé.

Terminez en notant le chemin autorisé de chaque service : quel socket, quelle liaison, quelle règle de transfert, quel contrôle réseau. Ce document est le résultat de sécurité utile. Un nombre minimal de sockets ne l’est pas, et une réinitialisation massive qui ferme des écouteurs que personne n’a fini d’identifier ne l’est pas non plus.