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

kgersen · « **Réponse #24 le:** 17 avril 2019 à 21:00:40 »

'6in4-HENET' t'as un tunnel Hurricane quelque part ?

c'est que du wg-quick les configs?

au besoin test que le flux udp passe avant ? le mieux c'est avec "socat" (app install socat sous linux ou https://openwrt.org/packages/pkgdata/socat).

en ipv6:

Code: [Sélectionner]

socat -6 -v - UDP:ipv6 ou dns distant:51820(mettre l'ipv6 entre []) puis taper la touche "entrer" si

Code: [Sélectionner]

> date heure  length=1 from=0 to=0

s'affiche c'est bon. ctrl-c pour terminer socat.

si "Connection refused" s'affiche y'a un souci d’accès au port, wg n'est pas le probleme (edit: s'il tourne).

kgersen · « **Réponse #25 le:** 17 avril 2019 à 21:02:25 »

Citation de: renaud07 le 17 avril 2019 à 20:54:09

Y'a aussi un truc qui me chiffonne :
Code: [Sélectionner]
root@wgvpnlhst:~# ip link add wg0 type wireguard root@wgvpnlhst:~# wg-quick up wg0 wg-quick: `wg0' already exists

ah! c'est "ip link add ..." OU wg-quick up pas les 2!

wg-quick est une surcouche sur wg qui automatise les commandes "ip" & "wg" mais s'arrete a la moindre erreur.

kgersen · « **Réponse #26 le:** 17 avril 2019 à 21:05:56 »

ps - pour voir si le port est en écoute:

Code: [Sélectionner]

ss -uap

kgersen · « **Réponse #27 le:** 17 avril 2019 à 21:07:34 »

mtu 1200 ? IPv6 a besoin au minimum de 1280.. marche pas sinon.

renaud07 · « **Réponse #28 le:** 17 avril 2019 à 22:02:51 »

Citation de: kgersen le 17 avril 2019 à 21:00:40

'6in4-HENET' t'as un tunnel Hurricane quelque part ?

Oui, pas le choix.

Citer

c'est que du wg-quick les configs?

Yep, j'ai simplement ajouté wg-quick@wg0 au démarrage

Citer

au besoin test que le flux udp passe avant ? le mieux c'est avec "socat" (app install socat sous linux ou https://openwrt.org/packages/pkgdata/socat).

en ipv6:

Code: [Sélectionner]
socat -6 -v - UDP:ipv6 ou dns distant:51820(mettre l'ipv6 entre []) puis taper la touche "entrer" si

Code: [Sélectionner]
> date heure length=1 from=0 to=0s'affiche c'est bon. ctrl-c pour terminer socat.

si "Connection refused" s'affiche y'a un souci d’accès au port, wg n'est pas le probleme (edit: s'il tourne).

Ça ne m'affiche rien une fois lancé, juste le rectangle qui clignote... comme s'il attendait la réponse qui ne vient pas.

Citation de: kgersen le 17 avril 2019 à 21:05:56

ps - pour voir si le port est en écoute:

Code: [Sélectionner]
ss -uap

C'est ok des deux côtés.

Après avoir testé des dizaines de combinaisons, le ping fonctionne enfin, mais c'est très lent : ça met un temps fou à négocier, de même j'ai l'impression que si je ne met pas le keepalive ça ne fonctionne carrèment pas... et il faut aussi que je mette explicitement les adresses de chaque côté... sinon pareil, aucune négo.

Citation de: kgersen le 17 avril 2019 à 21:07:34

mtu 1200 ? IPv6 a besoin au minimum de 1280.. marche pas sinon.

La MTU serait donc la cause de ce fonctionnement (très) aléatoire ? Je n'ai rien défini c'est wg qui l'a choisi tout seul.

Citation de: kgersen le 17 avril 2019 à 21:02:25

ah! c'est "ip link add ..." OU wg-quick up pas les 2!

wg-quick est une surcouche sur wg qui automatise les commandes "ip" & "wg" mais s'arrete a la moindre erreur.

Oui, j'ai réalisé après coup

kgersen · « **Réponse #29 le:** 17 avril 2019 à 22:12:15 »

pourquoi pas le choix ? autant faire en IPv4 si les sites n'ont pas IPv6.

Citation de: renaud07 le 17 avril 2019 à 22:02:51

Ça ne m'affiche rien une fois lancé, juste le rectangle qui clignote... comme s'il attendait la réponse qui ne vient pas.

faut taper "entrer" pour voir une réponse. Si rien ne s'affiche c'est que le flux se perd en chemin ...('socat' attend du texte taper au clavier puis l'envoi sur la connexion établie, si a l'autre bout ca répond quelque chose il l'affiche).

Citation de: renaud07 le 17 avril 2019 à 22:02:51

La MTU serait donc la cause de ce fonctionnement aléatoire ?

Pour ipv6 oui il ne faut pas descendre en dessous de 1280.

1500 de base, les tunnel HE prennent 20 donc reste 1480 ca passe large pour faire du wireguard.
wg-quick enleve 80 octet au mtu qu'il trouve en dessous, donc si ca affiche 1200 c'est qu'il voit 1280 en dessous-> l'interface 6in4-HENET est mal configurée niveau mtu.

renaud07 · « **Réponse #30 le:** 17 avril 2019 à 22:27:13 »

Citation de: kgersen le 17 avril 2019 à 22:12:15

pourquoi pas le choix ? autant faire en IPv4 si les sites n'ont pas IPv6.

C'était pour m'éviter le script de MAJ des ip dynamiques.

Citation de: kgersen le 17 avril 2019 à 22:12:15

faut taper "entrer" pour voir une réponse. Si rien ne s'affiche c'est que le flux se perd en chemin ...('socat' attend du texte taper au clavier puis l'envoi sur la connexion établie, si a l'autre bout ca répond quelque chose il l'affiche).

Ah ok... donc c'est bon, je ne tapais qu'une seule fois sur enter pour valider, la seconde fois il me renvoi bien le texte

Citer

Pour ipv6 oui il ne faut pas descendre en dessous de 1280.

1500 de base, les tunnel HE prennent 20 donc reste 1480 ca passe large pour faire du wireguard.
wg-quick enleve 80 octet au mtu qu'il trouve en dessous, donc si ca affiche 1200 c'est qu'il voit 1280 en dessous-> l'interface 6in4-HENET est mal configurée niveau mtu.

Effectivement, la MTU était à 1280. Rectifié à 1480.

Je vais voir si ça fonctionne mieux.

renaud07 · « **Réponse #31 le:** 17 avril 2019 à 23:01:53 »

Je ne saurais dire s'il y a du mieux... peut-être un tout petit peu.

J'ai réessayé en virant PersistentKeepAlive et le port fixe d'un côté et là la négo a été trèèèèès longue, je dirais bien une minute une fois la VM redémarrée.

renaud07 · « **Réponse #32 le:** 18 avril 2019 à 00:42:24 »

Maintenant que ça fonctionne à peu près, occupons nous du routage qui est aussi capricieux :

Site A :

Code: [Sélectionner]

root@wgvpnlpa:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 enp0s3
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0

Site B :

Code: [Sélectionner]

root@wgvpnlhst:~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 ens18
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 ens18

-le ping 192.168.2.0/24 > 192.168.1.0/24 fonctionne mais bizarrement pas avec tous les devices. Par exemple mon raspberry pi qui est en 192.168.1.10 est injoignable. Par contre ça fonctionne pour le NAS (192.168.1.2), mon PC (192.168.1.11) ou le routeur (192.168.1.1).

Code: [Sélectionner]

root@wgvpnlhst:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=212 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=107 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=107 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=105 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=63 time=107 ms
^C
--- 192.168.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 105.701/128.361/212.623/42.141 ms

Code: [Sélectionner]

root@wgvpnlhst:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=63 time=105 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=63 time=105 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=63 time=104 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=63 time=104 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=63 time=104 ms
^C
--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 104.012/104.679/105.256/0.508 ms

Code: [Sélectionner]

root@wgvpnlhst:~# ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=62 time=111 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=107 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=63 time=106 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=63 time=104 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=63 time=105 ms
^C
--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 104.520/106.868/111.129/2.373 ms

Code: [Sélectionner]

root@wgvpnlhst:~# ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
^C
--- 192.168.1.10 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2036ms

-le ping 192.168.1.0/24 > 192.168.2.0/24 fonctionne uniquement vers le serveur WG (192.168.2.2) tout le reste est KO :

Code: [Sélectionner]

root@wgvpnlpa:~# ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=106 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=103 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=104 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=104 ms
^C
--- 192.168.2.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 103.939/105.013/106.538/1.029 ms

Code: [Sélectionner]

root@wgvpnlpa:~# ping 192.168.2.3
PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data.
^C
--- 192.168.2.3 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4083ms

Code: [Sélectionner]

root@wgvpnlpa:~# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Une idée ?

Pour ce qui est est d'ouvrir une session SSH par exemple ça ne fonctionne pas non plus... même sur ceux répondant au ping.

renaud07 · « **Réponse #33 le:** 18 avril 2019 à 00:47:50 »

Je suis pris d'un doute : Pour que le routage se fasse sur le LAN il faut bien ajouter une route statique sur chaque routeur avec comme gateway les serveurs WG ? Soit :

192.168.1.0/24 GW 192.168.2.2
192.168.2.0/24 GW 192.168.1.8

Parce ce que ça n'a pas l'air de marcher :

Code: [Sélectionner]

root@LEDE:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         193.253.160.3   0.0.0.0         UG    0      0        0 pppoe-wan
192.168.1.0     192.168.2.2     255.255.255.0   UG    0      0        0 br-lan
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 br-lan
193.253.160.3   0.0.0.0         255.255.255.255 UH    0      0        0 pppoe-wan
216.66.84.42    193.253.160.3   255.255.255.255 UGH   0      0        0 pppoe-wan

root@LEDE:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
^C
--- 192.168.1.1 ping statistics ---
18 packets transmitted, 0 packets received, 100% packet loss

root@LEDE:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11): 56 data bytes
^C
--- 192.168.1.11 ping statistics ---
35 packets transmitted, 0 packets received, 100% packet loss

kgersen · « **Réponse #34 le:** 18 avril 2019 à 10:50:27 »

oui une route vers chaque serveur wg.

coté LEDE ca a l'air bon.

utiliser 'ip route'' plutot que 'route -n'

si certains protocoles passent et pas d'autre (ping mais pas ssh) ca peut être un souci de firewall.

attention aussi a ce que le 'masquerade' ne se déclenche pas pour ce traffic.

renaud07 · « **Réponse #35 le:** 18 avril 2019 à 14:27:15 »

Je vais peut-être passer pour un inconscient qui n'a que faire de la sécurité, mais il n'y a aucun pare-feu sur les machines.

Par exemple le raspberry qui ne fonctionne pas :

Code: [Sélectionner]

root@raspberrypi:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Pour l'accès via le LAN, ça fonctionne en fait, mais que sur le LAN 192.168.1.0 et que vers le serveur WG le reste KO :

Code: [Sélectionner]

renaud@renaud-pc:~$ ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
64 bytes from 192.168.2.2: icmp_seq=1 ttl=63 time=106 ms
From 192.168.1.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.8)
64 bytes from 192.168.2.2: icmp_seq=2 ttl=63 time=106 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=63 time=107 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=63 time=106 ms
64 bytes from 192.168.2.2: icmp_seq=5 ttl=63 time=106 ms
^C
--- 192.168.2.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 106.025/106.698/107.000/0.501 ms

De même que la session SSH (va comprendre...) :

Code: [Sélectionner]

renaud@renaud-pc:~$ ssh root@192.168.2.2
root@192.168.2.2's password: 
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Apr 18 14:07:42 2019 from 192.168.2.6
root@debian:~#

Code: [Sélectionner]

root@BT-LPA:~# ip route
default via 193.253.160.3 dev pppoe-wan proto static 
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1 
192.168.2.0/24 via 192.168.1.8 dev br-lan proto static 
193.253.160.3 dev pppoe-wan proto kernel scope link src 90.14.2.x
216.66.84.42 via 193.253.160.3 dev pppoe-wan proto static

Code: [Sélectionner]

root@LEDE:~# ip route
default via 193.253.160.3 dev pppoe-wan proto static 
192.168.1.0/24 via 192.168.2.2 dev br-lan proto static 
192.168.2.0/24 dev br-lan proto kernel scope link src 192.168.2.1 
193.253.160.3 dev pppoe-wan proto kernel scope link src 90.14.0.x 
216.66.84.42 via 193.253.160.3 dev pppoe-wan proto static

Alors que les tables sont ok des 2 côtés...

Comme hier, même après avoir tout redémarré, c'est pareil certaines destination sont pigeables, les autres non, alors qu'il n'y a aucune raison valable.

Pour la session SSH qui ne marchait pas, je crois que c'était la MTU qui faisait encore n'importe quoi. Je l'ai surprise à être à 65456 après avoir rectifié celle de HE. Du coup j'ai forcé des 2 côtés à 1300.