Introduction

J’ai chez moi un serveur sous Proxmox, un hyperviseur qui me permet de créer des machines virtuelles et des conteneurs Linux pour héberger les services de mes diverses activités d’auto-hébergement.

Avec un seul abonnement internet de particulier, je n’ai qu’une seule adresse IP résidentielle. Je suis donc vite limité par le nombre de ports disponibles, et je ne peux pas faire tourner tous les services que je souhaite dans de bonnes conditions.

Ouvrir des ports reste possible, mais certains opérateurs retirent cette option au fil du temps, et les box 4G/5G ne la proposent pas du tout à cause du CG-NAT.

Ces limitations m’ont poussé à trouver un moyen d’avoir plusieurs adresses IP publiques chez moi, dédiées, protégées par un anti-DDoS et peu chères. Faute de solution existante, j’ai bricolé la mienne, puis je l’ai transformée en script pour qu’elle soit reproductible en quelques minutes.

Principe de fonctionnement

Comment fonctionne l'internet

Un VPS chez un hébergeur reçoit une ou plusieurs adresses IP publiques supplémentaires. Un tunnel WireGuard relie ce VPS à une machine chez moi, et le VPS lui route ces adresses telles quelles, sans NAT. Vu de l’extérieur, ma machine est directement sur internet avec sa propre IP, tout en restant derrière ma box.

Le choix de l’hébergeur

Cette méthode fonctionne chez n’importe quel hébergeur qui vend des adresses IP supplémentaires (aussi appelées IP failover) et les route vers votre VPS, comme HostMyServers, OVHcloud ou RoyaleHosting. Le script et la configuration restent les mêmes partout ; seule la commande des adresses dans l’espace client change.

Quelques critères pour choisir :

le prix des adresses IP supplémentaires, qui varie beaucoup d’un hébergeur à l’autre (frais uniques ou abonnement mensuel) ;
une protection anti-DDoS incluse, puisque le VPS devient la porte d’entrée de vos services ;
le débit réseau du VPS : WireGuard consomme très peu de ressources et une offre d’entrée de gamme suffit, mais tout votre trafic passera par lui ;
un datacenter proche de chez vous, pour limiter la latence ajoutée par le tunnel.

Achat d’adresses IP supplémentaires

Ce tutoriel nécessite au moins une adresse IPv4 supplémentaire sur le VPS.

Commandez-la depuis l’espace client de votre hébergeur, en général dans la configuration réseau du VPS. Prenez les adresses IPv4 à l’unité : le script attribue une adresse à chaque profil. Le routage d’un bloc entier vers un routeur est abordé dans « Pour aller plus loin ».

Une fois l’adresse livrée, notez bien, pour la suite :

l’adresse IP principale du VPS : celle qu’il avait à sa livraison, qui a généralement déjà un reverse DNS fourni par l’hébergeur ;
l’adresse IP supplémentaire : celle que vous venez de commander.

Gardez ces deux adresses sous les yeux pour ne pas les confondre plus loin.

Commandez raisonnablement : il ne reste plus beaucoup d’adresses IPv4, et il est inutile d’en réserver si elles restent inutilisées.

Prérequis sur le VPS

Une fois votre VPS livré, choisissez sa distribution dans l’espace client. J’installe Debian 12 ou plus récent, mais n’importe quelle distribution avec systemd convient : Debian, Ubuntu, Fedora, Rocky ou Alma, Arch, openSUSE, ou encore Flatcar.

Les identifiants de connexion arrivent généralement par e-mail une fois l’installation terminée.

Connectez-vous en SSH avec un client comme PuTTY ou Termius.

L’adresse IP supplémentaire ne doit pas être montée sur le VPS : ni sur son interface réseau, ni dans sa configuration (netplan, cloud-init, /etc/network/interfaces…). L’hébergeur la route vers le VPS, mais c’est la machine au bout du tunnel qui doit la porter. Si le VPS la monte aussi, il répond lui-même au trafic destiné à cette adresse et rien n’arrive jusqu’au client.

Vérifiez-le avec :

ip -4 addr

Si l’adresse supplémentaire apparaît sur eth0 (ou ens3, selon la distribution), retirez-la de la configuration réseau avant de continuer. Certains hébergeurs la configurent automatiquement, d’autres non : dans ce second cas, il n’y a rien à faire.

Installation de WireGuard

Commençons par mettre à jour le VPS :

apt update
apt full-upgrade -y
reboot

Une fois le VPS redémarré, déployons le serveur WireGuard avec mon script. C’est un fork de angristan/wireguard-install devenu un installeur tout-en-un : VPN classique, routage d’adresses IP publiques, choix de l’endpoint pour chaque profil, intégration du pare-feu et vue d’état.

curl -O https://raw.githubusercontent.com/tbringuier/wireguard-install/master/wireguard-install.sh
chmod +x wireguard-install.sh
./wireguard-install.sh

Le script est open source et documenté sur github.com/tbringuier/wireguard-install. Une grande partie a été écrite avec Claude, l’IA d’Anthropic, puis relue et testée par mes soins sur Debian, Ubuntu, Fedora, Rocky, Arch et openSUSE.

Les questions du script

Le script pose une série de questions. Les valeurs proposées par défaut conviennent presque partout ; la seule à changer est la question sur le routage public, à laquelle il faut répondre yes.

Welcome to the WireGuard installer!
The git repository is available at: https://github.com/tbringuier/wireguard-install

I need to ask you a few questions before starting the setup.
You can keep the default options and just press enter if you are ok with them.

Public addresses of this server (leave empty the ones it does not have):
Public IPv4: 203.0.113.10
Public IPv6: 2001:db8:42::1
Hostname pointing to this server:
Public interface: eth0
WireGuard interface name: wg0
Tunnel MTU [1280-1500]: 1420
Server WireGuard IPv4: 10.66.66.1
Server WireGuard IPv6: fd42:42:42::1
Server WireGuard port [1-65535]: 62052
First DNS resolver to use for the clients: 1.1.1.1
Second DNS resolver to use for the clients (optional): 1.0.0.1
Enable public IP routing support [yes/no]: yes
Public clients can get an IPv6 from the block your provider routes to this server.
Public IPv6 prefix of this server (empty if none): 2001:db8:42::/64

WireGuard uses a parameter called AllowedIPs to determine what is routed over the VPN.
Allowed IPs list for generated clients (leave default to route everything): 0.0.0.0/0,::/0

Okay, that was all I needed. We are ready to setup your WireGuard server now.
You will be able to generate a client at the end of the installation.
Press any key to continue...

Quelques précisions :

L’adresse IPv4 publique proposée par défaut est celle de l’interface du VPS, donc l’adresse principale (celle qui a un reverse DNS), pas l’adresse supplémentaire.
L’IPv6 et le nom d’hôte sont facultatifs. Ils servent à proposer plusieurs endpoints aux clients, on y revient plus bas.
Le préfixe IPv6 est détecté sur l’interface du VPS. Il permet au script de proposer lui-même une IPv6 publique à chaque client.
Si ufw ou firewalld est actif sur le VPS, le script le détecte et propose d’ajouter lui-même les règles nécessaires (port UDP entrant, forwarding sur wg0). Répondez y.

Le premier profil

Le script installe les paquets, active le routage, génère les clés, démarre le tunnel, puis demande le nom du premier profil. J’appelle le mien MaVM :

The client name must consist of alphanumeric character(s). It may also include underscores or dashes and can't exceed 15 chars.
Client name: MaVM

Vient ensuite la question importante : le mode d’adressage du client.

private : le client reçoit une adresse privée du tunnel (10.66.66.x) et sort derrière l’IP du VPS, comme avec un VPN classique.
public : le client reçoit une de vos adresses supplémentaires, routée directement et sans NAT. C’est ce que nous voulons.
mixed : le client reçoit les deux.

A private client gets an address from the tunnel subnet and is NATed behind the server.
A public client gets one of the server's additional public addresses, routed without NAT.
A mixed client gets both.
Client address mode [private/public/mixed]: public

Public addresses must be routed to this server by your provider (additional/failover IP).
Public client IPv4 (leave empty if unused): 198.51.100.25
Public client IPv6 (leave empty if unused):

C’est ici que l’on saisit l’adresse IP supplémentaire achetée chez votre hébergeur. Pour l’IPv6, le script propose la prochaine adresse libre du bloc du VPS ; laissez vide si vous n’en voulez pas.

Le script refuse une adresse déjà attribuée à un autre profil, ou configurée sur une interface du VPS (voir les prérequis).

Dernière question : l’endpoint auquel le client se connectera. Si le VPS a une IPv6, elle est recommandée : ce sont surtout les IPv4 qui sont attaquées, et un tunnel monté en IPv6 ne souffre pas d’une attaque visant l’IPv4 du VPS. Il faut évidemment que le client dispose d’une connectivité IPv6 ; sinon, choisissez l’IPv4 ou un nom de domaine.

Endpoint this client connects to (it must be able to reach it):
   1) IPv6 [2001:db8:42::1]:62052 (recommended: IPv4 addresses attract most attacks)
   2) IPv4 203.0.113.10:62052
   3) Another hostname or address
Select an option [1-3]: 2

Le profil est créé : un QR code s’affiche et le fichier /root/wg0-client-MaVM.conf est écrit.

Ce que le script a mis en place

Tout le reste est automatique. Pour la curiosité, voici ce qui tourne désormais sur le VPS :

une table nftables inet wireguard, qui fait le NAT des clients privés et clampe le MSS TCP dans les deux sens à la MTU du tunnel. C’est ce qui règle les fameux soucis de MTU (merci Diggyworld et Hecate), y compris pour les clients Windows ou mobiles qui ne peuvent pas exécuter de hooks ;
une entrée proxy ARP (ip neigh proxy) par adresse publique, pour que le VPS réponde aux requêtes ARP de l’hébergeur, et son équivalent proxy NDP pour l’IPv6 ;
un service systemd wg-public-ipv4-announce@wg0, qui annonce chaque adresse publique en gratuitous ARP toutes les secondes. C’est l’équivalent de la boucle arping historique du tutoriel (merci titin et TheOrion-OVH) ;
la régénération de /etc/wireguard/wg0.conf à chaque ajout ou suppression de profil, appliquée à chaud sans couper les autres tunnels, avec une sauvegarde de la version précédente dans wg0.conf.bak.

Et voici le profil client généré :

[Interface]
PrivateKey = MM2OFVfYrJFtdAgebfPJL2hDtjaslufqoJ1yzvdN+X8=
Address = 198.51.100.25/32
DNS = 1.1.1.1,1.0.0.1
MTU = 1420

[Peer]
PublicKey = udEYVLpHnWb4o7kgjZ4pCnfUaVjqd9inXAUmak9mXxM=
PresharedKey = t+rgwqN3j8LccHtgi7GULlwBrf8ghY8HAbZN6cagP8s=
Endpoint = 203.0.113.10:62052
AllowedIPs = 0.0.0.0/0,::/0
PersistentKeepalive = 15

Vous pouvez vérifier l’état du serveur à tout moment :

systemctl status wg-quick@wg0
systemctl status wg-public-ipv4-announce@wg0
wg show

Pour ajouter d’autres profils (une autre adresse supplémentaire, ou un simple client VPN en mode private), relancez le script. Son menu permet d’ajouter ou de révoquer des profils, de désinstaller WireGuard, et d’afficher une vue d’état : pour chaque client, ses adresses, son endpoint, l’adresse depuis laquelle il est connecté, la date du dernier handshake et le trafic échangé.

Le profil est prêt à être déployé.

Déploiement du profil WireGuard

Le profil s’installe sur n’importe quelle plateforme : Windows, Linux, Android, macOS, iOS et bien d’autres.

Voici les commandes pour un Linux à base de Debian :

# Installer WireGuard et resolvconf
apt install wireguard-tools resolvconf

# Installer le profil : collez le contenu de wg0-client-MaVM.conf dans ce fichier
nano /etc/wireguard/wg0.conf

# Activer le tunnel maintenant et à chaque démarrage
systemctl enable wg-quick@wg0 --now

# Vérifier que l'adresse est bien montée
ip a
curl ifconfig.me

Diagnostics

Si le profil ne fonctionne pas, vérifiez d’abord que vous n’avez pas confondu les adresses IP, puis relisez la section des prérequis. Ensuite, sur le VPS :

# Le tunnel est-il monté, et le client a-t-il fait un handshake récent ?
wg show

# Le service d'annonce ARP tourne-t-il, et pour quelles adresses ?
systemctl status wg-public-ipv4-announce@wg0
journalctl -u wg-public-ipv4-announce@wg0 -f

# Le VPS répond-il en ARP pour l'adresse supplémentaire ?
ip neigh show proxy

# La table nftables du tunnel (NAT et clamp MSS) est-elle chargée ?
nft list table inet wireguard

# Les annonces partent-elles réellement sur le réseau ?
tcpdump -ni eth0 arp

Remplacez eth0 par le vrai nom de votre interface : il change selon la distribution et l’hébergeur.

Les cas classiques :

Pas de handshake dans wg show : le port UDP ou l’endpoint est faux côté client, ou le client n’a pas de connectivité (IPv6 par exemple) vers cet endpoint.
Handshake présent mais pas de trafic : l’adresse supplémentaire est configurée sur l’interface du VPS (voir les prérequis), ou l’hébergeur ne la route pas vers ce VPS.
Certains sites ne chargent pas : problème de MTU. Le script fixe la MTU du tunnel des deux côtés et clampe le MSS sur le serveur pour tous les clients ; vérifiez que votre application WireGuard a conservé la ligne MTU = 1420 du profil.
Ça marche une fois sur deux après un redémarrage du VPS : regardez journalctl -u wg-public-ipv4-announce@wg0, c’est le service d’annonce ARP qui corrige ce cas.

Conclusion et remerciements

Et voilà : vous avez des adresses IP failover chez vous, protégées par un anti-DDoS, utilisables sur n’importe quel appareil.

Cette astuce m’a fait franchir un grand pas dans l’auto-hébergement, pour mes services comme pour ceux que j’héberge pour d’autres : elle offre la puissance d’un VPS avec des IP dédiées, à prix réduit et avec une qualité de service comparable.

Ce tutoriel existe depuis juillet 2020. Il a été remasterisé en septembre 2024, puis simplifié en octobre 2026 : toutes les manipulations manuelles d’alors (règles de pare-feu, sysctl, boucle arping, édition des profils) sont désormais faites par le script.

Merci à

@Aven678, pour avoir énormément simplifié la gestion des IP et la création de profils ;
@DrKnaw, pour avoir corrigé des bugs de mon système qui n’était pas tout à fait fini à l’époque ;
@MaelMagnien, pour avoir testé le tutoriel de bout en bout ;
@Gogow_, pour m’avoir fait déboguer ma doc plusieurs fois ;
@Diggyworld, pour avoir passé toute une soirée à trouver une solution à ces fichus soucis de MTU ;
@titin, pour avoir trouvé la commande arping qui règle certains soucis de routage ;
@Hecate, pour la règle iptables qui corrigeait les soucis de MTU ;
@TheOrion-OVH, pour le correctif ARP qui ne fonctionnait qu’une fois sur deux et quelques fautes de frappe dans la documentation.

Et merci à toutes les personnes qui m’ont écrit sur Discord pour améliorer cette documentation ou simplement dire merci.

Pour aller plus loin

Routage d’un bloc entier (/29, /64…) vers un routeur chez soi : ce n’est pas géré par le script, mais un ami a rédigé une très bonne documentation pour monter les adresses sur un routeur VyOS, ce qui évite de déployer un profil WireGuard par machine : Router un subnet IPv4 chez soi avec WireGuard + VyOS.

Si vous souhaitez faire figurer votre « fork » de cette documentation ici, écrivez-moi sur Discord ou Telegram.

Avoir des adresses IPv4/IPv6 chez soi avec un tunnel WireGuard