Bonjour
Suite à un autre message il y a 4 jours, je n'ai pas essayé avec network-manager...
Donc :
J'installe wireguard
sudo apt install wireguard
je copie dans /etc/wireguard/wg0.conf une configuration (générée par une freebox) :
[Interface]
PrivateKey = **************************************
Address = 192.168.27.71/32
DNS = nnn.nnn.nnn.nnn
MTU = 1360
[Peer]
PublicKey = PJ61Y3lfxoChmdXLUlDs3IKB9PIEUXWkmUCmGbPq0mk=
Endpoint = xxx.xxx.xxx.xxx:44570
AllowedIPs = 0.0.0.0/0, 192.168.27.64/27, 192.168.1.0/24
PersistentKeepalive = 0
et je fais :
sudo wg-quick up wg0
Plusieurs commandes ip s'exécutent, puis resolvconf qui ne retourne rien et bloque le terminal.
A ce stade, on ne peut plus faire un ping sur le serveur.
Il faut désinstaller wireguard pour s'en sortir....
Que se passe-t-il et comment faire ?
Je précise que ufw est désactivé.
Si je le réactive tout marche bien tant que je ne reboote pas.
Après reboot le serveur devient inaccessible aussi, même sans wireguard.
Bonjour @MartinR2
En exécutant wg-quick up wg0, la commande modifie la table de routage du serveur afin d’envoyer tout le trafic (y compris les connexions SSH) à travers le tunnel VPN vers le pair de la Freebox.
Pour le résoudre, je vous recommande les étapes suivantes :
- Accédez au mode rescue
Depuis l’espace client d’OVHcloud, redémarrez votre serveur en mode rescue. Cela vous permettra d’accéder aux fichiers du système et d’annuler les changements sans besoin de connexion SSH.
- Montez le système de fichiers :
mount /dev/sda1 /mnt (adaptez la partition selon votre système)
- Désactivez ou supprimez la configuration de WireGuard :
rm /mnt/etc/wireguard/wg0.conf
- Vérifiez la configuration persistante :
chroot /mnt
systemctl disable wg-quick@wg0
Quittez l’environnement chroot et redémarrez le serveur en mode normal.
Si vous souhaitez utiliser WireGuard sans perdre l’accès SSH, la clé est de modifier la ligne AllowedIPs dans le fichier wg0.conf. Au lieu de AllowedIPs = 0.0.0.0/0, vous devez limiter les routes qui sont envoyées à travers le tunnel.
Tenez-nous au courant, salut.
Sergio Turpín
Bonjour et merci pour votre réponse.
Alors, que faudrait-il mettre en AllowedIPs ?
Salut @MartinR2
Au lieu de rediriger tout le trafic, tu dois simplement envoyer à travers le tunnel les réseaux dont tu as réellement besoin. Comme dans ta configuration de la Freebox tu n’as besoin d’accéder qu’aux réseaux locaux de ta maison, tu dois remplacer la ligne AllowedIPs par celle-ci :
AllowedIPs = 192.168.27.64/27, 192.168.1.0/24
Supprime 0.0.0.0/0. Ainsi, le trafic vers les réseaux 192.168.27.64/27 et 192.168.1.0/24 passera par le tunnel VPN, et le reste continuera à utiliser la table de routage normale de ton serveur, sans blocages.
Tiens nous au courant, un salut 
Sergio Turpín
Ok, ça fonctionne, merci !
Ce que je ne comprends pas c'est que j'avais avant un serveur physique (chez moi, pas chez OVH), je n'avais pas enlevé le masque 0.0.0.0/0 (qui est généré par la Freebox) et ça fonctionnait parfaitement.
C'est le réseau OVH qui impose de supprimer ce masque ?
Salut @MartinR2
Sur ton serveur physique à la maison, tout est sur le même réseau local. Lorsque tu configures le VPN sur ce serveur, la machine physique se trouve déjà sur le réseau local et possède une route directe et naturelle vers ton routeur, la Freebox, et le reste du réseau domestique.
Lorsque tu as le VPS d'OVH, il n'y a pas de réseau local que tu partages avec ta Freebox. L'IP du serveur est publique, et ta connexion SSH va directement à cette IP publique. En activant WireGuard avec AllowedIPs = 0.0.0.0/0, tu dis au serveur que tout le trafic doit passer par le tunnel VPN. Comme le tunnel ne sert qu'à atteindre ta maison, le serveur perd sa route par défaut vers Internet, et c’est pourquoi ta connexion SSH cesse de fonctionner.
Je suis content que tout fonctionne 
Cordialement,
Sergio Turpín
En supprimant le masque 0.0.0.0/0 le système reste accessible depuis l'extérieur, et il accède aussi au VPN Wireguard, ce qui m'a fait dire que ça fonctionne.
Malheureusement on perd les accès depuis le serveur, utilisés pour différents services de mises à jour.
Par exemple, au login :
Failed to connect to ``https://changelogs.ubuntu.com/meta-release-lts``. Check your Internet connection or proxy settings
Ce problème n'existait pas avec le serveur qui était chez-moi dans mon réseau.
Que peut-on faire pour retrouver cette connexion du serveur vers l'extérieur, à part désactiver Wireguard quand on en a besoin et le réactiver ensuite.