Le symptôme est toujours le même, et il est déroutant parce que tout a l'air de marcher :
wg showaffiche un handshake récent ;- le client a bien reçu son adresse dans le tunnel ;
- et pas un octet ne sort vers Internet.
La cause n'est presque jamais le port. Elle tient à une distinction qu'UFW fait et qu'on oublie en le configurant : entrer sur une machine et la traverser sont deux autorisations différentes.
Le malentendu de départ
sudo ufw allow 51820/udp autorise les paquets à entrer sur le serveur, sur ce port. C'est
nécessaire, et c'est tout ce que cette règle fait.
Le trafic de vos clients, lui, ne s'arrête pas au serveur : il le traverse pour ressortir par l'interface publique. Ce passage-là relève d'une autre chaîne de filtrage, que rien n'a autorisée — et qu'UFW refuse par défaut.
D'où la scène du dessus : la porte d'entrée est ouverte, le tourniquet ne s'ouvre pas.
Les quatre points à vérifier, dans cet ordre
1. Le transfert IP, et le piège du fichier qui écrase l'autre
UFW charge son propre fichier sysctl au démarrage, et il prime sur celui du système. Un réglage
posé dans /etc/sysctl.conf peut donc être écrasé au premier ufw enable.
Le bon endroit est /etc/ufw/sysctl.conf :
net/ipv4/ip_forward=1 net/ipv6/conf/default/forwarding=1 net/ipv6/conf/all/forwarding=1
Puis on vérifie la valeur effective, pas le fichier :
sysctl net.ipv4.ip_forward
C'est le point qui coûte le plus de temps, parce que le réglage a l'air fait. On relit un fichier correct en se demandant pourquoi rien ne change.
2. Le transit, qui n'est pas l'entrée
Deux façons de l'autoriser. La ciblée, à préférer :
sudo ufw route allow in on wg0 out on eth0
Et la globale, dans /etc/default/ufw :
DEFAULT_FORWARD_POLICY="ACCEPT"
La seconde ouvre le transit pour toutes les interfaces. Elle dépanne en dix secondes, ce qui en fait un bon test de diagnostic — et une mauvaise configuration à laisser en place.
3. La traduction d'adresses, qu'UFW ne pose jamais tout seul
Sans elle, les paquets sortent avec leur adresse du tunnel, à laquelle aucune machine sur Internet
ne sait répondre. Dans /etc/ufw/before.rules, tout en haut du fichier, avant la ligne
*filter :
*nat :POSTROUTING ACCEPT [0:0] -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE COMMIT
Deux erreurs classiques ici : placer ce bloc après *filter (il est alors ignoré) et recopier
eth0 sans vérifier.
4. Le nom réel de l'interface de sortie
eth0 est une convention d'article, pas une réalité. Selon l'hébergeur, ce sera ens3, enp1s0
ou autre chose. La commande qui donne la réponse sans deviner :
ip route get 1.1.1.1
L'interface citée dans la sortie est celle qu'il faut écrire dans les deux règles ci-dessus.
Une barrière tubulaire jaune occupe le premier plan. Deux chaînes pendent librement de leurs crochets, sans être reliées entre elles, avec un cadenas rouge sous l'une d'elles. Derrière, une cour asphaltée avec des flaques, des bâtiments bas et un ciel de fin de journée.
Le test qui sépare les deux familles de causes
Depuis un client connecté, essayez de joindre l'adresse du serveur dans le tunnel (souvent
10.8.0.1) :
| ce que vous observez | ce que cela dit |
|---|---|
| l'adresse du tunnel répond, rien d'extérieur ne répond | le tunnel va bien : transit ou traduction d'adresses manquant |
| l'adresse du tunnel ne répond pas non plus | le problème est en amont : clés, AllowedIPs, routage du client |
| tout répond mais les noms ne se résolvent pas | ce n'est pas UFW, c'est le DNS poussé au client |
Cette troisième ligne mérite d'être connue : « je n'ai pas Internet » signifie très souvent « aucun nom ne se résout ». Une adresse IP jointe directement le montre en une commande.
Après application : recharger, et vérifier ce qui tourne
before.rules n'est relu qu'au rechargement :
sudo ufw disable && sudo ufw enable
Puis on regarde l'état réel, pas le fichier qu'on vient d'écrire :
sudo ufw status verbose sudo iptables -t nat -L POSTROUTING -n -v
Un dernier point qui produit des configurations en double : si vos règles PostUp et PostDown
dans le fichier WireGuard posent déjà du MASQUERADE, vous n'avez pas besoin du bloc *nat
ci-dessus. Les deux ensemble ne cassent pas grand-chose, mais vous rendent la prochaine panne
beaucoup plus difficile à lire — et il y aura une prochaine panne.
Ce que ce réglage protège, et ce qu'il ne protège pas
Un serveur correctement pare-feuté décide ce qui se connecte à lui. C'est utile, et c'est étroit. Cela ne dit rien de ce que votre navigateur raconte pendant que vous naviguez dans ce tunnel, ni de ce qu'un appareil perdu déverrouille encore, ni du compte qui peut réinitialiser tous les autres chez vous.
Ce sont des habitudes plus que des règles de filtrage, et elles ne se règlent pas dans
before.rules.
Situez votre propre surface d'attaque — 10 questions, environ trois minutes, sans compte, sans adresse e-mail, et rien n'est conservé. Le résultat nomme le geste qui, chez vous, réduit le plus l'exposition — et pour quelqu'un qui auto-héberge, ce n'est généralement pas une règle de pare-feu de plus.
En résumé
| Ce qu'on croit régler | Ce qu'on règle vraiment |
|---|---|
ufw allow 51820/udp | l'entrée sur le serveur, pas le transit |
net.ipv4.ip_forward dans /etc/sysctl.conf | rien, si UFW recharge le sien par-dessus |
| « UFW gère le NAT » | il n'en pose aucun sans bloc *nat explicite |
eth0 recopié d'un tutoriel | l'interface d'un autre serveur que le vôtre |
La phrase à retenir tient en une ligne : un port ouvert dit que les paquets peuvent entrer, pas qu'ils peuvent traverser.
★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · 200+ Mbps garantis
Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→
