La Fibre
Télécom => Réseau => 
Attaques informatiques => Discussion démarrée par: Darkjeje le 11 septembre 2019 à 22:44:57
-
Bonsoir tous le monde,
Souhaitant sécuriser mes connexions sur nos smartphones Android et IOS lors de nos déplacements familiaux avec probable connexion à des réseaux WIFI, je voulais savoir si vous sauriez me conseiller un protocole VPN (OpenVPN, Wireguard, IPSEC/ikev2) à installer sur mon Raspberry Pie 3 qui tourne sous Raspbian Buster.
Je cherche un protocole sécurisé, qui ne mette pas à mal les ressources de mon Rasp et qui fonctionne facilement avec Android et IOS.
Merci pour votre aide !
-
Bonjour,
Pour répondre à ta question initiale, je pense que OpenVPN est ta cible car il est open source.
Cela lui permet d'être mis à jour en permanence ce qui est le mieux pour un logiciel orienté sur la sécurité.
Pour la même raison, il est disponible sur n'importe quelle plate-forme (ton Raspberry pie 3 en fait parti)
Maintenant, parlons du sujet un peu coton :
- Seras-tu configurer ton serveur OpenVPN de manière suffisante ?
- Sais-tu et/ou peux-tu configurer ton routeur pour diriger les demandes entrantes vers ton Raspberry ?
- Possède-tu une adresse IP fixe et/ou un service dynDns qui te permettrait de te connecter chez toi depuis l'extérieur ?
SI tu peux répondre OUI à ces 3 questions alors tu peux te lancer dans cette aventure :D
SINON tu peux toujours prendre un abonnement à un fournisseur VPN (ce sera plus simple pour toi)
Bonne chance.
-
Merci Milouse.
Je pense pouvoir répondre oui à la première.
Et clairement oui au deux autres ;)
-
Wireguard: plus simple, plus performant, plus moderne. OpenVPN est une usine a gaz.
-
Mais est il assez simple pour être installer,...
Sinon en effet, je suis assez pour celui-là !!!
-
Mais est il assez simple pour être installer,...
Ce guide est suffisant en principe: https://github.com/adrianmihalko/raspberrypiwireguard
D'autres points :
- avec des clients mobiles, Wireguard tire moins sur les batteries qu'OpenVPN.
- serveur OpenVPN IPv6 + Android = soucis.
-
Je m'était fait une documentation perso pour un éventuel remplacement d'openVPN sur un rapspberry pi derrière une connexion 3g/4g sans ouverture de port possible (sous CGNAT)
Il n'y a pas de routage, j'utilise pour avoir un accès SSH sur un rapsberry pi derrière une connexion 3g/4g
Génération des clés publiques/privé pour les machines à connecter (serveur ou client):
wg genkey | tee privatekey | wg pubkey > publickey
Créer un fichier wg0.conf dans le repertoire crée par wireguard /etc/wireguard
Configuration Serveur (Ip Publique avec port ouvert)
Partie Serveur
Adress = adresse assigné à l'interface wg
ListenPort = port d'écoute du serveur wireguard j'ai mit le port par défaut d'OpenVPN pour tester
Partie Client
AllowedIPs= les ips assigné du client autorisé à se connecter au serveur
Fichier /etc/wireguard/wg0.conf
-----------
[Interface]
PrivateKey = cle privé généré du poste serveur fichier privatekey
Address = 10.0.42.1/24
ListenPort = 1190
[Peer]
PublicKey = cle publique généré du client fichier pubkey
AllowedIPs = 10.0.42.2/32
Configuration Client (Ip privé CGNAT ou port fermé)
Partie Client
Address = adresse assigné à l'interface wg
Partie Serveur
AllowedIPs= les ips assigné du serveur autorisé à se connecter au client
Endpoint = IP ou DNS du serveur a connecter
PersistentKeepAlive = envoie periodique ( en seconde) de paquet pour maintenir une connexion derrière un NAT ou pare-feu filtrant
Fichier /etc/wireguard/wg0.conf
-----------
[Interface]
PrivateKey = cle privé du client fichier privatekey
Address = 10.0.42.2/24
[Peer]
PublicKey = cle publique du serveur fichier pubkey
AllowedIPs = 10.0.42.0/24
Endpoint = DNS/IP du serveur
PersistentKeepalive = 25
Activer l'interface sur les deux postes pour test :
Note: wg-quick va lire le nom du fichier de config spécifié dans /etc/wireguard exemple wg-quick up wg1 va lire le fichier /etc/wireguard/wg1.conf
wg-quick up wg0
Vérifier la connexion via la commande wg
interface: wg0
public key: dF/vyfo8/ZNwkPQW9RXX0ks+Efw/0hUQ7wyvQkomYRg=
private key: (hidden)
listening port: 1190
peer: bPZZgGg3lqGTrDGZoKbuCheRkMiU4ygVrea+uuW/RWk=
endpoint: IP du client découverte automatiquement
allowed ips: 10.0.42.0/24
latest handshake: 26 seconds ago
transfer: 53.39 KiB received, 1.30 KiB sent
La mention "latest handshake" doit apparaitre !
Ne pas hésiter à faire des pings
Activer l'interface wg0 au démarrage de la machine:
systemctl enable wg-quick@wg0.service
-
Wireguard est cool.
Il faut cependant garder à l'esprit les choses suivantes :
- Pas d'audit de sécurité réalisé
- module wg pas encore intégré nativement au noyau Linux
- Pas de version "stable" du client officiel pour Windows
- TunSafe est un client Windows réalisé par un développeur tiers, et l'auteur de Wireguard déconseille son utilisation
-
il y'a bien un client officiel sur le site de wireguard non ?
https://www.wireguard.com/install/
sinon oui la seule chose qui me rebute un peu c'est que c'est tout neuf et en chantier (Work In Progress) mais c'est prometteur pour une utilisation perso/ de test
-
Franchement pour un usage 'grand public' ou PME ca va largement.
L'histoire du manque d'audit de sécurité c'est plus pour les grosses boites ou le DSI/RSSI veut couvrir ses arrieres avec des certifications ISO 9000 machin, ANSSI trucmuch, Bullshit 3.0, etc
-
Pour l'utiliser sur mon smartphone pour mon accès SIP, je confirme que WG marche bien.
Bien que j'ai galéré un sacré moment à régler les petits pépins de routage, mais c'était entre 2 LANs. Avec un smartphone qui est directement client la config est beaucoup plus facile et se résume au guide github.
Petite précaution aussi : éviter de se servir de wg-quick, et plutôt tout configurer à la main. Chez moi j'avais un bug qui fait que le ping ne passait pas (j'ai cherché un sacré moment avant de trouver la source).
-
Merci à tous pour votre aide et le lien du tuto.
J'ai pu créer la partie serveur sur mon Rasp, j'ai téléchargé l'appli android et configurer le tunnel.
Le tunnel est fonctionnel, mais comment savoir si cela fonctionne, car j'ai un doute ?
Peut-on voir les clients connectés ?
-
Le tunnel est fonctionnel, mais comment savoir si cela fonctionne, car j'ai un doute ?
Tu peux essayer d'accéder à un serveur ou un service accessible uniquement sur ton réseau local (par exemple, un partage de fichiers via SMB). Ou bien encore, tu regarde le résultat d'un site comme ip.lafibre.info (http://ip.lafibre.info), si tu as seulement les IP de ton Raspi c'est bon.
-
Sinon, j'arrive un peu après la bataille, mais j'aime bien les scripts d'Angristan qui sont sécurisés, rapides et pratique :
- OpenVPN-install (https://github.com/angristan/openvpn-install), le plus complet et le plus mature des deux
- Wireguard-install (https://github.com/angristan/wireguard-install)
Fonctionnent en x86 ou ARM, sur Ubuntu, Debian, Fedora, Arch (Raspbian aussi pour le 1er, pas encore (https://github.com/angristan/wireguard-install/issues/17) pour wireguard)
-
Tu peux essayer d'accéder à un serveur ou un service accessible uniquement sur ton réseau local (par exemple, un partage de fichiers via SMB). Ou bien encore, tu regarde le résultat d'un site comme ip.lafibre.info (http://ip.lafibre.info), si tu as seulement les IP de ton Raspi c'est bon.
Malheureusement cela ne fonctionne pas. L'adresse IP reste la même et je n'accède pas à mon NAS. Je vais essayer de voir ce que j'ai raté.
-
Malgré mes efforts, je n'y parviens pas. Sauriez-vous m'aider ?
Sur mon Rasp j'ai ceci :
[Interface]
Address = 192.168.2.1/24
PrivateKey = 2P4Mk/UgCGTSJxRavbPuhbqZBip7dJWtcOkdGwr6Lkk=
ListenPort = 51820
#replace eth0 with the interface open to the internet (e.g might be wlan0 if wi$
#PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACC$
#PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j A$
[Peer]
#Client1
PublicKey = Br08O0KDCPqpU0PXMaRcs+trWOWNvJ37+7pkCUF4CkQ=
AllowedIPs = 192.168.2.2/32
Quand j'active wg0 j'obtiens :
- ip link add wg0 type wireguard
- wg setconf wg0 /dev/fd/63
- ip -4 address add 192.168.2.1/24 dev wg0
- ip link set mtu 1420 up dev wg0
Et sur mon windows figurant sur le même réseau j'ai :
-
Pour que tout le trafic passe par le tunnel, il faut mettre 0.0.0.0/0 dans allowed ips sur le client windows (ou android).
Si tu mets uniquement le rasp tu ne pourras joindre que celui-ci.
Après tu peux adapter et ne mettre que ton LAN par exemple, tout est possible.
-
si je mets allowed 0.0.0.0/0, je n'arrive plus à joindre le net. Les pages ne chargent pas :(
-
Le routage/NAT côté rasp ne doit pas être bon alors.
Essaies d'ajouter la règle :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
eth0 étant la carte réseau du rasp (sur le 2 c'est eth0, sur les suivantes je sais pas si c'est pareil) un ip a te donnera l'info.
Et vérifier que le routage est activé :
cat /proc/sys/net/ipv4/ip_forward
Si 1 c'est ok, si 0 :
echo 1 > /proc/sys/net/ipv4/ip_forward
-
je te conseille de ne pas poster tes clés privés/publics dans un forum ;)
-
je te conseille de ne pas poster tes clés privés/publics dans un forum ;)
T'inquiète ce ne sont pas mes vrais clés, mais merci kgersen ;)
Par contre je n'ai pas installé iptables ni de serveur dns sur mon rasp.
Mon réseau privé est sur 192.168.1.x, et si je comprends bien je ne peux pas mettre ce même réseau donc j'ai mis 192.168.2.x.
Est-ce bon ?
-
Le routage/NAT côté rasp ne doit pas être bon alors.
Essaies d'ajouter la règle :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
eth0 étant la carte réseau du rasp (sur le 2 c'est eth0, sur les suivantes je sais pas si c'est pareil) un ip a te donnera l'info.
Et vérifier que le routage est activé :
cat /proc/sys/net/ipv4/ip_forward
Si 1 c'est ok, si 0 :
echo 1 > /proc/sys/net/ipv4/ip_forward
Je n'ai pas iptable d'installé.
Par contre j'ai bien 1 en retour de la commande cat /proc/sys/net/ipv4/ip_forward
-
c'est quoi la finalité ?
Si les appareils distants n'ont besoin d’accéder qu'au réseau local du Pi et que tu peux mettre sur la passerelle par défaut du réseau local une route vers les IPs du wg alors tu n'as pas besoin d'iptables (pas besoin de NAT/masquerad).
Sinon cas il te faut NATer les IPs wg. Tu peux aussi tout contrôler sur le routeur du réseau ou y'a le Pi ca évite du double NAT.
comme toujours en réseau le mieux est de faire un plan d'adressage.
-
Par contre je n'ai pas installé iptables ni de serveur dns sur mon rasp.
iptables est normalement installé de base dans toutes les distributions linux ou presque.
root@raspberrypi:~# dpkg -l | grep iptables
ii iptables 1.8.2-4 armhf administration tools for packet filtering and NAT
Tu as le même retour ? Sinon un apt install iptables devrait résoudre le soucis, mais c'est curieux. Ou alors y'a un problème de PATH$ avec bash : https://unix.stackexchange.com/questions/150523/bash-iptables-command-not-found
Mon réseau privé est sur 192.168.1.x, et si je comprends bien je ne peux pas mettre ce même réseau donc j'ai mis 192.168.2.x.
Est-ce bon ?
Oui.
-
c'est quoi la finalité ?
Si les appareils distants n'ont besoin d’accéder qu'au réseau local du Pi et que tu peux mettre sur la passerelle par défaut du réseau local une route vers les IPs du wg alors tu n'as pas besoin d'iptables (pas besoin de NAT/masquerad).
Sinon cas il te faut NATer les IPs wg. Tu peux aussi tout contrôler sur le routeur du réseau ou y'a le Pi ca évite du double NAT.
comme toujours en réseau le mieux est de faire un plan d'adressage.
Mon but est d'avoir accès à mon réseau local, mais aussi au net lorsque je suis sur des hotspot wifi public dont je doute de la sécurité,...
-
Mon but est d'avoir accès à mon réseau local, mais aussi au net lorsque je suis sur des hotspot wifi public dont je doute de la sécurité,...
donc il faut faire du NAT quelque part.
1. as-tu le contrôle du routeur/box sur le réseau local du Pi ? Si oui tu peux installer une route dessus qui va pointer 192.168.2.0/24 vers le Pi. ("ip route 192.168.2.0/24 192.168.1.x").Dans ce cas le Pi n'a pas besoin d'iptables et doit juste router par défaut (/proc/sys/net/ipv4/ip_forward a 1). il faut aussi ajouter 192.168.2.0/24 en sortie du NAT dans le routeur.
2. sinon c'est au Pi de faire du NAT donc de partager son IP local (192.168.1.x) avec les clients wireguard qui eux sont en 192.168.2.y. C'est les commandes indiqués par renaud07.
donc à mettre dans le PostUp
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
et les inverses en PostDown.
Apres si tu ne veux pas trop apprendre les détails, utilise le script proposer par alegui: https://lafibre.info/attaques/quel-type-de-vpn-installer-sur-un-raspberry-pie-3/msg687366/#msg687366
-
Merci kgersen je vais regarder cela dès que possible.
Mon routeur la Freebox mini 4k donc je doute de pouvoir faire la 1ère solution, je vais tâcher de comprendre la 2 et au pire faire le script.
Merci encore pour votre aide, je vous dirai si cela a fonctionné
-
donc il faut faire du NAT quelque part.
1. as-tu le contrôle du routeur/box sur le réseau local du Pi ? Si oui tu peux installer une route dessus qui va pointer 192.168.2.0/24 vers le Pi. ("ip route 192.168.2.0/24 192.168.1.x").Dans ce cas le Pi n'a pas besoin d'iptables et doit juste router par défaut (/proc/sys/net/ipv4/ip_forward a 1). il faut aussi ajouter 192.168.2.0/24 en sortie du NAT dans le routeur.
2. sinon c'est au Pi de faire du NAT donc de partager son IP local (192.168.1.x) avec les clients wireguard qui eux sont en 192.168.2.y. C'est les commandes indiqués par renaud07.
donc à mettre dans le PostUp
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
et les inverses en PostDown.
Apres si tu ne veux pas trop apprendre les détails, utilise le script proposer par alegui: https://lafibre.info/attaques/quel-type-de-vpn-installer-sur-un-raspberry-pie-3/msg687366/#msg687366
Salut kgersen et renaud07 et encore merci pour votre aide.
J'ai donc créé un fichier firewall avec ceci dedans :
#!/bin/sh
### BEGIN INIT INFO
# Provides: firewall rules
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO
#Suppression des règles précédentes
iptables -F
iptables -X
########
# DROP #
########
# Définition du blocage général
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Drop des scans XMAS et NULL
iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
##########
# ACCEPT #
##########
# Conservations des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Autorisation du loopback (127.0.0.1)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# WIREGUARD (51820)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -p udp --dport 51820 -j ACCEPT
# ICMP (Ping)
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT
# Parer les attaques de type Déni de Service
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT
# Parer les scans de ports
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Et au niveau du fichier wireguard j'ai :
Pour le client windows :
AllowedIPs = 0.0.0.0/0
Endpoint = xxx.xxx.xxx.xxx:51820
Pour le serveur :
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
J'avais une erreur de clé qui expliquait pourquoi je n'arrivais pas à faire de ping sur l'adresse du serveur en 192.168.2.x, c'est maintenant réglé.
J'ai accès à facebook et lafibre lorsque j'active le vpn, mais pratiquement aucun autre site. Est-ce une différence ipv4 / ipv6 ? Ou plutôt de DNS facebook et lafibre ne fonctionne plus si je les lance depuis un onglet de navigation privé de chrome,...
Je n'arrive par contre pas à faire de ping sur 192.168.1.254 (freebox) ou 192.168.1.6 (le rasp), j'ai le message défaillance générale en retour, seul 192.168.1.1 (mon pc) fonctionne.
En ping -6 j'ai le retour que l'hôte n'a pu être trouvé.
Il y a donc encore quelque chose qui ne va pas.
-
tu te complique à faire un conf firewall complete: le Pi n'est pas un routeur en direct sur Internet, ce n'est pas necessaire.
Il faut juste partir de rien (pas de regles;conf par défaut d'iptables) et juste ajouter les 2 regles indiquées.
-
Il faut juste partir de rien (pas de regles;conf par défaut d'iptables) et juste ajouter les 2 regles indiquées.
J'ai vidé le fichier firewall, mais je ne vois pas où je dois mettre les lignes suivantes, si ce sont bien celle-ci à indiquer :
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
-
Il faut les mettre dans /etc/network/interfaces mais sous cette forme :
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -A FORWARD -i wg0 -j ACCEPT
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -D FORWARD -i wg0 -j ACCEPT
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
Dans /etc/wireguard/wg0.conf il faut commenter la ligne Address= (puisque désormais indiqué dans /etc/network/interfaces) :
On doit avoir ça au final :
[Interface]
PrivateKey = la-clé-privée
ListenPort = 51820
#Address = 192.168.2.1/24
# Client windows
[Peer]
PublicKey = la-clé-publique
AllowedIPs = 192.168.2.2/32
# Client android
[Peer]
PublicKey = la-clé-publique
AllowedIPs = 192.168.2.3/32
Et théoriquement ça devrait marcher ;)
-
Il faut les mettre dans /etc/network/interfaces mais sous cette forme :
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -A FORWARD -i wg0 -j ACCEPT
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -D FORWARD -i wg0 -j ACCEPT
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
Dans /etc/wireguard/wg0.conf il faut commenter la ligne Address= (puisque désormais indiqué dans /etc/network/interfaces) :
On doit avoir ça au final :
[Interface]
PrivateKey = la-clé-privée
ListenPort = 51820
#Address = 192.168.2.1/24
# Client windows
[Peer]
PublicKey = la-clé-publique
AllowedIPs = 192.168.2.2/32
# Client android
[Peer]
PublicKey = la-clé-publique
AllowedIPs = 192.168.2.3/32
Et théoriquement ça devrait marcher ;)
J'ai fait ce que tu m'as indiqué renaud07, malheureusement mon rasp ne redémarrait pas, où du moins ne me donnait plus accès en ssh.
J'ai donc effacer etc/network/interfaces pour avoir de nouveau la main.
-
Étrange... c'est la même config que j'utilise à quelques règles près. A noter que dans mon cas il faut que j'attende bien 1 minute avant qu'il ne me repropose le login SSH. Tu as testé voir s'il répondait au ping avec cette config ? Si c'est le cas, faut attendre un peu. Sinon, il est effectivement planté.
D’autant plus que même si l'interface wg0 n'est pas bonne, ça ne devrait pas en principe affecter l'interface principale.
EDIT : On va commencer par simplifier le fichier en activant le routage de manière permanente (ça supprime la règle de forward) :
Décommenter la ligne (faut enlever le dièse, quoi) net.ipv4.ip_forward=1 dans /etc/sysctl.conf et rebooter.
ce qui donne :
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
-
Je testerai ce soir si possible.
Mais n'ayant pas de connexion ssh, j'ai connecté mon rasp à un écran et je te confirme qu'il affichait erreur au lancement de l'interface network, puis au lancement de wg0.
-
Étrange... c'est la même config que j'utilise à quelques règles près. A noter que dans mon cas il faut que j'attende bien 1 minute avant qu'il ne me repropose le login SSH. Tu as testé voir s'il répondait au ping avec cette config ? Si c'est le cas, faut attendre un peu. Sinon, il est effectivement planté.
D’autant plus que même si l'interface wg0 n'est pas bonne, ça ne devrait pas en principe affecter l'interface principale.
EDIT : On va commencer par simplifier le fichier en activant le routage de manière permanente (ça supprime la règle de forward) :
Décommenter la ligne (faut enlever le dièse, quoi) net.ipv4.ip_forward=1 dans /etc/sysctl.conf et rebooter.
ce qui donne :
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
Dans ton fichier interfaces, tu n'as que les lignes de code que tu m'as indiqué, où tu as d'autres infos sur ta carte réseau, le dhcp,...
Car je n'ai que ça moi :
source-directory /etc/network/interfaces.d
Je garde cette ligne et je rajoute ce que tu as mis à ton post précédent ?
-
Je me doutais qu'on ne s'était pas compris.
Il faut évidemment rajouter wg0 à la suite et non effacer entièrement le fichier. Dans ton cas tu n'as plus la config de eth0, c'est donc normal que ça ne réponde pas.
Il faut remettre au moins ça :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
Et là tu devrais avoir de nouveau du réseau.
-
Je me doutais qu'on ne s'était pas compris.
Il faut évidemment rajouter wg0 à la suite et non effacer entièrement le fichier. Dans ton cas tu n'as plus la config de eth0, c'est donc normal que ça ne réponde pas.
Il faut remettre au moins ça :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
Et là tu devrais avoir de nouveau du réseau.
Merci Renaud07 je vais tâcher de tester ce soir.
En fait je n'avait rien effacé, mon fichier interfaces ne comportait qu'une ligne à la suite de laquelle j'avais copié ton script.
C'est quand ça a planté que j'ai effacé ton code de mon fichier et c'est en lisant sur ce fichier que j'ai compris que j'aurai dû avoir eth0 dedans.
Pourquoi ne l'ai je pas ? Aucune idée.
-
C'est quand ça a planté que j'ai effacé ton code de mon fichier et c'est en lisant sur ce fichier que j'ai compris que j'aurai dû avoir eth0 dedans.
Pourquoi ne l'ai je pas ? Aucune idée.
As-tu installé avec l'interface graphique ? Du coup c'est sans doute normal, puisque le réseau est pris en charge par network-manager (https://debian-facile.org/doc:reseau:network-manager)dans ce cas et /etc/network/interfaces est vide (c'est pareil sur ubuntu par exemple).
Il faut le désactiver : dans /etc/NetworkManager/NetworkManager.conf passer
[ifupdown]
managed=true
à managed=false
et le redémarrer :
service network-manager restart
Désormais toutes les interfaces sont gérés via le fichier.
-
As-tu installé avec l'interface graphique ? Du coup c'est sans doute normal, puisque le réseau est pris en charge par network-manager (https://debian-facile.org/doc:reseau:network-manager)dans ce cas et /etc/network/interfaces est vide (c'est pareil sur ubuntu par exemple).
Non j'ai installé en ligne de commande via SSH. Par contre j'utilise webmin si jamais ça a pu modifier quoi que ce soit.
Il faut le désactiver : dans /etc/NetworkManager/NetworkManager.conf passer
[ifupdown]
managed=true
à managed=false
et le redémarrer :
service network-manager restart
Désormais toutes les interfaces sont gérés via le fichier.
Je n'ai pas networkmanager dans le dossier etc,...
-
Petite précision, je suis sous raspbian Buster et avec un rasp 1 B+ et non 3 comme indiqué par erreur dans mon titre.
Je ne comprends pas où sont stockés les infos du DHCP et autre s'ils ne sont ni dans interfaces, ni dans network-manager
-
Après plus ample recherche, je viens de voir qu'en fait depuis la version 8 (jessie), le fichier /etc/dhcpcd.conf est aussi responsable du réseau, il "remplace" interfaces. Il me semble que j'avais vu passer l'info à l’époque mais j'ai visiblement oublié.
Mas ça ne gène pas, le service détecte que interfaces est utilisé à la place et il ne se lance pas, comme l'atteste le retour de cette commande : (j'ai toujours configuré le réseau à partir d'interfaces, sans me préoccuper de dhcpcd.conf)
root@raspberrypi:~# service dhcpcd status
Warning: The unit file, source configuration file or drop-ins of dhcpcd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
● dhcpcd.service - dhcpcd on all interfaces
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/dhcpcd.service.d
└─wait.conf
Active: failed (Result: exit-code) since Fri 2019-09-20 21:21:24 BST; 4 days ago
Process: 354 ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w (code=exited, status=6)
Sep 20 21:21:24 raspberrypi systemd[1]: Starting dhcpcd on all interfaces...
Sep 20 21:21:24 raspberrypi dhcpcd[354]: Not running dhcpcd because /etc/network/interfaces
Sep 20 21:21:24 raspberrypi dhcpcd[354]: defines some interfaces that will use a
Sep 20 21:21:24 raspberrypi dhcpcd[354]: DHCP client or static address
Sep 20 21:21:24 raspberrypi systemd[1]: dhcpcd.service: Control process exited, code=exited, status=6/NOTCONFIGURED
Sep 20 21:21:24 raspberrypi systemd[1]: dhcpcd.service: Failed with result 'exit-code'.
Sep 20 21:21:24 raspberrypi systemd[1]: Failed to start dhcpcd on all interfaces.
C'était donc normal que le fichier soit vide à la base.
Pour résumer tu dois avoir un fichier qui ressemble à ça :
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 192.168.1.254
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
À adapter selon ton plan d'adressage évidemment.
-
Pour résumer tu dois avoir un fichier qui ressemble à ça :
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 192.168.1.254
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
À adapter selon ton plan d'adressage évidemment.
Je viens de faire le test et cela bug au niveau du fichier interfaces que j'avais complété comme tu me l'as indiqué.
J'ai pris la photo suivante des 3 anomalies (interfaces, dhcpcd et wireguard).
Qu'est ce que tu en penses ?
Il ne semble pas trouvé eth0,... J'ai lu que debian avait changé sa manière de nommer les interfaces réseaux, mais pourtant c'est bien eth0 que j'ai lorsque je ne touche à rien,...
-
avec ifconfig -a :
Je n'ai pas eth0 mais enxb828eb71a4fc qui semble être la nouvelle façon de nommer eth0.
J'en conclu que si je remplace eth0 par enxb828eb71a4fc dans le fichier interfaces, cela devrait fonctionner.
-
Oui c'est ça.
Par contre il y a d'autres problèmes à régler :
-le Address=192.168.2.1 (ça c'est dans le fichier wireguard, pas dans interfaces) : la bonne syntaxe address 192.168.2.1
-il faut désactiver wg-quick aussi (car il est déjà lancé via interfaces)
-pour dhcpcd, c'est ok, il ne démarre pas comme attendu vu que la config est renseignée dans interfaces
-
Oui c'est ça.
Par contre il y a d'autres problèmes à régler :
-le Address=192.168.2.1 (ça c'est dans le fichier wireguard, pas dans interfaces) : la bonne syntaxe address 192.168.2.1
-il faut désactiver wg-quick aussi (car il est déjà lancé via interfaces)
-pour dhcpcd, c'est ok, il ne démarre pas comme attendu vu que la config est renseignée dans interfaces
J'ai testé la config suivante dans interfaces (sans toucher à rien d'autre) :
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopbac
auto enxb828eb71a4fc
allow-hotplug enxb828eb71a4fc
iface enxb828eb71a4fc inet dhcp
iface enxb828eb71a4fc inet6 dhcp
Et impossible de me connecter en ssh.
En branchant le rasp à ma TV, donc sans connexion au câble réseau, j'ai pu voir l'erreur suivante :
-
Puis j'ai testé le code suivant :
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopbac
auto enxb827eb71a4fc
iface enxb827eb71a4fc static
address 192.168.1.9
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 192.168.1.254
Et là aussi une erreur sans connexion du câble réseau :
-
Ton code n'est pas bon.
Il manque inet et le k de loopback
Ça devrait aller mieux comme ça :
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto enxb827eb71a4fc
iface enxb827eb71a4fc inet static
address 192.168.1.9
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 192.168.1.254
Les erreurs de syntaxe ne pardonnent pas. Moi aussi il arrive de me faire avoir car j'ai tapé la mauvaise lettre ou mis une majuscule là où il ne fallait pas. Des fois il faut que je relise plusieurs fois avant de trouver la bourde, et c'est encore pire avec le fichier dhcpd.conf (le seveur dhcp) ou bind (DNS) par exemple, où il y a des point virgule à chaque fin de ligne, t'en oublies un, rien ne démarre !
-
Les erreurs de syntaxe ne pardonnent pas. Moi aussi il arrive de me faire avoir car j'ai tapé la mauvaise lettre ou mis une majuscule là où il ne fallait pas. Des fois il faut que je relise plusieurs fois avant de trouver la bourde, et c'est encore pire avec le fichier dhcpd.conf (le seveur dhcp) ou bind (DNS) par exemple, où il y a des point virgule à chaque fin de ligne, t'en oublies un, rien ne démarre !
Oui je suis clairement allé trop vite.
Maintenant interfaces fonctionne mais toujours pas pour l'accès au net ou au reste du réseau en VPN activé :
ifconfig -a me retourne :
enxb827eb71a4fc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.9 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::ba27:ebff:fe71:a4fc prefixlen 64 scopeid 0x20<link>
inet6 2a01:e34:ee0f:b290:ba27:ebff:fe71:a4fc prefixlen 64 scopeid 0x0<global>
ether b8:27:eb:71:a4:fc txqueuelen 1000 (Ethernet)
RX packets 2383 bytes 290703 (283.8 KiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 1084 bytes 174830 (170.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 107 bytes 8193 (8.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 107 bytes 8193 (8.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 192.168.2.1 netmask 255.255.255.0 destination 192.168.2.1
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC)
RX packets 293 bytes 41628 (40.6 KiB)
RX errors 0 dropped 473 overruns 0 frame 0
TX packets 50 bytes 5300 (5.1 KiB)
TX errors 46 dropped 0 overruns 0 carrier 0 collisions 0
Dans interfaces j'ai ceci :
source-directory /etc/network/interfaces.d
auto lo
iface lo inet loopback
auto enxb827eb71a4fc
allow-hotplug enxb827eb71a4fc
iface enxb827eb71a4fc inet dhcp
iface enxb827eb71a4fc inet6 auto
auto wg0
iface wg0 inet static
pre-up ip link add dev wg0 type wireguard
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -A FORWARD -i wg0 -j ACCEPT
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -D FORWARD -i wg0 -j ACCEPT
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
address 192.168.2.1
netmask 255.255.255.0
J'ai aussi testé avec ceci :
#post-up wg setconf wg0 /etc/wireguard/wg0.conf
#post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
#post-down ip link del wg0
à la place de :
post-up wg setconf wg0 /etc/wireguard/wg0.conf
post-up iptables -A FORWARD -i wg0 -j ACCEPT
post-up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
post-down iptables -D FORWARD -i wg0 -j ACCEPT
post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
post-down ip link del wg0
Et lorsque je relance l'interface network j'ai ceci :
pi@raspberrypi:~ $ sudo ifdown enxb827eb71a4fc && sudo ifup enxb827eb71a4fc
Too few arguments.
Too few arguments.
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/enxb827eb71a4fc/b8:27:eb:71:a4:fc
Sending on LPF/enxb827eb71a4fc/b8:27:eb:71:a4:fc
Sending on Socket/fallback
DHCPRELEASE of 192.168.1.9 on enxb827eb71a4fc to 192.168.1.254 port 67
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/enxb827eb71a4fc/b8:27:eb:71:a4:fc
Sending on LPF/enxb827eb71a4fc/b8:27:eb:71:a4:fc
Sending on Socket/fallback
DHCPDISCOVER on enxb827eb71a4fc to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on enxb827eb71a4fc to 255.255.255.255 port 67 interval 6
DHCPOFFER of 192.168.1.9 from 192.168.1.254
DHCPREQUEST for 192.168.1.9 on enxb827eb71a4fc to 255.255.255.255 port 67
DHCPACK of 192.168.1.9 from 192.168.1.254
Too few arguments.
Too few arguments.
bound to 192.168.1.9 -- renewal in 20893 seconds.
pi@raspberrypi:~ $
Je n'ai pas touché à dhcpv ni désactivé wg-quick.
Je me retrouve donc avec mon réseau paramétré par le fichier interfaces mais toujours pas d'accès à mon réseau en 192.168.1.x ni au net,... :(
-
Il y a encore une bourde (mais c'est bizarre qu'il reçoive quand même une ip dans ce cas...)
Tu as mis auto à la place de dhcp pour la ligne iface enxb827eb71a4fc inet6 (à moins que tu l'aies corrigé après ?)
Est-ce que tu arrives à ping ta freebox ou autre équipement via leur ip ? C'est peut-être un problème de DNS simplement. Que contient /etc/resolv.conf ? Normalement il doit y avoir l'ip de la freebox soit :
nameserver 192.168.1.254
-
Il y a encore une bourde (mais c'est bizarre qu'il reçoive quand même une ip dans ce cas...)
Tu as mis auto à la place de dhcp pour la ligne iface enxb827eb71a4fc inet6 (à moins que tu l'aies corrigé après ?)
Ce n'est pas un oubli, en mettant dhcp, ça tourne sans fin, sans obtenir de réponse de ma freebox.
Donc j'ai mis auto à la place ayant lu ceci : "Autrement, IPv6 peut être configuré automatiquement en utilisant l'autoconfiguration sans état (stateless address autoconfiguration ou SLAAC) qui est spécifiée en utilisant auto à la place de dhcp dans la section inet6 :"
Est-ce que tu arrives à ping ta freebox ou autre équipement via leur ip ? C'est peut-être un problème de DNS simplement. Que contient /etc/resolv.conf ? Normalement il doit y avoir l'ip de la freebox soit :
nameserver 192.168.1.254
Tous les équipements en 192.168.1.x ne répondent pas, j'obtiens défaillance générale. Ce qui est étonnant car je m'attendrai à avoir hôte inexistant ou délais dépassé.
-
Ce n'est pas un oubli, en mettant dhcp, ça tourne sans fin, sans obtenir de réponse de ma freebox.
Donc j'ai mis auto à la place ayant lu ceci : "Autrement, IPv6 peut être configuré automatiquement en utilisant l'autoconfiguration sans état (stateless address autoconfiguration ou SLAAC) qui est spécifiée en utilisant auto à la place de dhcp dans la section inet6 :"
Ah oui c'est vrai, vu que je n'utilise que très rarement la config auto/dhcp sur serveur, je m'en rappelais plus. auto est pour le SLAAC et dhcp pour dhcpv6.
Tous les équipements en 192.168.1.x ne répondent pas, j'obtiens défaillance générale. Ce qui est étonnant car je m'attendrai à avoir hôte inexistant ou délais dépassé.
Essaies dans un premier temps de virer tout ce qui concerne wireguard (en commentant, pas besoin de l'effacer), car il se peut que les règles interfèrent. Tu as aussi viré ton script de pare-feu ? Car c'est un coup à tout bloquer si les règles ne sont pas bonnes.
EDIT : défaillance générale, c'est sur windows ça. Que donne un ping à partir du rasp ? C'est surtout ça qui m'intéresse.
Exemples à tester :
ping 192.168.1.254
ping 2a01:6e00:10:410::2
ping4 lafibre.info
ping6 lafibre.info
-
EDIT : défaillance générale, c'est sur windows ça. Que donne un ping à partir du rasp ? C'est surtout ça qui m'intéresse.
Exemples à tester :
ping 192.168.1.254
ping 2a01:6e00:10:410::2
ping4 lafibre.info
ping6 lafibre.info
Merci pour to aide renaud07, j'ai fini par faire fonctionner le VPN.
J'ai mis les deux lignes suivantes dans wg0.conf :
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -$
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING$
J'accède maintenant à Internet depuis Windows via le VPN, mais pendant ce temps là je n'ai plus accès au réseau local en 192.168.1.x
Il doit donc manquer quelque chose.
Sur mon Android, j'arrive à avoir accès à Internet et au réseau local en 192.168.1.x ce qui est le plus important pour moi.
Merci encore pour toute ton aide !!!
-
Content de voir que ça fonctionne :)
Pour windows qui n'accède pas au réseau local, si les paramètres sont identiques au client andoid c'est assez étonnant... Faudrait que je fasse le test de mon côté.
-
Test effectué : La navigation sur un partage SMB ainsi que le net fonctionne en même temps. Et je n'ai rien d'autre que la règle de NAT, comme toi. C'est peut-être comme je l'avais mentionné avant, wg-quick qui merde. Chez moi je suis en configuration tout manuel :
auto wg0
iface wg0 inet static
pre-up /sbin/ip link add dev wg0 type wireguard
post-up /usr/bin/wg setconf wg0 /etc/wireguard/wg0.conf
post-up /sbin/ip route add 192.168.1.0/24 dev wg0
post-up iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
post-down /sbin/ip link del wg0
address 172.16.2.1
netmask 255.255.255.0
-
Test effectué : La navigation sur un partage SMB ainsi que le net fonctionne en même temps. Et je n'ai rien d'autre que la règle de NAT, comme toi. C'est peut-être comme je l'avais mentionné avant, wg-quick qui merde. Chez moi je suis en configuration tout manuel :
Merci renaud07 pour ton retour.
La solution était pourtant évidente, mais je ne l'ai vue que ce soir,... j'ai changé l'adresse DNS de Free en 212.xxx.xxx.xxx par celle de la freebox 192.168.1.254 et tout fonctionne aussi en local ;)
Merci beaucoup pour tout le temps que tu m'as consacré !!!
En fait non, j'ai confondu mon problème d'accès au net qui fonctionne depuis un moment, avec mon problème d'accès à mon réseau classique en 192.168.1.x qui ne fonctionne pas.
J'essaye aussi de paramétrer ipv6 dans wireguard mais sans grand résultat pour le moment.
ip.lafibre.info me ressort :
Connectivité IP : Attention : Vous n’avez pas de connectivité IPv6 native.
Connectivité IPv4 (via requête DNS) OK : IPv4 publique = www.xxx.yyy.zzz
Connectivité IPv4 (via IPv4 littérale) OK : IPv4 publique = www.xxx.yyy.zzz
Connectivité IPv6 (via requête DNS) hors-service
La version du protocole IP utilisée par défaut est IPv4
Informations IP :
Reverse DNS IPv4 est fmx92-1-www-xxx-yyy-zzz.fbx.proxad.net
Reverse DNS IPv6 est (Vous n'avez pas de connectivité IPv6)
IP locales : 192.168.2.1, 2a01:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
Informations TCP :
Port TCP source utilisé par votre connexion IPv4 : TCP 56748 et TCP 56749 (via IPv4 littérale) (Plus d'informations)
Port TCP source utilisé par votre connexion IPv6 : (Vous n'avez pas de connectivité IPv6)
Port TCP destination utilisé : TCP 80
-
Lorsque je remplace l'adresse ip de la ligne AllowedIPs = 0.0.0.0/0 chez le client par celle de wg0 du serveur : 192.168.2.254/32, j'arrive à accéder au réseau 192.168.1.x, à aller sur le web et avoir une connectivité ipv6 sur mon client PC.
Par contre sur Android, le VPN ne fonctionne pas avec cette config et ne refonctionne qu'avec AllowedIPs = 0.0.0.0/0
En fonction des sites webs lu, il est indiqué qu'AllowedIPs doit avoir 0.0.0.0/0 pour que tous le traffic du terminal passe par le VPN, mais sur d'autre site il est indiqué de renseigner l'adresse ip du peer serveur.
-
sur une interface wireguard, AllowedIPs fonctionne :
- en sortie de l'interface: comme un routage (routage local a l'interface wg, il faut aussi qu'une route correspondante soit installée dans l'OS).
- en entrée de l'interface: comme un filtre sur adresse source (ACL)
donc en général:
- coté serveur il ne faut mettre qu'une IP (ou range éventuellement) , celle du client.
- coté client il faut mettre 0.0.0.0/0 si on veut que tout son traffic passe par le vpn de façon a ce qu'il laisse entrée n'importe quelle IP source (ie les retour).
Ce qui peut se passer c'est que certaines surcouches (comme wg-quick) établissent en plus les routes dans l'OS en fonction de la valeur de AllowedIPs. Si ce n'est pas fait, par exemple, indiqué sur le client, que 0.0.0.0/0 doit sortir par wg0 alors meme si il y a 0.0.0.0/0 en AllowedIPs ca ne sortira pas par la bien qu'autorisé a entrer par la.
extrait de la doc de wg-quick (https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8) :
It infers all routes from the list of peers’ allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway.
Pas mal de gens ne réalisent pas ceci quand il utilise la commande 'wg' directement: ca ne change pas les routes dans l'OS. Alors que wg-quick change les routes dans l'OS. donc bien faire attention quand on utilise les 2 commandes directement (je recommande de n'utiliser que wg-quick).
-
Merci kgersen pour toutes ces précisions.
Je vais regarder ça en détail et reviendrai dire si j'ai pu avancer ou non ;)
-
Ce qui peut se passer c'est que certaines surcouches (comme wg-quick) établissent en plus les routes dans l'OS en fonction de la valeur de AllowedIPs. Si ce n'est pas fait, par exemple, indiqué sur le client, que 0.0.0.0/0 doit sortir par wg0 alors meme si il y a 0.0.0.0/0 en AllowedIPs ca ne sortira pas par la bien qu'autorisé a entrer par la.
extrait de la doc de wg-quick (https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8) :
Pas mal de gens ne réalisent pas ceci quand il utilise la commande 'wg' directement: ca ne change pas les routes dans l'OS. Alors que wg-quick change les routes dans l'OS. donc bien faire attention quand on utilise les 2 commandes directement (je recommande de n'utiliser que wg-quick).
Salut kgersen,
Je viens de vérifier et sauf erreur de ma part, j'utilise la commande wg-quick car j'ai suivi la procédure suivante :
pi @ raspberrypi: ~ $ mkdir wgkeys
pi @ raspberrypi: ~ $ cd wgkeys
pi @ raspberrypi: ~ / wgkeys $ wg genkey > server_private.key
Attention: écriture dans le fichier accessible au monde entier.
Envisagez de définir l'umask sur 077 et réessayez.
pi @ raspberrypi: ~ / wgkeys $ wg pubkey > server_public.key < serveur_private.key
pi @ raspberrypi: ~ / wgkeys $ wg genkey > client1_private.key
Attention: écriture dans le fichier accessible au monde entier.
Envisagez de définir l'umask sur 077 et réessayez.
pi @ raspberrypi: ~ / wgkeys $ wg pubkey > client1_public.key < client1_private.key
pi @ raspberrypi: ~ / wgkeys $ ls
client1_private.key client1_public.key serveur_private.key serveur_public.key
pi @ raspberrypi: ~ / wgkeys $ sudo nano /etc/wireguard/wg0.conf
[Interface]
Adresse = 192.168.2.254/24
PrivateKey = <server_private.key>
ListenPort = 51820
# remplacez eth0 par l'interface ouverte à Internet (par exemple, wlan0 si wifi)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enxb827eb71a4fc -j MASQUERADE; ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o enxb827eb71a4fc -j M$
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o enxb827eb71a4fc -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o enxb827eb71a4fc -j$
[Peer]
# Client1
PublicKey = <client1_public.key>
AllowedIPs = 192.168.2.1/32,
Endpoint = 192.168.1.1:51820
pi @ raspberrypi: ~ / wgkeys $ sudo wg-quick up wg0
pi @ raspberrypi: ~ / wgkeys $ sudo wg show
Comment et où dois-je vérifier que les routes ont été créées pour permettre aux clients d'accéder au réseau local en 192.168.1.x ?
-
sudo journalctl -b -t wg-quick
sinon:
AllowedIPs = 192.168.2.1/32,
bizarre cette virgule a la fin, enleve la
-
sudo journalctl -b -t wg-quick
sinon:
bizarre cette virgule a la fin, enleve la
Merci pour ton retour.
La virgule sépare l'adresse ipv6 allouée à l'interface du client. Adresse que j'ai pas indiqué sur la copie que j'ai mise sur le forum ci-dessus.
La commande me renvoie ceci :
pi@raspberrypi:~ $ sudo journalctl -b -t wg-quick
-- Logs begin at Sun 2019-11-10 21:14:01 CET, end at Mon 2019-11-11 22:28:34 CET
-- No entries --
lines 1-2/2 (END)
J'en conclu que ce n'est pas bon.
Il faudrait donc que je rajoute la route.
Mais comment faire ?
-
Sous Wireguard les routes sont apellées "Allowed IP".
Tu n'es pas obligé de faire du full routes statiques.
Tu peux faire tourner un IGP avec FRR pour annoncer tout tes réseaux.
-
La commande me renvoie ceci :
pi@raspberrypi:~ $ sudo journalctl -b -t wg-quick
-- Logs begin at Sun 2019-11-10 21:14:01 CET, end at Mon 2019-11-11 22:28:34 CET
-- No entries --
lines 1-2/2 (END)
J'en conclu que ce n'est pas bon.
par forcement, ton systeme n'utilise peut-etre pas systemd ?
sudo systemctl status wg-quick@wg0.service
affiche quoi ?
-
par forcement, ton systeme n'utilise peut-etre pas systemd ?
sudo systemctl status wg-quick@wg0.service
affiche quoi ?
J'ai le retour suivant :
pi@raspberrypi:~ $ sudo systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset
Active: active (exited) since Wed 2019-10-30 08:11:54 CET; 1 weeks 6 days ago
Docs: man:wg-quick(8)
man:wg(8)
https://www.wireguard.com/
https://www.wireguard.com/quickstart/
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8
https://git.zx2c4.com/WireGuard/about/src/tools/man/wg.8
Main PID: 541 (code=exited, status=0/SUCCESS)
Memory: 0B
CGroup: /system.slice/system-wg\x2dquick.slice/wg-quick@wg0.service
Warning: Journal has been rotated since unit was started. Log output is incomple
lines 1-14/14 (END)
Merci pour ton aide !!!
-
donc c'est bien systemd. le service est bien 'enabled' donc démarrera au boot. il faut eviter de faire 'sudo wg-quick up' (ou down).
Concernant journalctl si y'a rien c'est que le journal ne remonte pas trop dans le temps peut-etre dans ce cas:
sudo systemctl stop wg-quick@wg0.servicepuis
sudo systemctl start wg-quick@wg0.service
(ces 2 commandes sont la méthode "propre" démarrer / arrêter wg , au lieu de "sudo wg-quick up/down")
-
sudo systemctl stop wg-quick@wg0.servicepuis
sudo systemctl start wg-quick@wg0.service
(ces 2 commandes sont la méthode "propre" démarrer / arrêter wg , au lieu de "sudo wg-quick up/down")
Merci kgersen, je vais regarder cela dès que possible et utiliser ces commandes.
Plus j'y pense et plus je me dis que j'ai un problème sur mon windows 10 car mon android et de mémoire le mac de ma femme arrive à voir les autres périphériques en 192.168.1.x alors que le pc non quand le VPN est activé.
Ne serait-ce pas plutôt les connexions qui ne passent pas par le VPN dès Windows ?