Bonjour,
Petit souci avec les tunnels GRE, impossible de monter 2 tunnels sur la même machine, il manque surement quelque chose.
GRE-PARIS | GRE-GENEVE | GRE-TOULOUSE
Je monte juste PARIS sur GENEVE c’est ok
Je monter juste TOULOUSE sur GENEVE c’est ok
mais pas les 2 en même temps
ip tunnel add geneve mode gre local 22.22.22.22 remote 33.33.33.33 ttl 255
ip addr add 12.18.18.1/30 dev geneve
ip link set geneve up
En gros et t’il possible d’avoir 2 tunnels GRE sur la même IP (GENEVE) qui communique avec PARIS et TOULOUSE.
Si tu dis que les deux ne fonctionnent pas en même temps, c’est que tu as dû constater quelque chose qui te fais arriver à cette conclusion, comme un message d’erreur, par exemple, si tu pouvais le partager, ça nous aiderai.
Je pense que tu devrais vérifier qu’il n’y a pas de collision de ressources entre les deux tunnels, genre des ports utilisés, les sous-réseaux.
Bonjour,
GRE est un protocole de couche 3 (ou 3 1/2) dans le modèle OSI. En conséquence, tu ne peux pas séparer les deux liens en disant que tel lien utilise le port UDP 1000 et un autre lien le port UDP 1001, par exemple.
Il faut donc ajouter un identifiant aux paquets de chaque lien. L’entête GRE permet justement une « clé » sur 32 bits permettant cela.
Voir Wikipedia EN - GRE
Un exemple pour le fichier /etc/network/interfaces :
auto pve2
iface pve2 inet static
address 172.28.25.1
pointopoint 172.28.25.2
mtu 9170
up ip link set $IFACE multicast on
pre-up ip tunnel add $IFACE mode gre local 10.0.0.1 remote 10.0.0.2 key 0x6a5a9d48 dev eth1 ttl 10
post-down ip tunnel del $IFACE
( un lien entre deux serveurs dans un datacenter, ce qui explique la grosse MTU et la faible TTL )
Pour générer une clé aléatoire :
xxd -p -l 4 /dev/urandom
–
AnonymousCoward
J’ai juste ça comme message :
link_config: autonegotiation is unset or enabled, the speed and duplex are not writable
J’ai déjà tester avec key rien n’y fait
On est bien d’accord que chaque lien GRE possède sa propre clé / key, configurée à l’identique aux deux extrémités du lien ?
Il serait pratique de vérifier si les paquets GRE sont effectivement envoyés et/ou reçus en réalisant des captures de paquets réseau.
Est-ce possible ?
–
AnonymousCoward
Oui exactement la même clé pour 2 liens
Sur le premier lien monter j’ai du log il marche correctement
Sur le 2em c’est vide
tcpdump -i gre3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre3, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
Peut importe le sens du montage des liens, c’est toujours le 2em qui ne marche pas
Exemple pour paris geneve
ip tunnel del gre3
ip rule flush table GRE
ip tunnel add gre3 mode gre key 231 local (IP GENEVE) remote (IP PARIS) ttl 255
ip addr add 10.12.0.1/24 dev gre3
ip addr add 10.12.0.3/24 dev gre3
ip addr add 10.12.0.5/24 dev gre3
ip link set gre3 up
ip tunnel del gre3
ip rule flush table TOP
ip tunnel add gre3 mode gre key 231 local (IP PARIS) remote (IP GENEVE) ttl 255
ip addr add 10.12.0.2/24 dev gre3
ip addr add 10.12.0.4/24 dev gre3
ip addr add 10.12.0.6/24 dev gre3
ip link set gre3 up
ip rule add from 10.12.0.0/24 table TOP
ip route add default via 10.12.0.1 table TOP
Il est très probable que le problème vienne de ton utilisation des règles de routage / Policy Based Routing (PBR).
En effet, s’il n’y a pas de trafic entrant dans le tunnel, c’est qu’il y a au moins un problème qui ne vient pas du tunnel.
Il serait conseillé d’essayer la configuration des liens GRE avec une configuration IP la plus simple possible.
S’il ne faut pas perturber le reste du routage parce qu’il y aurait de la production, tu peux te servir d’un espace de noms réseau ( netns ) ou d’un VRF pour cela. Les différents moteurs de recherche fourmillent d’exemples.
–
AnonymousCoward
Merci pour les infos, je n’avait pas connaissance de ( netns )
je vais faire un test avec des conf vraiment de base
un truc genre
ip tunnel add gre2 mode gre local 2.2.2.2 remote 3.3.3.3 ttl 255
ip addr add 192.168.168.1/30 dev gre2
ip link set gre2 up
ip tunnel add gre2 mode gre local 3.3.3.3 remote 2.2.2.2 ttl 255
ip addr add 192.168.168.2/30 dev gre2
ip link set gre2 up
ip rule add from 192.168.168.0/30 table GRE2
ip route add default via 192.168.168.1 table GRE2
En ajoutant une key lors de la création du tunnel GRE, cela devrait le faire.
Dans un premier temps, tu dois pouvoir te passer de l’ajout d’une règle de routage et de l’ajout de la route par défaut.
Pour tester, tu essaie de ping 192.168.168.2 depuis 192.168.168.1 ou vice-versa.
–
AnonymousCoward
Le premier lien monte sans surprise et ping, je passe a la 2em conf
GENEVE
:~# ping 192.168.168.2
PING 192.168.168.2 (192.168.168.2) 56(84) bytes of data.
64 bytes from 192.168.168.2: icmp_seq=1 ttl=64 time=19.4 ms
64 bytes from 192.168.168.2: icmp_seq=2 ttl=64 time=19.7 ms
PARIS
:~# tcpdump -i gre2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre2, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:08:14.640467 IP 192.168.168.1 > 192.168.168.2: ICMP echo request, id 2233, seq 8, length 64
16:08:14.640513 IP 192.168.168.2 > 192.168.168.1: ICMP echo reply, id 2233, seq 8, length 64
Vache bien vu c’est les règles 
:~# ping 192.168.88.2
PING 192.168.88.2 (192.168.88.2) 56(84) bytes of data.
64 bytes from 192.168.88.2: icmp_seq=1 ttl=64 time=20.6 ms
64 bytes from 192.168.88.2: icmp_seq=2 ttl=64 time=21.1 ms
:~# tcpdump -i gre3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gre3, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:13:52.781361 IP 192.168.88.1 > 192.168.88.2: ICMP echo request, id 1816, seq 1, length 64
16:13:52.781406 IP 192.168.88.2 > 192.168.88.1: ICMP echo reply, id 1816, seq 1, length 64
Merci encore pour le dépannage AnonymousCoward ça marche a merveille
Pour info
:~# xxd -p -l 4 /dev/urandom
af8cce43
ip tunnel add gre3 mode gre key af8cce43 local *.*.*.* remote *.*.*.* ttl 255
invalid value for "key": "af8cce43"; it should be an unsigned integer
Hello,
Oui, si tu entre une clé sous forme hexadécimale il faut le préfixe 0x . Par exemple :
ip tunnel add gre3 mode gre key 0xaf8cce43 local ... remote ... ttl 255
A priori, la plupart des commandes qui attendent un nombre entier savent comprendre la forme avec le préfixe.
Sinon, je ne sais s’il y a d’autres questions non résolues mais est-ce que tu saurais nous en dire un peu plus sur la finalité de ce que tu as mis en place ?
Parce-que s’il s’agit de mettre en place un réseau privé comme un VPN entre plusieurs sites, tu n’utilises pas de routage dynamique avec un protocole tel que OSPF ?
–
AnonymousCoward
Merci pour le préfixe.
Pour ma part c’est résolut
Alors pour la mise en place, j’ai plusieurs serveurs avec un nombre limité d’IP publique, avec 2 serveurs d’applicatifs.
Serveurs d’applicatifs (GENEVE)
Les serveurs d’IP sont un peu partout, mais pour l’exemple on garde (PARIS / TOULOUSE)
PARIS > VPN GENEVE
TOULOUSE > VPN GENEVE
Sur GENEVE j’utilise du PROXMOX avec des VM’s, ça me permet d’utiliser directement les vrais IP sur les VM sans aucune conf supplémentaire, si par malheur (GENEVE) bouge, j’ai juste a change les IP de GRE sur les VPN
Alors, personnellement, pour la génération de clefs, je préfère prendre /dev/random comme source. L’aléatoire de /dev/random est de meilleure qualité que celui de /dev/urandom, même si c’est un non-sens de parler de qualité d’aléatoire…