Wireguard - impossible de se connecter à Internet

Il est possible que j’ai installé une version de test de l’interface aussi. Je suis en Version v0.3.2. Mais ça ne devrait pas influencer ton problème ici.

Tente donc d’ajouter ::/0 dans les AllowedIPs, re-télécharge le wg0.conf ou modifie-le à la main sur ton client (séparation par des virgules), et relance le VPN. :crossed_fingers:

J’ai essayé… et en fait non lol. Du coup, je réinstalle tout Wireguard en espérant que ça écrase une mauvaise ancienne conf… je stresse !

Tu avais bien cliqué sur “Apply config” ensuite? :innocent:

Merci pour ton aide ! Alors voici ce que j’ai fait :

  • réinstallation complète de Wireguard
  • ajout de ::/0 dans Allowed IPs
  • Dans Post up script : ajout de iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlp1s0 -j MASQUERADE; ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -A FORWARD -o %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o wlp1s0 -j MASQUERADE
  • Dans Post down script : ajout de iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t n
  • bien sûr un Save, puis Apply config

Et ça ne fonctionne pas. A remarquer que :

  • l’interface connectée à internet est un module wifi wlp1s0
  • et que l’ Endpoint Address est l’adresse IPV4 publique du serveur
    mais je ne pense pas que cela pose problème.
  • enfin pourquoi dans les logs du serveur, j’ai ip -4 address add 10.10.10.0/24 dev wg0 alors que sur Wireguard UI, l’IP Allocation du client est 10.10.10.1/32 (c’est fait automatiquement) ?

Il manque la fin de la commande. Vérifie qu’il y a bien les IPv6. :wink:

Post up:
iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o wlp1s0 -j MASQUERADE; ip6tables -A FORWARD -i %i -j ACCEPT; ip6tables -A FORWARD -o %i -j ACCEPT; ip6tables -t nat -A POSTROUTING -o wlp1s0 -j MASQUERADE

Post down:
iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o wlp1s0 -j MASQUERADE; ip6tables -D FORWARD -i %i -j ACCEPT; ip6tables -D FORWARD -o %i -j ACCEPT; ip6tables -t nat -D POSTROUTING -o wlp1s0 -j MASQUERADE

Ce n’est pas la même chose. Dans les logs du serveur tu vois 10.10.10.0 car c’est l’adresse qui lui est assignée (voir la page “WireGuard Server” et non pas “WireGuard clients”)

image


En prenant les choses dans l’ordre, tentons déjà d’établir le VPN. On cherchera ensuite à établir le tunnel Internet. Quand tu lances le VPN sur le client, peux-tu ping 10.10.10.0 ensuite ? Ou voir ouvrir une page http://10.10.10.0 qui devrait te rediriger vers ton interface d’admin YunoHost.


Edit: il y avait une coquille dans les adresses IPv6 allouées au serveur dans la capture d’écran ci-dessus (/128 au lieu de /64)

1 Like

On y est ! Merci énormément pour ton aide !!!
Je ne sais pas exactement ce qui a résolu le problème, mais je suspecte de mal avoir écrit le Post down (j’ai le souvenir qu’il était effectivement trop court), l’essentiel est que ça fonctionne maintenant.

Fait intéressant : si je fais un curl ifconfig.me ou bien si je vais sur un site type What’s my ip mon adresse IP est reconnue comme celle du serveur IPv4 Wireguard (l’IPv6 est “non reconnue”, mais je suppose que jusqu’ici tout va bien),. En revanche, lorsque je vais dans (je suis sur Debian) l’explorateur de Fichiers Nautilus > Réseau, je ne vois pas le réseau Samba du serveur Wireguard mais plutôt mon serveur local côté client.

Simple curiosité (puisqu’on a résolu mon souci) : est-ce normal ? Merci !!!

Vérifie que Samba autorise les connexions depuis ton VPN. Chez moi j’ai ça dans /etc/samba/smb.conf:

...
#### Networking ####

# The specific set of interfaces / networks to bind to
# This can be either the interface name or an IP address/netmask;
# interface names are normally preferred
   interfaces = 127.0.0.0/8 10.10.10.0/24

Comme je (re)découvre qu’ils préfèrent les noms d’interface, tu peux mettre wg0 à la place de 10.10.10.0/24 je pense.

Redémarre ensuite Samba avec systemctl restart smbd

Petite modif à ce sujet, il est préférable de créer un fichier dédier à cette conf.

Laisse listen-address=127.0.0.1 dans /etc/dnsmasq.conf et ajoute listen-address=10.10.10.0 dans un nouveau fichier /etc/dnsmasq.d/vpn (par exemple).

Cela évitera que le système qui régénère la conf grogne à chaque mise à jour.

Hello et merci ! Voici un petit retour sur ton aide, et aussi une anecdote sur Wireguard lors de mon voyage à l’étranger.

Je suis sur Debian Bookworm, et de manière surprenante, ce fichier n’existe pas.

Merci beaucoup ! Faudrait que je réinstalle pi-Hole pour tester tout ça. Ce qui m’énervait était qu’apparemment, pi-Hole modifiait dnsmasq, du coup je recevais un mail du diagnostic tout le temps. J’aurrais préféré que pi-Hole utilise un sorte de hook comme tu viens de me le montrer précédemment.

Enfin, lors de mon voyage à l’étranger, j’ai tenté de passer par Wireguard : sans succès ! Fait intéressant, j’ai 2 wireguards :

  • celui dont on parle sur ce sujet
  • et un autre sur un serveur où il est installé “clé en main”
    Et bien je ne pouvais passer par aucun des 2 serveurs (preuve que ce n’est probablement pas lié à une erreur de config) !

As-tu déjà entendu parlé de fournisseurs d’accès à internet étrangers qui bloquent les demandes de connexions VPN ? merci

EDIT : il est apparemment possible pour les FAI de détecter les connexions VPN et les bloquer (c.f. lien d’une source à confirmer vu que je ne suis pas un spécialiste en la matière).

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.