La Fibre
Télécom => Réseau => VPN => Discussion démarrée 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.
-
Bonjour,
Quelle est la question ?
-
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é...
-
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 ?
-
Il n'y a pas de client et de serveur.
Chaque partie doit désigner l'autre avec une directive endpoint + la clé publique.
-
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 ?
-
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.
-
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 >:(
-
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.
-
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'
-
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
-
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)
-
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 ?
-
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).
-
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 :)
-
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.
-
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 ?
-
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 :
-
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.
-
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...
-
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).
-
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.
-
Ç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
-
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.
-
'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).
-
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.
-
ps - pour voir si le port est en écoute:
ss -uap
-
mtu 1200 ? IPv6 a besoin au minimum de 1280.. marche pas sinon.
-
'6in4-HENET' t'as un tunnel Hurricane quelque part ?
Oui, pas le choix.
c'est que du wg-quick les configs?
Yep, j'ai simplement ajouté wg-quick@wg0 au démarrage
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 ;)
-
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.
-
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 :)
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
"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.
-
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
-
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.
-
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:~#
-
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.
-
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.
-
et
ip -6 a
c'est quel OS ton Pi ? quelle version ?
-
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
-
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?
-
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'.
-
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
-
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
-
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.
-
met a jour ton OS... ;D
-
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
-
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é)...
-
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.
-
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 ?
-
y'a sans doute quelque chose qui monte l'interface oui.
-
Serait-ce le dhcp ou bind, vu qu'il ne sert qu'à ça ?
-
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...
-
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
-
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.
-
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.
-
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
-
fais les check de base:
- routage activé la ou il faut? (sysctl net.ipv4.ip_forward)
- vérif les tables de routage
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
-
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
-
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
-
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.
-
c'est dur a suivre à partir des trucs postés avant...
vm serveur site a = wgvpnlhst ? ou est wgvpnlpa?
-
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.
-
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.
-
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 ?
-
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
-
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 ;)
-
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).
-
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 ?
-
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.
-
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 ?