Après l’installation d’ESXi 8 sur mon Dell Latitude 5430, j’ai créé ma première VM : une Debian 13 destinée à l’accès VPN du laboratoire.
OpenVPN fonctionne désormais sur cette machine. Le test a été réalisé depuis le bureau : connexion avec OpenVPN Connect, puis ouverture de l’interface web de l’ESXi à travers le VPN.
Voici les ressources de la VM et les étapes suivies. Toutes les adresses et tous les noms utilisés dans les configurations ci-dessous sont des exemples anonymisés. Ils sont à adapter au réseau concerné.
La première machine virtuelle
Le laboratoire repose sur le portable déjà présenté dans le premier article : 16 Go de RAM, un SSD NVMe de 256 Go et environ 110 Go de datastore disponibles après l’installation d’ESXi.
| Élément | Configuration de la VM |
|---|---|
| Système | Debian 13.7 « trixie » |
| Processeur | 1 vCPU |
| Mémoire | 1 Go |
| Disque virtuel | 10 Go |
| Service | OpenVPN |
| État du VPN | Fonctionnel |
Cette première VM Linux constitue la nouvelle étape du projet. Ses allocations restent modestes sur un hôte de 16 Go, qui devra aussi accueillir les autres machines du laboratoire.
ESXi affiche alors 1,08 Go de stockage utilisé pour cette VM, pour une capacité virtuelle de 10 Go. Les valeurs de CPU et de mémoire visibles sur la capture décrivent cet instant.
Le chemin de l’accès distant
Le VPN permet d’atteindre l’hyperviseur depuis l’extérieur. Sur la box, la redirection concerne TCP 4443 vers la VM Debian ; l’interface d’administration ESXi reste sur le réseau interne.
| Élément | Exemple anonymisé |
|---|---|
| VM OpenVPN | 192.168.50.20 |
| ESXi | 192.168.50.10 |
| Box | 192.168.50.1 |
| Adresse publique d’exemple | 203.0.113.10 |
| Interface réseau Debian | ens192 |
| Réseau des clients VPN | 10.8.0.0/24 |
| Certificat serveur | vpn-server |
| Certificat client | client-pc |
Le schéma est le suivant : client Windows → connexion OpenVPN en TCP 4443 → VM Debian → ESXi. Il décrit le rôle de la VM ; les règles de routage et de filtrage sont détaillées plus bas.
Installer les paquets et vérifier le réseau
Les commandes d’installation ont été exécutées depuis un compte root :
apt update
apt upgrade -y
apt install -y sudo openvpn easy-rsa nftables
Pour contrôler les adresses et la route de la VM :
ip -br addr
ip route
Les adresses de la VM et de l’ESXi ont également été réservées dans le DHCP de la box. Cela évite qu’une redirection ou une route repose sur une adresse qui change au prochain bail.
Les commandes suivantes ont servi à documenter le système et les ressources :
cat /etc/os-release
free -h
df -h /
Préparer les certificats avec Easy-RSA
J’ai utilisé Easy-RSA pour créer l’autorité de certification et les identités du serveur et du client :
make-cadir /root/vpn-pki
chmod 700 /root/vpn-pki
cd /root/vpn-pki
./easyrsa init-pki
./easyrsa build-ca
La clé privée de la CA est protégée par un mot de passe. Le certificat du serveur utilise ici une clé sans mot de passe, afin de permettre le démarrage automatique du service :
./easyrsa build-server-full vpn-server nopass
Pour le client, la demande et la signature ont été réalisées séparément :
./easyrsa gen-req client-pc
./easyrsa sign-req client client-pc
La phrase secrète demandée avec Enter PEM pass phrase protège la clé privée cliente. Elle sera demandée lors de l’utilisation de ce profil dans OpenVPN Connect.
La liste de révocation a été générée avec :
./easyrsa --days=825 gen-crl
Cette CRL doit ensuite être suivie et renouvelée avant son expiration. Les clés privées de la CA et du serveur ne font pas partie du profil distribué au client.
Installer les fichiers et configurer OpenVPN
Depuis le répertoire /root/vpn-pki, les fichiers ont été installés côté serveur :
install -d -m 755 /etc/openvpn/server
install -m 644 pki/ca.crt \
/etc/openvpn/server/ca.crt
install -m 644 pki/issued/vpn-server.crt \
/etc/openvpn/server/server.crt
install -m 600 pki/private/vpn-server.key \
/etc/openvpn/server/server.key
install -m 644 pki/crl.pem \
/etc/openvpn/server/crl.pem
openvpn --genkey tls-crypt /etc/openvpn/server/tls-crypt.key
chmod 600 /etc/openvpn/server/tls-crypt.key
Voici la configuration anonymisée du fichier /etc/openvpn/server/server.conf :
port 4443
proto tcp4-server
dev tun0
disable-dco
topology subnet
server 10.8.0.0 255.255.255.0
push "route 192.168.50.10 255.255.255.255"
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh none
crl-verify /etc/openvpn/server/crl.pem
tls-crypt /etc/openvpn/server/tls-crypt.key
tls-version-min 1.2
remote-cert-tls client
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
allow-compression no
keepalive 10 120
persist-key
persist-tun
user nobody
group nogroup
verb 3
La route annoncée au client cible uniquement l’adresse de l’ESXi, avec un masque /32. Il n’y a pas de redirection de la route Internet par défaut dans cette configuration : la navigation habituelle reste sur la connexion du client.
L’option disable-dco fait partie de la configuration utilisée et désactive l’offload du canal de données.
Routage IPv4, filtrage et redirection sur la box
Une route envoyée au client indique un chemin ; elle ne remplace pas un contrôle d’accès côté serveur.
Le routage IPv4 a été activé de façon persistante sur Debian :
printf 'net.ipv4.ip_forward=1\n' \
> /etc/sysctl.d/90-openvpn-forward.conf
sysctl -p /etc/sysctl.d/90-openvpn-forward.conf
Les règles du fichier /etc/nftables.d/openvpn-esxi.nft remplissent quatre fonctions :
- autoriser le trafic de
tun0vers l’ESXi viaens192; - autoriser les réponses vers les clients VPN ;
- bloquer les autres destinations transférées depuis le VPN ;
- appliquer un masquerade vers l’ESXi, pour éviter de lui ajouter une route de retour vers le réseau VPN.
Voici le fichier de règles utilisé, avec les adresses anonymisées :
add table inet openvpn_esxi
flush table inet openvpn_esxi
table inet openvpn_esxi {
chain forward {
type filter hook forward priority -10; policy accept;
# Rejeter les paquets invalides provenant du VPN.
iifname "tun0" ct state invalid counter drop
# Autoriser les clients VPN à joindre uniquement l'ESXi.
iifname "tun0" oifname "ens192" \
ip saddr 10.8.0.0/24 ip daddr 192.168.50.10 \
counter accept
# Autoriser les réponses vers les clients VPN.
oifname "tun0" ct state established,related counter accept
# Bloquer les autres flux transférés depuis ou vers le VPN.
iifname "tun0" counter drop
oifname "tun0" counter drop
}
}
add table ip openvpn_esxi_nat
flush table ip openvpn_esxi_nat
table ip openvpn_esxi_nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
# Présenter à l'ESXi l'adresse LAN de la VM VPN comme source.
oifname "ens192" \
ip saddr 10.8.0.0/24 ip daddr 192.168.50.10 \
counter masquerade
}
}
La restriction porte ici sur la destination ESXi, tous ports confondus. La politique accept laisse les autres trafics transférés, sans lien avec tun0, suivre les éventuelles autres règles de la machine. Ce fichier ne filtre pas les connexions à la VM Debian elle-même : il ne contient pas de chaîne input.
Les autres chaînes de filtrage présentes restent à prendre en compte : un accept dans cette chaîne n’empêche pas une autre chaîne forward de bloquer ensuite le paquet. Ce comportement est décrit dans la documentation des chaînes nftables.
Une fois le fichier de règles préparé, la validation puis l’application ont été réalisées avec :
nft -c -f /etc/nftables.d/openvpn-esxi.nft
nft -f /etc/nftables.d/openvpn-esxi.nft
Pour le chargement au démarrage, cette ligne a été ajoutée à /etc/nftables.conf :
include "/etc/nftables.d/openvpn-esxi.nft"
Puis le service a été activé :
systemctl enable nftables
Le fichier et son include doivent s’intégrer aux règles déjà présentes sur la machine. La syntaxe de l’inclusion est décrite dans la documentation nftables.
Sur la box, la redirection NAT/PAT créée est la suivante, toujours avec les adresses d’exemple :
| Port externe | Port interne | Protocole | Destination |
|---|---|---|---|
| 4443 | 4443 | TCP | 192.168.50.20 |
Créer le profil Windows et établir la connexion
Le service OpenVPN a été activé, puis son état et son écoute ont été vérifiés :
systemctl enable --now openvpn-server@server
systemctl status openvpn-server@server
ss -lntp | grep 4443
ping -c 3 192.168.50.10
Le service a confirmé Initialization Sequence Completed et l’écoute sur TCP 4443. Le ping lancé depuis Debian contrôle le chemin local jusqu’à l’ESXi ; la validation depuis l’extérieur est une étape distincte.
La base anonymisée du profil client-pc.ovpn est :
client
dev tun
proto tcp-client
remote 203.0.113.10 4443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name vpn-server name
tls-version-min 1.2
verb 3
Ce bloc seul ne constitue pas le profil complet. Les éléments suivants ont été intégrés dans les blocs correspondants du fichier :
| Bloc | Contenu |
|---|---|
<ca> |
Certificat public de la CA |
<cert> |
Certificat du client |
<key> |
Clé privée chiffrée du client |
<tls-crypt> |
Clé TLS partagée |
Les valeurs de ces blocs restent privées et ne sont pas reproduites dans cet article. Le profil complet est un fichier d’accès à protéger.
Le nom attendu du certificat serveur est contrôlé par verify-x509-name vpn-server name, en complément de remote-cert-tls server. Les options sont détaillées dans le manuel OpenVPN.
Alors que le PC Windows était encore sur le réseau local, le profil a été récupéré avec PowerShell :
scp utilisateur@192.168.50.20:/home/utilisateur/client-pc.ovpn "$env:USERPROFILE\Downloads\client-pc.ovpn"
Le chemin ci-dessus suppose que le profil final a été placé dans le répertoire de cet utilisateur. Après récupération, il a été importé dans OpenVPN Connect, avec la phrase secrète de la clé cliente.
Ce qui a été vérifié
Le test d’accès distant a ensuite été réalisé depuis le bureau : connexion VPN établie dans OpenVPN Connect, puis ouverture de l’adresse interne de l’ESXi :
https://192.168.50.10/ui
L’ouverture de l’interface web à travers le VPN a réussi. Le lab dispose maintenant d’une première VM utile et d’un accès distant pour continuer les essais.
Cela ne donne pas un nombre maximal de connexions, un débit garanti ou une mesure de charge : le résultat confirmé ici est la connexion et l’accès à l’hyperviseur.
La suite du homelab pourra revenir sur Windows Server, Active Directory et DNS. L’article de départ conserve le détail du matériel et des difficultés rencontrées pour installer ESXi.