Quels rôles logiciels une passerelle OpenVPN sans écran exige-t-elle

Une machine dédiée à une passerelle OpenVPN a besoin d’une installation serveur prise en charge et des logiciels correspondant aux tâches qu’elle exécute réellement. Un menu d’installation qui propose SSH, l’hébergement web et d’autres rôles serveur n’est pas une liste de prérequis OpenVPN. Un déploiement sans écran est parfaitement raisonnable. L’important est de séparer trois tâches : porter le tunnel, administrer l’hôte et délivrer des identifiants.

Voici l’ordre d’inventaire que j’utilise, avec le contrôle qui clôt chaque étape.

1. Donnez au service de tunnel son propre paquet et profil

Le guide du serveur OpenVPN d’Ubuntu utilise le paquet openvpn de la distribution avec une ligne de commande et une configuration de service. Le même paquet sert de client Linux, et la configuration choisit le rôle.

Cela signifie qu’installer une interface graphique cliente n’est pas ce qui transforme l’hôte en serveur, et que la retirer n’est pas ce qui le rend sans écran. Notez quel profil lit l’instance en cours, car un second fichier de configuration dans le même répertoire peut être chargé sans que personne ne le remarque, et le démon signale un succès dans les deux cas. Lorsque deux profils existent, le gestionnaire de services décide lequel gagne, et cette décision appartient à vos notes plutôt qu’à une supposition.

2. Décidez le chemin d’administration avant le tunnel

OpenSSH provient d’un paquet openssh-server distinct et s’exécute comme son propre service. Il est utile lorsqu’un administrateur doit atteindre la machine par SSH, mais OpenVPN n’a pas besoin d’un serveur SSH pour échanger des paquets VPN. Une console locale ou un canal de gestion de plateforme approuvé est un autre chemin valable. Décidez celui sur lequel vous comptez avant de modifier le routage ou le filtrage, car un nouveau tunnel ne devrait jamais être la seule façon non testée de se réparer lui-même.

3. Délivrez les identifiants depuis le propriétaire approuvé

L’exemple Ubuntu installe easy-rsa aux côtés d’OpenVPN pour construire une petite PKI, ce qui est un rôle de délivrance d’identifiants et non un service de tunnel en fonctionnement. Si l’organisation dispose déjà d’un processus de délivrance approuvé, utilisez-le au lieu de créer une AC sans rapport parce qu’un tutoriel en contient une. Gardez la clé privée et le certificat propres à la passerelle distincts de la clé de signature de l’AC, et choisissez délibérément l’emplacement de signature et de sauvegarde. Copier chaque fichier de PKI sur chaque hôte n’est pas une exigence logicielle.

4. Laissez les greffons de bureau aux bureaux

Un éditeur NetworkManager ou un greffon d’importation a un but sur une machine qui utilise ce flux de travail. Ce n’est pas une fonction serveur supplémentaire nécessaire parce que la passerelle parle OpenVPN.

Choisissez un seul propriétaire pour la connexion, et ne lancez pas une seconde copie du même profil gérée depuis le bureau.

5. Acceptez la passerelle avec un vrai client

Moins de paquets n’est pas une passerelle terminée. Le serveur a encore besoin d’un écouteur approuvé, d’identités, de routes, de transfert là où c’est nécessaire, d’une politique de pare-feu étroite et du chemin de retour prévu. Notez où apparaissent ses journaux et comment les mises à jour sont appliquées, car ces deux réponses décident comment une panne sera diagnostiquée plus tard.

Une conception avec sortie Internet et une conception avec accès à un réseau privé ont des exigences de transfert différentes, alors décidez laquelle vous construisez avant d’ouvrir quoi que ce soit. Démarrez un client approuvé et vérifiez la ressource prévue plutôt que l’indicateur du tunnel. Redémarrez ensuite le service de manière contrôlée et confirmez le chemin de démarrage sans surveillance, car une passerelle qui ne monte que sous les yeux de quelqu’un n’est pas encore déployée.