Auteur Sujet: VPN Wireguard entre 2 openWRT (Lu 24904 fois)

renaud07 · « **Réponse #60 le:** 20 avril 2019 à 14:50:53 »

Pas mal cette analogie avec les rues

Sinon, de mon côté malgré ce délai de connexion, ça semble aller beaucoup mieux en V4. Je peux ping tous les hôtes 192.168.1.0 depuis 192.168.2.2 et même ouvrir une session ssh sur le RPi ou consulter mes partages réseau sur le NAS alors qu'en v6 ça passait pas.

Par contre ça ne fonctionne pas dans l’autre sens, tout est bloqué, et je n'arrive pas à comprendre... toujours aucune règle de pare-feu pourtant. Seul les interfaces wg0 peuvent se ping.

J'avais également réussi hier à connecter mon tel en 4G et j’arrivais à naviguer depuis le tunnel, aujourd’hui, pouf, ça ne fonctionne plus... je vois simplement les requêtes arriver sur wg0 mais le NAT ne semble pas s'opérer.

Voici la conf après tout ça :

Code: [Sélectionner]

# SiteA
[Interface]
Address = 172.16.0.1/32
PrivateKey = xxx
ListenPort = 51280

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens18 -j MASQUERADE

# SiteB
[Peer]
PublicKey = xxx
AllowedIPs = 192.168.1.0/24, 172.16.0.2/32

# Android
[Peer]
PublicKey = xxx
AllowedIPs = 172.16.0.3/32

kgersen · « **Réponse #61 le:** 20 avril 2019 à 16:04:10 »

fais les check de base:
- routage activé la ou il faut? (sysctl net.ipv4.ip_forward)
- vérif les tables de routage

Citer

Seul les interfaces wg0 peuvent se ping

Dans ce cas soit c'est le routage soit c'est les "AllowedIPs" qui sont mal définies (sachant que wg-quick utilise les AllowedIPs pour configurer des routes).

sinon un nat propre c'est (A = interface de sortie sur le net):

Code: [Sélectionner]

iptables -t nat -A POSTROUTING -o A -j MASQUERADE
iptables -A FORWARD -i A -o wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wg0 -o A -j ACCEPT

renaud07 · « **Réponse #62 le:** 20 avril 2019 à 16:59:21 »

Le forward est bien activé des 2 côtés, je l'ai forcé dans sysctl.conf bien qu'il soit déjà activé au démarrage.

Je ne sais pas où j'ai pu merder, j'ai revérifié des dizaines de fois, ça commence à me rendre fou.

Code: [Sélectionner]

root@wgvpnlpa:~# sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Code: [Sélectionner]

root@wgvpnlhst:~# sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Code: [Sélectionner]

root@wgvpnlhst:~# ip route
default via 192.168.2.1 dev ens18 onlink 
172.16.0.0/24 dev wg0 proto kernel scope link src 172.16.0.1 
192.168.1.0/24 dev wg0 scope link 
192.168.2.0/24 dev ens18 proto kernel scope link src 192.168.2.2

Code: [Sélectionner]

root@wgvpnlpa:~# ip route
default via 192.168.1.1 dev enp0s3 onlink 
172.16.0.0/24 dev wg0 proto kernel scope link src 172.16.0.2 
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.8 
192.168.2.0/24 dev wg0 scope link

Code: [Sélectionner]

# SiteB
[Interface]
Address = 172.16.0.2/24
PrivateKey = (hide)
#ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o enp0s3 -j MASQUERADE

# SiteA
[Peer]
PublicKey = xxx
AllowedIPs = 192.168.2.0/24, 172.16.0.1/32
Endpoint = siteA.dyn.net:51280
PersistentKeepAlive = 25

Tout à l'air d'aller bien coté serveur :

Code: [Sélectionner]

root@wgvpnlhst:~# wg
interface: wg0
  public key: (hide)
  private key: (hidden)
  listening port: 51280

peer: SiteA
  endpoint: 90.14.2.x:59713
  allowed ips: 192.168.1.0/24, 172.16.0.2/32
  latest handshake: 8 seconds ago
  transfer: 648 B received, 1.80 KiB sent

peer: Android
  endpoint: 77.136.85.24:40246
  allowed ips: 172.16.0.3/32
  latest handshake: 1 minute, 39 seconds ago
  transfer: 183.21 KiB received, 1.18 MiB sent

kgersen · « **Réponse #63 le:** 20 avril 2019 à 19:51:34 »

c'est des versions récentes de wireguard ?

t'as un masquerade global site b ? c'est pas clair clair ton archi. tu devrais faire un dessin ca aide pour trouver les bugs

renaud07 · « **Réponse #64 le:** 20 avril 2019 à 20:15:17 »

La version c'est celle de debian sid. Pour le masquerade je ne sais pas s'il est indispensable, j'ai testé a tout hasard.

Voici pour le schéma ( ça me parait très simple perso)

J'ai changé et mis le Rpi en client car ça devra tourner dessus. Là j'ai fait un test en compilant à partir des sources, mais mon problème est toujours présent. Néanmoins j'arrive à ping l'interface WG et l'ip LAN mais l’accès au reste du réseau est toujours HS.

kgersen · « **Réponse #65 le:** 20 avril 2019 à 21:52:16 »

c'est dur a suivre à partir des trucs postés avant...

vm serveur site a = wgvpnlhst ? ou est wgvpnlpa?

renaud07 · « **Réponse #66 le:** 20 avril 2019 à 22:19:31 »

C'est ça, et wgvpnlpa c'est le site B à la place du Rpi. Je testais en VM sur mon PC avant de tout mettre en prod et d'upgrader le Rpi vers stretch.

kgersen · « **Réponse #67 le:** 20 avril 2019 à 22:47:13 »

franchement wireguard c'est super simple en principe...efface tout et repart de zero en utilisant que wg-quick ? on arrive souvent a se mélanger les pinceaux en faisant un mix de wg et wg-quick.

renaud07 · « **Réponse #68 le:** 21 avril 2019 à 00:03:28 »

Un point qui ne m'est pas très clair : Lorsque iptables accepte tout, et que le forwarding est activé, je n'ai en principe pas besoin de préciser de règle particulière dans le genre :

Code: [Sélectionner]

/sbin/iptables -A FORWARD -i ens18 -o wg0  -j ACCEPT
/sbin/iptables -A FORWARD -i wg0 -o ens18 -j ACCEPT

Pour que les paquets passe d'une interface à l'autre ?

On est d'accord que c'est uniquement quand on bloque tout par défaut ?

kgersen · « **Réponse #69 le:** 21 avril 2019 à 00:45:08 »

Citation de: renaud07 le 21 avril 2019 à 00:03:28

Un point qui ne m'est pas très clair : Lorsque iptables accepte tout, et que le forwarding est activé, je n'ai en principe pas besoin de préciser de règle particulière dans le genre :

Code: [Sélectionner]
/sbin/iptables -A FORWARD -i ens18 -o wg0 -j ACCEPT /sbin/iptables -A FORWARD -i wg0 -o ens18 -j ACCEPT
Pour que les paquets passe d'une interface à l'autre ?

On est d'accord que c'est uniquement quand on bloque tout par défaut ?

oui par defaut y'a rien de bloqué il faut juste le routage soit activé (net.ipv4.ip_forward) et que les routes soient correctes pour que ca passe d'une interface a l'autre.

au besoin reset iptables: https://www.digitalocean.com/community/tutorials/how-to-list-and-delete-iptables-firewall-rules#flush-all-rules,-delete-all-chains,-and-accept-all

renaud07 · « **Réponse #70 le:** 22 avril 2019 à 03:05:30 »

Cette fois, j'abandonne pour de bon.

J'ai tout réinstallé de 0 avec ubuntu et j'arrive au même résultat... Ça me fait clairement ch***, mais là j'en peux plus.

Encore merci d'avoir essayé de m'aider

renaud07 · « **Réponse #71 le:** 05 septembre 2019 à 03:41:14 »

Après plusieurs mois, je pense avoir un début d'explication : Il semble que le ping soit bloqué à partir des endpoint. Mais pas à partir du reste du réseau. Je me suis arraché les cheveux sur ça, alors que si ça se trouve ça fonctionnait depuis le début...

Actuellement, j'ai 2 interfaces en ipv6 (afin de ne pas gérer les changements d'ip), pour relier les LAN entre eux et un autre pour le SIP et ça fonctionne depuis plusieurs semaines sans problème. La config initiale n'a pourtant pas changée.

Et j'ai pu updrager les systèmes sans soucis (passage à debian 10, avec même une compilation sur le Pi à cause de certaines instructions non présentes sur le CPU du 2).