OpenVPN sur VPS : installation, sécurité et dépannage

Les solutions VPN commerciales mutualisées imposent de faire confiance à un prestataire tiers qui peut journaliser, revendre ou exposer vos données de connexion. En hébergeant OpenVPN Server sur votre propre VPS, vous êtes le seul administrateur : vous choisissez le niveau de journalisation, les utilisateurs autorisés et les protocoles de chiffrement (TLS 1.3, AES-256-GCM). C'est également la solution idéale pour interconnecter des équipes distribuées, sécuriser l'accès à vos services internes ou contourner les restrictions réseau d'un environnement d'entreprise, le tout à un coût maîtrisé.

Avant de commencer, vérifiez ces points sur votre VPS.

Ressources minimales : 1 vCPU et 512 Mo de RAM suffisent pour un usage personnel ou jusqu'à 10 utilisateurs simultanés. Au-delà de 50 connexions actives, comptez 2 vCPU et 1 Go de RAM pour absorber le chiffrement sans dégradation de bande passante.

Système d'exploitation : Ubuntu 22.04 LTS ou Debian 12 (les deux sont supportés par le dépôt officiel OpenVPN). AlmaLinux 9 et Rocky Linux 9 fonctionnent aussi avec les paquets EPEL.

Port réseau : UDP 1194 (défaut) ou TCP 443 pour passer les pare-feux restrictifs. Sur votre VPS ServOrbit, ouvrez ce port dans les règles de sécurité avant de lancer l'installation. Un seul port suffit.

Accès root : indispensable pour créer les interfaces réseau virtuelles (tun0), modifier les règles iptables et activer le forwarding IP.

Forwarding IP : activez-le avant de continuer :

echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p

Créez /etc/openvpn/server.conf avec le contenu suivant. Chaque directive est commentée.

port 1194
proto udp
dev tun

ca   /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key  /etc/openvpn/server.key
dh   /etc/openvpn/dh.pem

tls-auth /etc/openvpn/ta.key 0
key-direction 0

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt

# Pousser la route par défaut (full tunnel)
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

keepalive 10 120
cipher AES-256-GCM
tls-version-min 1.2

user nobody
group nogroup
persist-key
persist-tun

status  /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 3

Activez et démarrez le service :

mkdir -p /var/log/openvpn
systemctl enable --now openvpn@server
systemctl status openvpn@server

Full tunnel (redirect-gateway def1) : tout le trafic du client passe par le VPN. Utile pour protéger des utilisateurs sur des réseaux non fiables ou pour unifier les sorties Internet. Inconvénient : la bande passante du VPS devient le goulot d'étranglement pour tous les flux.

Split tunneling : seul le trafic à destination de votre réseau privé (ex. 10.8.0.0/24) passe par le VPN. Le reste sort directement depuis le poste client. Pour l'activer, remplacez la ligne redirect-gateway par des routes spécifiques dans server.conf :

push "route 192.168.1.0 255.255.255.0"

Cela réduit la charge sur le serveur et améliore les performances globales, mais les connexions hors VPN ne sont plus protégées.

Un fichier .ovpn autonome embarque tous les certificats. Il se génère ainsi :

cat > /tmp/client1.ovpn << EOF
client
dev tun
proto udp
remote <IP-de-votre-VPS> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
verb 3
key-direction 1
<ca>
$(cat /etc/openvpn/easy-rsa/pki/ca.crt)
</ca>
<cert>
$(cat /etc/openvpn/easy-rsa/pki/issued/client1.crt)
</cert>
<key>
$(cat /etc/openvpn/easy-rsa/pki/private/client1.key)
</key>
<tls-auth>
$(cat /etc/openvpn/ta.key)
</tls-auth>
EOF

Transférez ce fichier au client par un canal sécurisé (SCP ou un lien à usage unique). Il suffit ensuite de l'importer dans OpenVPN Connect (Windows, macOS, Android, iOS) ou NetworkManager (Linux) pour établir la connexion.

Pare-feu ufw — n'ouvrir que ce qui est nécessaire :

ufw allow ssh
ufw allow 1194/udp
ufw enable

Si vous utilisez le port TCP 443 à la place d'UDP 1194, adaptez la règle.

fail2ban pour le port OpenVPN :

Créez /etc/fail2ban/jail.d/openvpn.conf :

[openvpn]
enabled  = true
port     = 1194
protocol = udp
filter   = openvpn
logpath  = /var/log/openvpn/openvpn.log
maxretry = 5
bantime  = 3600

Créez ensuite le filtre /etc/fail2ban/filter.d/openvpn.conf :

[Definition]
failregex = .*TLS Error: TLS key negotiation failed.*<HOST>.*
            .*VERIFY ERROR:.*<HOST>.*

Activez :

systemctl restart fail2ban
fail2ban-client status openvpn

Désactiver IPv6 si inutile : une interface IPv6 non protégée peut contourner votre tunnel. Si votre infrastructure n'a pas besoin d'IPv6 :

echo 'net.ipv6.conf.all.disable_ipv6=1' >> /etc/sysctl.conf
echo 'net.ipv6.conf.default.disable_ipv6=1' >> /etc/sysctl.conf
sysctl -p

MTU et fragmentation : le chiffrement OpenVPN ajoute des en-têtes. Par défaut, la MTU du tunnel (tun-mtu) est 1500, mais l'encapsulation UDP peut provoquer de la fragmentation sur certains réseaux. Pour éviter cela, ajoutez dans server.conf :

tun-mtu 1400
mssfix 1360

Si vous observez des transferts lents ou des coupures sur des connexions avec une MTU basse (réseaux mobiles, certains VPN d'entreprise), réduisez tun-mtu à 1300.

Choix du cipher : AES-256-GCM est recommandé pour les noyaux Linux modernes, qui bénéficient des instructions matérielles AES-NI (vérifiez avec grep -m1 'aes' /proc/cpuinfo). Pour des serveurs très contraints en CPU, AES-128-GCM divise le coût de chiffrement par deux sans réduction de sécurité significative pour des usages courants.

UDP ou TCP : UDP 1194 est le mode par défaut et le plus performant. TCP 443 est utile pour contourner les pare-feux d'entreprise restrictifs, mais introduit le problème du « TCP over TCP » (retransmissions redondantes) qui dégrade les performances en cas de perte de paquets.

TLS Error: TLS key negotiation failed

Cette erreur apparaît quand le client ne peut pas atteindre le serveur sur le port configuré. Vérifiez que le port est ouvert (ss -ulnp | grep 1194), que la règle firewall est active et que la clé ta.key est identique côté serveur (key-direction 0) et côté client (key-direction 1).

Routes non appliquées après connexion

Si le trafic ne passe pas par le tunnel malgré une connexion établie, vérifiez que le forwarding IP est actif (cat /proc/sys/net/ipv4/ip_forward doit retourner 1) et qu'une règle NAT est en place :

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Remplacez eth0 par l'interface principale de votre VPS (ip route get 8.8.8.8 pour l'identifier).

Connexions qui tombent régulièrement

Si le tunnel se déconnecte toutes les 2 minutes, vérifiez le keepalive dans server.conf (keepalive 10 120 : ping toutes les 10 s, timeout à 120 s). Côté client, ajoutez ping-restart 60 dans le profil .ovpn pour forcer une reconnexion propre avant le timeout serveur.

VERIFY ERROR: depth=0, error=certificate is not yet valid

L'horloge du serveur ou du client est décalée. Synchronisez NTP : timedatectl set-ntp true.