Monter un tunnel VXLAN côté client Linux pour Remote Transit IP

Introduction

VXLAN (Virtual Extensible LAN, RFC 7348) est un encapsulateur L2-over-L3 qui transporte des trames Ethernet dans des paquets UDP. Contrairement à GRE (L3 only), VXLAN peut étendre un domaine de broadcast, mais on l'utilise très souvent comme simple transport L2/L3 pour du transit.

Avantage majeur sur GRE : VXLAN tourne en UDP/4789, donc il passe partout — y compris derrière les box résidentielles qui filtrent IP proto 47. Si Bouygues, Orange, SFR bloquent ton GRE, VXLAN est le plan B avant WireGuard.

Prérequis

• Un serveur Linux avec une IP publique (fixe idéalement, sinon DDNS)
• Le mail technique VeryCloud : PUB_VC, PUB_CLIENT, IPs tunnel (169.254.X.0/30, 2a0e:XXXX:XXXX::/127), VNI (Virtual Network Identifier, ex : 198825)
• Root / sudo
• Kernel récent (4.x+ pour VXLAN dual-stack)

Étape 1 : Vérifier le support VXLAN

sudo modprobe vxlan
lsmod | grep vxlan

Présent par défaut sur Debian, Ubuntu, RHEL récents.

Étape 2 : Créer l'interface VXLAN

VXLAN se configure avec :

• VNI (Virtual Network Identifier) : ID unique du tunnel (24 bits)
• remote : l'endpoint VeryCloud
• local : ton IP publique
• dstport : 4789 (port standard IANA)

sudo ip link add vxlan-vc type vxlan \
    id 198825 \
    remote PUB_VC \
    local PUB_CLIENT \
    dstport 4789 \
    ttl 64

sudo ip link set vxlan-vc up
sudo ip addr add 169.254.X.2/30 dev vxlan-vc
sudo ip -6 addr add 2a0e:XXXX:XXXX::1/127 dev vxlan-vc

💡 id 198825 est un exemple — utilise la VNI fournie par VeryCloud dans le mail technique.

Étape 3 : MTU VXLAN

VXLAN ajoute 50 octets de headers (8 VXLAN + 8 UDP + 20 IPv4 + 14 Ethernet inner). Sur Ethernet MTU=1500, ton MTU effective dans le tunnel est 1450.

sudo ip link set vxlan-vc mtu 1450

MSS clamping :

sudo iptables -t mangle -A FORWARD -o vxlan-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

sudo ip6tables -t mangle -A FORWARD -o vxlan-vc -p tcp --tcp-flags SYN,RST SYN \
    -j TCPMSS --clamp-mss-to-pmtu

⚠️ Si tu transportes du jumbo frame (MTU>1500 entre les deux endpoints), tu peux remonter le MTU côté tunnel à 1500+. Mais le défaut sur Internet reste 1500, donc 1450 dans le tunnel.

Étape 4 : FDB statique (peer learning)

Par défaut VXLAN cherche à apprendre les MACs des peers via multicast — mais ça ne marche pas sur Internet (pas de multicast). Il faut une entrée FDB statique pour dire "le MAC X est joignable via PUB_VC".

VeryCloud te donne en général une seule peer-IP côté backbone. Tu peux faire confiance à la résolution L2 implicite avec remote (étape 2), mais si tu as besoin d'être explicite :

sudo bridge fdb append 00:00:00:00:00:00 dev vxlan-vc dst PUB_VC

L'adresse MAC 00:00:00:00:00:00 signifie "tout MAC inconnu, envoie vers cette destination".

Étape 5 : Tester la connectivité

ping 169.254.X.1
ping6 2a0e:XXXX:XXXX::0

Si ça répond, OK. Si non, dépannage.

Étape 6 : Persistance systemd-networkd

/etc/systemd/network/10-vxlan-vc.netdev :

[NetDev]
Name=vxlan-vc
Kind=vxlan

[VXLAN]
VNI=198825
Remote=PUB_VC
Local=PUB_CLIENT
DestinationPort=4789
TTL=64
MacLearning=no

/etc/systemd/network/10-vxlan-vc.network :

[Match]
Name=vxlan-vc

[Network]
Address=169.254.X.2/30
Address=2a0e:XXXX:XXXX::1/127
LinkLocalAddressing=no

[Link]
MTUBytes=1450

sudo systemctl restart systemd-networkd
networkctl status vxlan-vc

Étape 7 : Persistance Netplan

network:
  version: 2
  tunnels:
    vxlan-vc:
      mode: vxlan
      local: PUB_CLIENT
      remote: PUB_VC
      id: 198825
      port: 4789
      ttl: 64
      mtu: 1450
      mac-learning: false
      addresses:
        - 169.254.X.2/30
        - 2a0e:XXXX:XXXX::1/127

sudo netplan apply

Étape 8 : Préparer pour BGP

Autorise TCP/179 entre les IPs du tunnel :

sudo iptables -A INPUT -p tcp --dport 179 -s 169.254.X.1 -j ACCEPT
sudo iptables -A INPUT -p tcp --sport 179 -s 169.254.X.1 -j ACCEPT

Et lance ton démon BGP avec ces IPs (voir tutos BIRD / FRR).

Étape 9 : VXLAN vs GRE — résumé

Pour du transit pur, GRE reste plus simple si ton FAI le laisse passer. VXLAN gagne quand proto 47 est bloqué.

Dépannage

ping ne fonctionne pas

• Port UDP/4789 bloqué côté firewall (vérifie iptables et règles cloud provider)
• VNI mal renseignée — la VNI doit être identique des deux côtés
• tcpdump -i any udp port 4789 pour voir les paquets

Les paquets arrivent mais le tunnel ne réagit pas

• Mauvais endpoint remote ou local
• Si NAT entre toi et VeryCloud, l'IP source vue côté VeryCloud n'est pas ton local — discute avec le support

Performances dégradées

• Le checksum UDP coûte cher en CPU sur faible-end. Désactive avec udp6zerocsumtx si possible (rare besoin)
• Offload des cartes réseau désactivé (ethtool -K eth0 tx-checksum-ipv4 on)

FDB qui grossit

• Tu as learning yes (défaut) — passe à nolearning pour figer en mode point-à-point :

sudo ip link set vxlan-vc type vxlan nolearning

Commandes utiles

# Voir le détail VXLAN
ip -d link show vxlan-vc

# FDB du VXLAN
bridge fdb show dev vxlan-vc

# Tcpdump sur le port UDP
sudo tcpdump -i eth0 udp port 4789 -nn

# Stats interface
ip -s link show vxlan-vc

# Supprimer
sudo ip link del vxlan-vc

Conclusion

VXLAN sous Linux = ton plan B sur GRE quand ton FAI fait n'importe quoi avec IP proto 47. Quelques commandes, une VNI, et tu retrouves un transport stable pour ta session BGP. MTU et MSS clamping comme pour GRE, et tu es bon.

Pour aller plus loin : WireGuard pour ajouter du chiffrement, BIRD 2 ou FRR pour la session BGP par-dessus.

Ressources

• RFC 7348 — VXLAN
• Linux Kernel — VXLAN documentation
• systemd.netdev — VXLAN section
• Netplan — Tunnel VXLAN