La Fibre

Télécom => Réseau => reseau VPN => Discussion démarrée par: renaud07 le 02 mars 2019 à 02:41:06

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 02 mars 2019 à 02:41:06
Bonsoir,

En quête de bidouille et d'expérimentation, je voudrais me monter un VPN entre 2 BT home hub 5 sous LEDE.

Ayant fait un peu le tour des différentes solution de tunnelisation, j'ai retenu le "petit nouveau" wireguard, qui à l'air plus simple à configurer qu'ipsec ou openVPN et qui apparemment supporte nativement les ip dynamiques (puisque on peut renter un hostname en endpoint, ce qui dans mon cas est indispensable, merci à Orange de ne pas changer ses DSLAM).

Si j'ai tout compris, il faut :

-générer une paire de clés publique/privée sur chaque routeur et utiliser la clé publique de l'autre
-prendre une plage d'ip privée et l'affecter au tunnel (ex 172.16.0.0/24)
-autoriser cette plage + celle des 2 LAN à emprunter le tunnel (ex 192.168.1.0/24 et 192.168.2.0/24)
-affecter une zone de firewall à wireguard ou l'ajouter à celle du LAN
-mettre en endpoint le routeur d'en face
-croiser les doigts pour que ça fonctionne

Merci d'avance.
Titre: VPN Wireguard entre 2 openWRT
Posté par: FloBaoti le 02 mars 2019 à 09:22:39
Bonjour,

Quelle est la question ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 02 mars 2019 à 13:38:47
Y'en a pas vraiment en fait, c'est juste pour voir si je n'ai pas oublié d'étapes (pour ceux qui auraient déjà monté un tel tunnel). Ma plus grosse crainte c'est de planter les routeurs et ne plus avoir accès à rien. Bien que jusqu'à présent ça ne m'est pas encore arrivé...
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 02 mars 2019 à 15:19:58
En relisant la doc, j'ai eu un doute : le endpoint c'est uniquement pour le client ?

Admettons que A soit le serveur et B le client. Sur A il faut simplement renseigner la clé publique de B et sur B la clé publique de A + endpoint ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: FloBaoti le 02 mars 2019 à 16:09:17
Il n'y a pas de client et de serveur.

Chaque partie doit désigner l'autre avec une directive endpoint + la clé publique.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 02 mars 2019 à 16:54:19
Ok on va essayer cette config alors. Ce qui est étrange c'est que sur plusieurs tutos, c'est seulement le "client" qui doit ajouter le endpoint, le serveur se contente juste de la clé publique de chaque client :

https://www.tutos.snatch-crash.fr/wireguard-vpn-rapide-moderne-et-securise/
https://casept.github.io/post/wireguard-server-on-openwrt-router/

Ils auraient donc faux ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: FloBaoti le 02 mars 2019 à 16:56:14
Ca doit être possible de ne pas mettre le endpoint, mais je ne vois toujours pas le problème, autant le mettre puisque c'est prévu ainsi. Je ne vois pas ce qui est bloquant.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 02 mars 2019 à 20:27:54
Ce qui devait arriver arriva. Au moment fatidique de faire un reboot pour prendre en compte la création du tunnel, le routeur a mystérieusement bloqué toutes les connexions.

Apparemment il boot toujours correctement (d'après les LED) mais pas accès au net ni à l’interface web... pourtant j'avais redémarré le pare-feu en CLI avant et il n'y avait aucun problème de règles. Et comme par hasard c'est sur celui à distance, obligé d'attendre demain pour aller réparer moi-même, donner les instructions par téléphone pour tout reparaméter, on y passerait des heures  >:(
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 03 mars 2019 à 01:36:29
Finalement c'est moins grave que je ne l'aurais pensé, après plus ample investigation le ping et le ssh fonctionne.

Apparemment c'est la session PPPoE qui ne monte pas... ça par contre c'est étrange, à moins que j'ai décoché le "Bring up on boot" sans faire attention... Et vu qu'il n'avait pas redémarré depuis plus de 6 mois (un record me concernant sur une synchro ADSL). Bref, la suite demain.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 03 mars 2019 à 16:11:23
Le routeur n'était finalement pas du tout bloqué, lors de l'essai hier firefox a du faire une redirection de la page en https, d'où la connexion échouée. Et ce qui bloquait la session PPPoE c'était le bridge que j'avais créé pour un essai avec pfsense, qui se connectait en premier, rien de grave donc.

Par contre, une fois remis d’aplomb, la simple connexion du tunnel fait réellement planter le routeur... hard reboot obligatoire... Je l'ai supprimée et recrée, et ça a fonctionné. Mais je me suis rendu compte après coup que je n'avais pas mis les bonnes addresses, j'ai donc re-modifié et de nouveau blocage complet.

J'ai l'impression que dans tous les cas si je démarre le tunnel après que la session PPPoE soit établie, c'est blocage instantané (ça reste bloqué sur "interface is reconnecting"). Par contre si je le laisse en automatique, au reboot des fois ça bloque des fois ça passe... c'est très étrange. Sur le routeur "serveur" je pouvais faire 10000x reconnecter l'interface aucun blocage.

La seule fois où j'ai eu le tunnel fonctionnel je voyais bien les deux routeurs connectés avec du trafic qui augmente côté "serveur", par contre je suis toujours à 0kb coté client... et un ping ou une connexion ssh sur le LAN "serveur" ne passait pas...

Dnas un cas j'ai droit à packet filtered, avec une IP étrange
renaud@HP:~$ ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
From 193.253.172.165 icmp_seq=1 Packet filtered
From 193.253.172.165 icmp_seq=2 Packet filtered
From 193.253.172.165 icmp_seq=3 Packet filtered
From 193.253.172.165 icmp_seq=4 Packet filtered
From 193.253.172.165 icmp_seq=5 Packet filtered

Et avec une conexion ssh : no route to host

J'ai bien ajouté le tunnel dans la zone LAN et coché sur les 2 routeurs la création des routes automatique.

Voici la config :

Serveur :
config interface 'tunnel'
option proto 'wireguard'
option private_key 'xxxxxx'
option listen_port '51820'
list addresses '172.16.0.1/24'

config wireguard_tunnel
list allowed_ips '172.16.0.0/24'
list allowed_ips '192.168.1.0/24'
list allowed_ips '192.168.2.0/24'
option public_key 'xxxxxx'
option persistent_keepalive '25'
option route_allowed_ips '1'

Client :
config wireguard_tunnel
option public_key 'xxxxx'
option endpoint_host 'mondomaine.net'
option route_allowed_ips '1'
list allowed_ips '172.16.0.0/24'
list allowed_ips '192.168.1.0/24'
list allowed_ips '192.168.2.0/24'

config interface 'tunnel'
option proto 'wireguard'
option auto '0'
option private_key 'xxxxxx'
list addresses '172.16.0.2/24'



Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 03 mars 2019 à 17:18:50
Je pense qu'il y a un sérieux bug avec wireguard ou du moins pour cette version de LEDE (la 17.01.4)

J'ai voulu à tout hasard réinstaller les paquets et régénérer les clés, et au moment de relancer l'interface sur le routeur serveur (juste pour prendre en compte la nouvelle clé du client), avec un ifdown ifup, devinez quoi : il a crashé à son tour ! Et le plus fort c'est que c'est absolument instantané, je tape ifup tunnel et bam, la ligne de commande ne répond plus !

EDIT : Je ne suis pas le seul à avoir le problème apparemment, et en plus c'est la même version de LEDE : https://forum.openwrt.org/t/wireguard-crashing-device-kernel-errors/8373

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 03 mars 2019 à 21:06:30
Mise à jour du routeur client en openwrt 18.06 et toujours le même problème, ça crash inexorablement au démarrage...  :'(

Je vais laisser tomber à mon avis et me monter un tunnel IPsec plus classique. Reste à résoudre le problème des IP dynamiques. Avec un script qui modifierait le fichier de conf à chaque changement d'ip ça pourrait le faire ?

J'ai rien dit, dans la doc openwrt (https://openwrt.org/docs/guide-user/services/vpn/ipsec/strongswan/basic) il est spécifié qu'on peut mettre soit une ip soit un FQDN pour le endpoint, donc ça devrait le faire  8)
 
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 04 mars 2019 à 14:24:11
Je m'attaque donc au tunnel IPsec. Avant de tout mettre à jour, est-ce bien la config correct pour un tunnel IPsec en PSK ? (Tiré de ce topic https://forum.openwrt.org/t/ipsec-site-to-site-tunnel/17920).


config 'ipsec'
list listen ''
option 'debug' '2'

config 'remote' 'other'
option 'enabled' '1'
option 'gateway' 'FQDN.routeur.B'
option 'authentication_method' 'psk'
option 'pre_shared_key' 'xxxxxx'
option 'exchange_mode' 'aggressive'
option 'local_identifier' 'tunnelid'
list 'crypto_proposal' 'pre_g14_aes_sha1'
list 'tunnel' 'other_lan'

config 'crypto_proposal' 'pre_g14_aes_sha1'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'
option 'dh_group' 'modp2048'

config 'tunnel' 'other_lan'
option 'local_subnet' '192.168.1.0/24'
option 'remote_subnet' '192.168.2.0/24'
option 'crypto_proposal' 'g14_aes_sha1'

config 'crypto_proposal' 'g14_aes_sha1'
option 'dh_group' 'modp2048'
option 'encryption_algorithm' 'aes128'
option 'hash_algorithm' 'sha1'

Et même code de l'autre côté en inversant remote/local subnet, ainsi que le FQDN.

Étant déjà en 18.06 sur un des routeurs, la config est bien générée, par contre sur celui resté en 17.01 ça ne fonctionne pas, j'ai fait boulette d'installer le paquet strongswan-full au lieu de strongswan et j'ai une erreur de script à la fin que je n'arrive pas à éradiquer (même en essayant de désinstaller/réinstaller) à moins que ça ne soit pas lié :
root@LEDE:~# opkg install strongswan
Installing strongswan (5.5.3-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.4/packages/mips_24kc/packages/strongswan_5.5.3-1_mips_24kc.ipk
Configuring strongswan.
/etc/rc.common: line 145: ipsec: not found

Même erreur lorsque je tente de démarrer le service. Je suis bon pour remettre à zéro encore une fois ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 04 mars 2019 à 14:50:12
fait un sujet a part si tu passe en IPsec ?

pour Wireguard,cf https://forum.openwrt.org/t/solved-setup-wireguard-connecting-two-networks/4215 ?

et y'a un tuto la: https://danrl.com/blog/2017/luci-proto-wireguard/ (pas forcement a jour).
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 04 mars 2019 à 15:38:12
Pour wireguard, ce n'est pas la configuration qui pose problème à priori (le tunnel montait bien), mais le fait que ça crash une fois sur 2 quand l'interface démarre. J'ai pas très envie de replanter les routeurs une autre fois... J'ai eu ma dose.

Je vais faire un autre sujet pour IPsec, t'as raison, ça sera plus clair  :)
Titre: VPN Wireguard entre 2 openWRT
Posté par: Nh3xus le 04 mars 2019 à 18:28:58
C'est dommage que Wireguard ne soit pas encore intégré nativement au kernel Linux.

En dehors du manque d'audit de Wireguard, certains devs pensent que ce truc n'a rien à faire dans le noyau.

Je ne sais pas qui a raison.

En tout cas, Linus n'a rien trouvé à redire sur le code source de WG pour le moment.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 00:13:52
J'ai décidé de retester wireguard sur des VM debian classique, mais conséquence : il y a du NAT de chaque côté.

Si les interfaces montent bien, je n'ai aucun handshake entre les deux. Pourtant j'ai bien forwardé le 51820 vers chaque serveur...

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxxOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: 90.14.5.x:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cdb4::/64

root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxkC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  endpoint: 90.14.0.x:51820
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64

# site A
[Interface]
Address = 172.16.0.1/24
PrivateKey = (hide)
ListenPort = 51820

# site B
[Peer]
PublicKey = xxxxxx6HgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
Endpoint = siteB.dyn.net:51820
AllowedIPs = 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64
PersistentKeepalive = 15

# site B
[Interface]
Address = 172.16.0.2/24
PrivateKey = (hide)
ListenPort = 51820

# site A
[Peer]
PublicKey =XXXXXXWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
Endpoint = siteA.dyn.net:51820
AllowedIPs = 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cdb4::/64
PersistentKeepalive = 15

Une idée ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 02:54:22
Testé en IPv6 : même résultat...  on pourra pas dire que c'est à cause du NAT, vu qui y'en a pas  :-\

Et oui j'ai bien pensé à ouvrir le port, et les 2 ip sont bien pingables :
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 07:55:28
curieux cela a l'air correct. l'erreur type avec wg c'est l'inversion des public/private keys par exemple ou ouvrir tcp au lieu d'udp ou les valeurs des endpoints.

il faut aussi installer le routage si ce n'est pas  déja fait (ie si on utlise wg-quick ou pas).

sinon capture et recheck config firewall.

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 16:16:05
Je viens juste de démarrer ma VM et ça marche  :o :
root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  endpoint: 90.14.0.x:51820
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64
  latest handshake: 43 seconds ago
  transfer: 188 B received, 180 B sent
  persistent keepalive: every 15 seconds
root@wgvpnlpa:~# ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=44.7 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=44.2 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=46.6 ms
64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=46.1 ms
64 bytes from 172.16.0.2: icmp_seq=5 ttl=64 time=44.9 ms
64 bytes from 172.16.0.2: icmp_seq=6 ttl=64 time=44.3 ms
64 bytes from 172.16.0.2: icmp_seq=7 ttl=64 time=44.2 ms
64 bytes from 172.16.0.2: icmp_seq=8 ttl=64 time=43.8 ms
64 bytes from 172.16.0.2: icmp_seq=9 ttl=64 time=44.1 ms
^C
--- 172.16.0.2 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8016ms
rtt min/avg/max/mdev = 43.897/44.828/46.625/0.916 ms

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxxxHgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: 90.14.5.x:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64
  latest handshake: 1 minute, 58 seconds ago
  transfer: 12.20 KiB received, 1.06 MiB sent
  persistent keepalive: every 15 seconds
root@wgvpnlhst:~# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=45.4 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=46.2 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=44.7 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=44.3 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=64 time=44.2 ms
64 bytes from 172.16.0.1: icmp_seq=6 ttl=64 time=44.2 ms
^C
--- 172.16.0.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 44.293/44.901/46.266/0.772 ms
root@wgvpnlhst:~#

Faudra qu'on m'explique...
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 16:46:23
quelques retours avec wireguard:

- on a pas besoin de mettre des IPv4 et/ou IPv6 sur l'interface wg0 elle meme. ca évite d'utiliser un /24 ou un /64 et de compliquer le plan d'adressage. Le mieux est de mettre une IPv6 link-local meme si on fait que de l'IPv4 (je mets juste fe80::X/64 ou X =1 , 2, 3 avec un numero par site facile a retenir). L'avantage d'une link-local est de permettre d'utiliser RIPng en IPv6, associé a DHCPv6-PD pour distribuer les /64 sur les peers wg  ca établie tout seul le routage dynamiquement. L’intérêt de mettre des mettre IPv4 et/ou IPv6 sur l'interface wg0 c'est si la machine est elle meme source/destination de traffic et qu'on veut identifier cette interface dans le firewalling par exemple.

- on n'a pas besoin d'ouvrir et figer le port et les IP des 2 cotés. Un seul coté suffit, l'autre peut être 100% dynamique. Il faut juste mettre un persistent keepalive qui maintienne le NAT. J'ai un site central avec une IP fixe et un port fixe . Tout les autres routeurs Openwrt sont sur des sites distants en double nat derriere une box opérateur sans ip public connues et port a ouvrir.

- si on utilise un fqdn pour l' endpoint comme dans ton exemple:  x.dyn.net:51820 , la résolution dns ne sera qu'une seule fois a l'installation et au reboot. il faut mettre un script a intervalle régulier (cron ou timer systemd) pour éventuellement actualiser l'endpoint (via la commande "wg set wg0 peer ... endpoint ...")

- penser a figer le mtu si la route par défaut est le tunnel wg (enlever 80 au mtu du réseau en dessous).
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 16:52:54
Merci pour ces précisons. Visiblement c'était un coup de chance puisque j'ai voulu redémarrer la 2nd VM (lhst) et la connexion est de nouveau impossible...

Je ne savais pas pour les endpoint dynamique que ça ne se faisait qu'une seule fois. Du coup je ferais mieux de faire fonctionner en ipv6 direct vu qu'elle est fixe.

Allez hop c'est reparti pour essayer de faire fonctionner ça pour de bon.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 19:09:57
Ça ne veut toujours pas fonctionner...

# siteA
[Interface]
Address = fe80::1/64
PrivateKey = (hide)
ListenPort = 51820

# siteB
[Peer]
PublicKey = xxxxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
AllowedIPs = 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64, fe80::/64
# siteB
[Interface]
Address = fe80::2/64
PrivateKey = (hide)

# siteA
[Peer]
PublicKey = xxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
Endpoint = 2001:470:1f13:629:x:x:x:x:51820
AllowedIPs = 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64, fe80::/64

root@wgvpnlhst:~# wg
interface: wg0
  public key: xxxxxxgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  private key: (hidden)
  listening port: 57031

peer: xxxxxxWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  endpoint: [2001:470:1f13:629:x:x:x:x]:51820
  allowed ips: 172.16.0.0/24, 192.168.1.0/24, fd63:13cf:cda4::/64, fe80::/64
root@wgvpnlhst:~#
root@wgvpnlpa:~# wg
interface: wg0
  public key: xxxxxxxWWekC8dGl4tfWEqt5SQv5XROvk/2lhndISWc=
  private key: (hidden)
  listening port: 51820

peer: xxxxxxxHgEnOYBAqxMvpK1g8rnCBFuXEpdXkZpnzf2o=
  allowed ips: 172.16.0.0/24, 192.168.2.0/24, fd63:13cf:cdb4::/64, fe80::/64


Et un TCPDUMP sur le routeur ne donne rien, aucun paquet reçu  :(

root@BT-LPA:~# tcpdump -i 6in4-HENET 'port 51820'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 6in4-HENET, link-type RAW (Raw IP), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 20:54:09
Y'a aussi un truc qui me chiffonne :
root@wgvpnlhst:~# ip link add wg0 type wireguard
root@wgvpnlhst:~# wg-quick up wg0
wg-quick: `wg0' already exists

root@wgvpnlhst:~# wg-quick down wg0
[#] ip link delete dev wg0
root@wgvpnlhst:~# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add fe80::2/64 dev wg0
[#] ip link set mtu 1200 up dev wg0
[#] ip route add fe80::/64 dev wg0
RTNETLINK answers: No such device
[#] ip link delete dev wg0
root@wgvpnlhst:~#

Pourquoi ce RTNETLINK answers: No such device à chaque fois ? C'est pénible... alors qu'on voit bien qu'il fait un ip link add au début...

Debian se traîne une version buggée ?

C'est seulement quand je tente un démarrage à la main, s'il se lance avec systemd c'est ok apparemment.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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:

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

> 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).


Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 21:02:25
Y'a aussi un truc qui me chiffonne :
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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 21:05:56
ps - pour voir si le port est en écoute:

ss -uap
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 21:07:34
mtu 1200 ? IPv6 a besoin au minimum de 1280.. marche pas sinon.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 22:02:51
'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:

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

> 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).

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

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

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.

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.

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  ;)
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 17 avril 2019 à 22:12:15
pourquoi pas le choix ? autant faire en IPv4 si les sites n'ont pas IPv6.


Ç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).

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.

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 17 avril 2019 à 22:27:13
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.

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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 00:42:24
Maintenant que ça fonctionne à peu près, occupons nous du routage qui est aussi capricieux :

Site A :
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 :
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).
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
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
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
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 :
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
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
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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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 :

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
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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 :
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 :
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...) :
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:~#

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 

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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 16:35:45
"pppoe-wan" c'est sur quoi  ?

J'avoue ton cas me parait bizarre (et complexe avec les tunnels HE en plus).

si le Pi ne repond pas c'est qu'il n'a peut-etre pas la bonne gateway ?

ou alors y'a des doublons d'adresses/réseaux quelque part.

Le mieux est de capturer de chaque coté du ping pour voir qui ne reçoit/èmet pas., ca indiquera déjà ou est le problème.


Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 17:19:09
pppoe-wan c'est mon IPv4 Orange.

Pour la mauvaise gateway ça me parait peu probable puisqu'il répond bien au ping en local :
renaud@renaud-pc:~$ ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.427 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=0.374 ms
^C
--- 192.168.1.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.374/0.400/0.427/0.021 ms
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 17:21:44
pppoe-wan c'est mon IPv4 Orange.

Pour la mauvaise gateway ça me parait peu probable puisqu'il répond bien au ping en local :
renaud@renaud-pc:~$ ping 192.168.1.10
PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=0.427 ms
64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=0.374 ms
^C
--- 192.168.1.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.374/0.400/0.427/0.021 ms

non justement le ping local n'utilise pas la gateway, il fait une résolution arp.

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 17:31:34
Ah oui exact j'suis fatigué  ;D

root@raspberrypi:~# ip route
default via 192.168.1.1 dev eth0  metric 202
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.10  metric 202

Peut-être le metric en cause ?

Et à propos du Rpi, j'essaie de lui foutre une ipv6 statique, mais il ne la prend pas... Une fois les RA désactivés je n'ai que la link-local et pas celle que j'ai configurée. Pourtant la syntaxe est bonne :

iface eth0 inet6 static
address 2001:470:1f13:629::x
netmask 64
gateway fe80::1a1e:78ff:xxxx:xxd2

J'ai fait la même chose sur le serveur WG d'en face et c'est passé crème, j'ai pu désactiver l'ipv6 pour le reste du réseau. Pas tout capté... Peut-être parce que le système a été installé alors que l'ipv6 était déjà actif ? Ça aurait modifié d'autres paramètres ?

Pourtant j'ai bien le autoconf à 0 pour eth0 :
root@raspberrypi:~# sysctl -a | grep auto
kernel.auto_msgmni = 0
kernel.sched_autogroup_enabled = 1
sysctl: net.ipv4.tcp_autocorking = 1
reading key "net.ipv6.conf.all.stable_secret"
net.ipv6.auto_flowlabels = 1
net.ipv6.conf.all.autoconf = 1
sysctl: reading key "net.ipv6.conf.default.stable_secret"
net.ipv6.conf.default.autoconf = 1
sysctl: reading key "net.ipv6.conf.eth0.stable_secret"
net.ipv6.conf.eth0.autoconf = 0
sysctl: reading key "net.ipv6.conf.lo.stable_secret"
net.ipv6.conf.lo.autoconf = 1
root@raspberrypi:~#


Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 18:39:40
ip -6 link
affichent quoi ?

et y'a plusieurs facon de configurer le réseau, s'il y a un network manager il va prendre le dessus  et ignorer /etc/network/interfaces.

 
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 18:42:58
Pas de network manager dans mon cas.

Pour la commande: 
root@raspberrypi:~# ip -6 link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:xx:xx:xx brd ff:ff:ff:ff:ff:ff

J'ai pendant un instant cru que c'était mon paramétrage pour utiliser des adresses temporaires (net.ipv6.conf.eth0.use_tempaddr = 2), je l'ai viré et redémarré, sans résultat.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 18:58:40
et ip -6 a
c'est quel OS ton Pi ? quelle version ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 19:41:14
C'est raspbian Jessie. Oui je sais qu'il faut que je le mette a jour...

root@raspberrypi:~# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fd63:13cf:cda4:0:a336:b05b:916c:cf9c/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2001:470:1f13:629:xx:xx:xx:xx/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::bb95:8355:c173:f6e8/64 scope link
       valid_lft forever preferred_lft forever

Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 19:43:59
je ne sais si y'avait IPv6 au debut du Pi :p

ip -6 a affiche des link-local ?

edit: ah ben c'est bon alors?
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 19:50:10
et t'as une ULA (fd63:..) sans doute le routeur Openwrt/LEDE qui genere cela: vire la si tu t'en sert pas c'est dans Network/Interface en bas 'IPv6 ULA-Prefix'.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 19:56:05
Oui je sais pour la ULA, mais ça ne résout pas le problème, en gros :

-RA désactivé : je n'ai que la link-local malgré la statique configurée.
-RA activé : J'ai de nouveau la publique autoconf et la ULA.

Sur l'autre serveur WG où tout fonctionne : même avec le RA activé c'est la statique qui prend le dessus (ce qui semble être le comportement normal) :
root@debian:~# ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:470:1f13:381::x/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::d043:3fff:xx:xx/64 scope link
       valid_lft forever preferred_lft forever
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 20:11:20
revoit la conf en entier:

dans /etc/network/interfaces
dans /etc/network/interfaces.d/*

et
grep --color -e autoconf -e accept_ra /etc/sysctl.conf /etc/sysctl.d/*.conf
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 20:21:10
auto lo
iface lo inet loopback

iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 127.0.0.1

iface eth0 inet6 static
address 2001:470:1f13:629::x
netmask 64
gateway fe80::1a1e:78ff:xx:xx

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Je pense pas qu'on puisse faire plus court.

interfaces.d est vide et grep ne me renvoie rien.

Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 20:42:23
met a jour ton OS... ;D
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 20:49:59
Faudra bien de tout façon  ;D

Par contre la micro SD est tellement lente ça va prendre des heures (sans rire la derrière fois que j'ai voulu upgrade c'était horrible)... espérons qu'elle ne meurt pas pendant l'opération. J'en ai pas d'autre sous la main. La pauvre en a vu de toute les couleurs depuis 2009 dans 2 smartphones pour finir dans le RPi, je sais pas comment elle tient encore le choc  :o
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 18 avril 2019 à 21:49:49
Intéressant : En rajoutant auto eth0 mon ip statique est bien prise en compte avec 2 autoconf et 2 ULA (stable + temporaire) alors que ces dernières sont censé être désactivé.

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd63:13cf:cda4:0:a336:b05b:916c:cf9c/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2001:470:1f13:629:xx:xx:xx:xx/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 2001:470:1f13:629::x/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fd63:13cf:cda4:0:ba27:xx:xx:xx/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
    inet6 2001:470:1f13:629:ba27:xx:xx:xx/64 scope global mngtmpaddr dynamic
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:feea:13a9/64 scope link
       valid_lft forever preferred_lft forever
root@raspberrypi:~#

J'ai ensuite testé avec allow-hotplug et là j'ai droit a la statique + autoconf + ULA mais sans les temporaires.

Et sans rien une autoconf + ULA et pas de statique.

C'est quoi ce bintz ?  :o  D'après la doc Debian auto et allow-hotplug sont pas censé influer les ip... juste le moment où elles sont configurées (démarrage, câble branché)...

Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 18 avril 2019 à 23:10:25
il faut de toute facon "auto" si tu veux que ca monte au boot (auto = l'interface sera monter quand "ifup"  est appelé avec l'option -a, ce qui arrive notamment au boot cf "man ifup").

au boot, "ifup -a" est appelé par "/etc/init.d/networking" ou sous systemd par "networking.service" (/lib/systemd/system/networking.service)

"journalctl -b -u networking.service" permet de voir ce qui s'est passé depuis le boot.

Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 19 avril 2019 à 00:10:27
Donc si auto n'est pas présent, l'interface n'est pas censée monter toute seule donc pas d'accès une fois rebooté ?

Bizarre, car jusqu'à présent ça n'y était pas et ça montait bien. Et je n'ai aucun script qui démarre l’interface après coup. Ou alors un service monte l'interface à mon insu ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 19 avril 2019 à 22:43:50
y'a sans doute quelque chose qui monte l'interface oui.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 20 avril 2019 à 01:08:10
Serait-ce le dhcp ou bind, vu qu'il ne sert qu'à ça ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 20 avril 2019 à 01:22:29
Je viens de réessayer en IPv4 et c'est toujours pareil, il faut plusieurs minutes pour que le tunnel monte, je ne comprends vraiment pas pourquoi c'est si long, normalement c'est pas censé être instantané ou presque ?

EDIT : il a fallut 6 minutes à partir du redémarrage de la VM cliente. Tu m'étonnes que la première fois je croyais que ça ne fonctionnait pas.

EDIT2 : En fait c'est fluctuant, un coup ça se connecte immédiatement, un coup il faut attendre plusieurs minutes, mystère...
Titre: VPN Wireguard entre 2 openWRT
Posté par: jeremyp3 le 20 avril 2019 à 03:06:20
bonjour,

j'aimerai bien avoir des éclaircissements sur cette parties:
- on a pas besoin de mettre des IPv4 et/ou IPv6 sur l'interface wg0 elle meme. ca évite d'utiliser un /24 ou un /64 et de compliquer le plan d'adressage. Le mieux est de mettre une IPv6 link-local meme si on fait que de l'IPv4

comment on fait pour avoir une ipv4 si on lui met pas d'ip sur l'interface wg elle même ? j'avoue que c'est une question de N00B, mais ça m'intrigue :) ou alors j'ai pas compris le sens du message, ce qui est bien possible.

Jerem
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 20 avril 2019 à 04:17:13
L'interface wg a bien une ip c'est une link-local ipv6 (fe80). Il n'y a  techniquement pas besoin de plus pour que ça fonctionne.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 20 avril 2019 à 11:02:56
bonjour,

j'aimerai bien avoir des éclaircissements sur cette parties:
comment on fait pour avoir une ipv4 si on lui met pas d'ip sur l'interface wg elle même ? j'avoue que c'est une question de N00B, mais ça m'intrigue :) ou alors j'ai pas compris le sens du message, ce qui est bien possible.

Jerem

y'a pas besoin d'IP coté tunnel car c'est une liaison point a point donc dans le tunnel les 2 extrémités n'ont pas obligatoirement besoin d'addresses pour communiquer car elles n'ont qu'un seul interlocuteur possible.

Un peu comme une petite rue qui relie 2 avenues. Si y'a pas de maison dans la petite rue y'a pas besoin de n° d'adresses, le nom de la petite rue suffit du moment qu'il y'a des numéros dans les 2 avenues:

Pour envoyer une lettre de la maison n°25 avenue 1 a la maison 12 avenue 2 passe par le petite rue.

Tu peux mettre des numéros d'adresses aux extrémités de la petite rue:

Pour envoyer une lettre de la maison n°25 avenue 1 a la maison 12 avenue 2 passe par le n° 1 de la petite rue puis le n°2 de la petite rue.

mais c'est inutile car la petite rue n'a pas de n°3 donc 'est toujours forcement 1->2 dans un sens et 2-1  dans l'autre.

En jargon 'routeur' on appelle la petite rue une "unnumbered interface" .

L'interface wg a bien une ip c'est une link-local ipv6 (fe80). Il n'y a  techniquement pas besoin de plus pour que ça fonctionne.


y'a meme pas besoin de la link-local. c'est juste pour debug et si on veut mettre un protocol de routage dynamique.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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 :
# 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

Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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):

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
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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.

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

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

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


# 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 :

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

Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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  ;D
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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?
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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.
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen 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.

Titre: VPN Wireguard entre 2 openWRT
Posté par: 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 :

/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 ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 21 avril 2019 à 00:45:08
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 :

/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


Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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  ;)
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 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).
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 12 septembre 2019 à 22:15:15
Je crois avoir enfin compris le fonctionnement :

Si j'active le routage :  la communication fonctionne à partir de n'importe quelle machine sauf le serveur et le client (excepté entre les interfaces WG) vers le LAN d'en face
Si j'active le NAT en plus : la communication fonctionne à partir du serveur et du client

Une idée du pourquoi  ? Théoriquement il ne devrait pas y en avoir besoin, si ?
Titre: VPN Wireguard entre 2 openWRT
Posté par: kgersen le 13 septembre 2019 à 02:17:14
ca ressemble typiquement problème de routage de l'adresse source.

un ping (ou n'importe quel trafic bidirectionnel) indique une adresse de retour , si celle-ci est l'adresse d'interface wg elle n'est peut-etre pas joignable depuis le lan distant (quand on ping depuis un routeur, celui utilise l'ip de l'interface de sortie comme adresse source).

Le test à faire c'est avec les options '-S 1.2.3.4' ou '-I eth0' de la commande ping qui permettent de choisir l'interface ou l'IP source.

ou de faire une capture des ping pour voir les valeurs des adresses.
Titre: VPN Wireguard entre 2 openWRT
Posté par: renaud07 le 13 septembre 2019 à 17:42:16
C'était bien ça.

J'ai ajouté une route statique vers 172.16.2.0/24 sur les 2 routeurs et maintenant ça marche sans NAT  :D

Pourquoi j'y ai pas pensé avant...

Encore merci  :)

EDIT  : Pas tout à fait, certains périph's ne sont pas joignables, comme mon point d'accès ou mon switch. Seraient-ils trop vieux pour aller interroger le routeur et savoir la route ? Ou peut-être que ce n'est pas implèmenté ?

J'aussi le soucis avec une machine windows 7, mais là c'est bizarre, il répond bien au ping depuis mon PC mais quand par exemple je veux scanner les ports, nmap ne dit qu'il ne répond pas au ping (idem avec -sP, pas dans la liste) et il faut que j'utilise l'option -Pn, protection du pare-feu ? Donc il pourrait aussi potentiellement refuser le ping d'un autre subnet que le sien ?