Auteur Sujet: VXLAN par dessus wireguard  (Lu 375 fois)

0 Membres et 1 Invité sur ce sujet

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« le: 04 septembre 2019 à 02:48:22 »
Bonsoir,

Afin de contourner les problèmes de détection de NAT pour mon infra SIP, je me suis mis en tête de mettre en place un VXLAN par dessus wireguard.

J'ai lu un peu de doc (notamment cet article de blog) mais apparemment j'ai dû louper un truc. Résumé :

-Création du VXLAN avec comme IP local-remote celles du tunnel WG : ok
-Attribution d'une IP côté serveur : ok (192.168.3.254)
-Création d'un bridge côté client entre le VLAN SIP et le VXLAN : ok
-Test d'un ping à partir du VLAN SIP vers l'ip serveur : FAIL
-Test en virant le bridge et en attribuant au VXLAN une IP côté client directement : FAIL

Y'a t-il une histoire avec les groupes multicast à rajouter (comme dans cet exemple) ? J'avoue que je n'ai pas bien compris si c'était indispensable ou non.

Voici le /etc/network/interfaces côté client :
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 127.0.0.1 80.10.246.2

auto wg10
iface wg10 inet static
pre-up /sbin/ip link add dev wg10 type wireguard
post-up /usr/bin/wg setconf wg10 /etc/wireguard/wg10.conf
post-down /sbin/ip link del wg10
address 172.16.1.2
netmask 255.255.255.0


iface eth0 inet6 static
address 2001:470:x:x::x
netmask 64
gateway fe80::1a1e:78ff:fe1a:c2d2

auto eth0.10
iface eth0.10 inet manual
#        address 192.168.3.1
#       metmask 255.255.255.0
    vlan-raw-device eth0

auto vxlan10
iface vxlan10 inet manual
    pre-up ip link add vxlan10 type vxlan id 10 local 172.16.1.2 remote 172.16.1.1 dstport 4789
        up ip link set vxlan10 up
        down ip link set vxlan10 down
        post-down ip link del vxlan10
#        address 192.168.3.253
#        netmask 255.255.255.0

auto br0
iface br0 inet manual
    bridge_ports eth0.10 vxlan10

Côté serveur, je me suis contenté pour le moment de le faire manuellement.


renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #1 le: 04 septembre 2019 à 17:31:15 »
Je viens d'essayer avec un groupe multicast, et toujours rien. De même en ajoutant explicitement les @MAC dans la FDB.

Est-ce que la MTU trop basse bloquerait les requêtes (ou juste ça dégrade les perfs) ? Car je ne l'ai pas modifié et par défaut il me la définie à 1370 pour le VX (sachant que WG est à 1420 et le VLAN à 1500).

raf

  • Expert France-IX
  • Expert
  • *
  • Messages: 576
VXLAN par dessus wireguard
« Réponse #2 le: 09 septembre 2019 à 08:02:37 »
L'IP du VTEP, tu dois pas la configurer plutot sur un loopback ? Normalement il faut aussi un IGP, mais avec du routage statique ca deva marcher aussi.
Et a la fin, quand ca ping, fave fun avec le MTU :)

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #3 le: 09 septembre 2019 à 17:02:05 »
Merci pour ta réponse.

Dans les exemples de config que j'ai vu, aucun ne parait de loopback... peut-être que l'implèmentation est différente ?

Je ne trouve rien concernant une config Linux classique (ici une debian). Seulement sur des routeurs genre cisco ou astria... Même la page de doc officielle du kernel ne mentionne pas cette histoire : https://www.kernel.org/doc/Documentation/networking/vxlan.txt

Si ça existe vraiment, un p'tit exemple de conf ne serait pas de refus  ;)

kgersen

  • Client Bouygues FTTH
  • Modérateur
  • *
  • Messages: 6 276
  • FTTH 1Gb/s sur Paris (75)
VXLAN par dessus wireguard
« Réponse #4 le: 09 septembre 2019 à 19:18:28 »
ca marche sans loopback, usuellement on precise l'interface plutôt qu'une IP local.

donc
ip link add vxlan10 type vxlan id 10 dev wg10 remote 172.16.1.1 dstport 4789

après je n'ai jamais fait avec wireguard comme interface de transport (wireguard ne supportant pas le broadcast).

le mieux c'est de tcpdump l'interface wg pour voir ce qu'il se passe.

sinon une bonne lecture qui montre les différentes façon de faire connaitre les VTEPs les uns aux autres: https://vincent.bernat.ch/en/blog/2017-vxlan-linux

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #5 le: 09 septembre 2019 à 20:47:28 »
Ça sent bon  :D

Pour le moment j'ai seulement fait le test en attibuant une IP de chaque côté, à voir en ajoutant le VLAN et le bridge.

root@astwg:~# ping 192.168.4.253
PING 192.168.4.253 (192.168.4.253) 56(84) bytes of data.
64 bytes from 192.168.4.253: icmp_seq=1 ttl=64 time=216 ms
64 bytes from 192.168.4.253: icmp_seq=2 ttl=64 time=108 ms
64 bytes from 192.168.4.253: icmp_seq=3 ttl=64 time=111 ms
64 bytes from 192.168.4.253: icmp_seq=4 ttl=64 time=110 ms
64 bytes from 192.168.4.253: icmp_seq=5 ttl=64 time=112 ms
64 bytes from 192.168.4.253: icmp_seq=6 ttl=64 time=108 ms
64 bytes from 192.168.4.253: icmp_seq=7 ttl=64 time=108 ms
64 bytes from 192.168.4.253: icmp_seq=8 ttl=64 time=111 ms
64 bytes from 192.168.4.253: icmp_seq=9 ttl=64 time=109 ms
64 bytes from 192.168.4.253: icmp_seq=10 ttl=64 time=109 ms
64 bytes from 192.168.4.253: icmp_seq=11 ttl=64 time=107 ms
64 bytes from 192.168.4.253: icmp_seq=12 ttl=64 time=110 ms
^C
--- 192.168.4.253 ping statistics ---
12 packets transmitted, 12 received, 0% packet loss, time 26ms
rtt min/avg/max/mdev = 107.055/118.074/215.504/29.408 ms

Par contre avec cette syntaxe, ça ne monte pas si je le renseigne en dur obligé de le faire à la main après coup... c'est à cause de wg-quick qui se lance après ? Côté serveur par contre, ça marche en renseignant tout dans interfaces (WG et VXLAN).

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #6 le: 09 septembre 2019 à 22:16:59 »
Et c'est... UNE VICTOIRE  8) Merci kgersen, c'était donc la bonne syntaxe.

renaud@renaud-pc:~$ ping 192.168.3.254
PING 192.168.3.254 (192.168.3.254) 56(84) bytes of data.
64 bytes from 192.168.3.254: icmp_seq=1 ttl=64 time=218 ms
64 bytes from 192.168.3.254: icmp_seq=2 ttl=64 time=110 ms
64 bytes from 192.168.3.254: icmp_seq=3 ttl=64 time=108 ms
^C
--- 192.168.3.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 108.830/145.827/218.528/51.410 ms

Tout s'enregistre nickel.

Mais grosse déception, j'ai toujours la détection d'IP foireuse (mélange entre l'ip normale et le VLAN, qui fait que je n'ai pas de son dans un sens ou un raccrochage en règle...) Toute cette mise en place n'aura servi à rien... enfin presque :

J'ai résolu le problème de ping entre les interfaces WG, le coupable est à priori wg-quick, puisque une fois la conf remise dans /etc/network/interfaces côté client ça passe comme par magie.

Je peux enfin interroger le DNS de l'autre LAN et profiter de la résolution des noms de chaque côté  :)

root@raspberrypi:~# ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=108 ms
64 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=107 ms
64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=107 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=107 ms
64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=108 ms
64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=108 ms
64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=107 ms
64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=106 ms
^C
--- 172.16.1.1 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 17ms
rtt min/avg/max/mdev = 105.889/107.197/108.058/0.770 ms
root@raspberrypi:~# ping 172.16.2.1
PING 172.16.2.1 (172.16.2.1) 56(84) bytes of data.
64 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=107 ms
64 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=108 ms
64 bytes from 172.16.2.1: icmp_seq=3 ttl=64 time=140 ms
64 bytes from 172.16.2.1: icmp_seq=4 ttl=64 time=107 ms
64 bytes from 172.16.2.1: icmp_seq=5 ttl=64 time=107 ms
64 bytes from 172.16.2.1: icmp_seq=6 ttl=64 time=107 ms
64 bytes from 172.16.2.1: icmp_seq=7 ttl=64 time=107 ms
^C
--- 172.16.2.1 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 14ms
rtt min/avg/max/mdev = 106.574/111.735/140.094/11.590 ms

Au final voici les confs :

CLIENT :
auto lo
iface lo inet loopback

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

auto wg0
iface wg0 inet static
pre-up /sbin/ip link add dev wg0 type wireguard
post-up /usr/bin/wg setconf wg0 /etc/wireguard/wg0.conf
post-up /sbin/ip route add 192.168.2.0/24 via 172.16.2.2 dev wg0
post-down /sbin/ip link del wg0
address 172.16.2.2
netmask 255.255.255.0

auto wg10
iface wg10 inet static
pre-up /sbin/ip link add dev wg10 type wireguard
post-up /usr/bin/wg setconf wg10 /etc/wireguard/wg10.conf
post-down /sbin/ip link del wg10
address 172.16.1.2
netmask 255.255.255.0

iface eth0 inet6 static
address 2001:x:x:x::x
netmask 64
gateway fe80::1a1e:78ff:fe1a:c2d2

auto eth0.10
iface eth0.10 inet manual
# address 192.168.3.1
# metmask 255.255.255.0
    vlan-raw-device eth0


auto vxlan10
iface vxlan10 inet manual
        pre-up ip link add vxlan10 type vxlan id 10 dev wg10 remote 172.16.1.1 dstport 4789 || true
        up ip link set vxlan10 up
        down ip link set vxlan10 down
        post-down ip link del vxlan10 || true

auto br0
iface br0 inet static
   bridge_ports eth0.10 vxlan10
address 192.168.3.253
netmask 255.255.255.0

SERVEUR :
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet static
address 192.168.2.7
netmask 255.255.255.0
gateway 192.168.2.1

auto wg0
iface wg0 inet static
  pre-up /sbin/ip link add dev wg0 type wireguard
  post-up /usr/bin/wg setconf wg0 /etc/wireguard/wg0.conf
  post-up /sbin/ip route add 192.168.1.0/24 via 172.16.2.1 dev wg0
  post-up iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE
  post-down /sbin/ip link del wg0
  address 172.16.2.1
  netmask 255.255.255.0

auto wg10
iface wg10 inet static
  pre-up /sbin/ip link add dev wg10 type wireguard
  post-up /usr/bin/wg setconf wg10 /etc/wireguard/wg10.conf
  post-down /sbin/ip link del wg10
  address 172.16.1.1
  netmask 255.255.255.0

iface ens18 inet6 static
address 2001:x:x:x::x
netmask 64
gateway fe80::d284:b0ff:fed6:a2ae

auto vxlan10
iface vxlan10 inet static
        pre-up ip link add vxlan10 type vxlan id 10 dev wg10 remote 172.16.1.2 dstport 4789
        up ip link set vxlan10 up
        down ip link set vxlan10 down
        post-down ip link del vxlan10
address 192.168.3.254
netmask 255.255.255.0

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #7 le: 10 septembre 2019 à 20:28:53 »
Citer
Mais grosse déception, j'ai toujours la détection d'IP foireuse (mélange entre l'ip normale et le VLAN, qui fait que je n'ai pas de son dans un sens ou un raccrochage en règle...)

Problème résolu (c'est donc linphone qui chie dans la colle) : https://lafibre.info/serveur-linux/asterisk-et-wireguard-cafouillage-rtp/msg683748/#msg683748

renaud07

  • Client Orange adsl
  • *
  • Messages: 1 906
VXLAN par dessus wireguard
« Réponse #8 le: 18 septembre 2019 à 00:07:48 »
Un petit soucis assez emm***ant :

J'ai voulu repasser sur une config routée pour tester un truc et impossible de faire remonter le VLAN...

J'ai le problème courant du "RTNETLINK answers: File exists", sauf que dans mon cas il ne veut pas partir, j'ai testé :

ip addr flush eth0
puis reboot. Mais rien. Et le pire c'est que l'interface se voit bien attribuer son ip malgré l'erreur. Mais le VLAN refuse à part en forçant (avec --ignore-errors) mais j'ai l’impression que dans ce cas ça bug, et le réseau se coupe au bout d'un moment.

Est-ce que le "file exists" est réellement un fichier de conf quelque part ? On peut pas le supprimer comme on peut le faire avec les .pid quand les services ne veulent pas démarrer ?


 

Mobile View