# 2 tunnels GRE **URL:** \ **Category:** Support Debian\ **Created:** [Mars 23, 2022, 9:50 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283 "2022-03-23T09:50:44Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 9:50 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/1 "2022-03-23T09:50:44Z")
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 ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 11:44 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/2 "2022-03-23T11:44:12Z")
En gros et t’il possible d’avoir 2 tunnels GRE sur la même IP (GENEVE) qui communique avec PARIS et TOULOUSE. ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Mars 23, 2022, 12:32 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/3 "2022-03-23T12:32:49Z")
> [@Doudou67](#): > > mais pas les 2 en même temps 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. ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Mars 23, 2022, 12:39 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/4 "2022-03-23T12:39:02Z")
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](https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation) Un exemple pour le fichier `/etc/network/interfaces` : ```nohighlight 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 : ```auto xxd -p -l 4 /dev/urandom ``` – AnonymousCoward ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 1:01 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/5 "2022-03-23T13:01:22Z")
J’ai juste ça comme message : link\_config: autonegotiation is unset or enabled, the speed and duplex are not writable ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 1:02 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/6 "2022-03-23T13:02:10Z")
J’ai déjà tester avec key rien n’y fait ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Mars 23, 2022, 1:55 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/7 "2022-03-23T13:55:06Z")
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 ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 2:12 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/8 "2022-03-23T14:12:52Z")
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 ```nohighlight 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 ```bash 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 ``` ```bash 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 ``` ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Mars 23, 2022, 2:44 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/9 "2022-03-23T14:44:49Z")
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 ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 2:56 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/10 "2022-03-23T14:56:23Z")
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 ```bash 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 ``` ```bash 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 ``` ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Mars 23, 2022, 3:02 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/11 "2022-03-23T15:02:02Z")
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 ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 3:10 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/12 "2022-03-23T15:10:51Z")
Le premier lien monte sans surprise et ping, je passe a la 2em conf GENEVE ```nohighlight :~# 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 ```nohighlight :~# 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 ``` ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 23, 2022, 3:15 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/13 "2022-03-23T15:15:56Z")
Vache bien vu c’est les règles 🙂 ```nohighlight :~# 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 ``` ```nohighlight :~# 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 ``` ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 25, 2022, 7:33 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/14 "2022-03-25T07:33:21Z")
Merci encore pour le dépannage AnonymousCoward ça marche a merveille 🙂 Pour info ```nohighlight :~# xxd -p -l 4 /dev/urandom af8cce43 ``` ```nohighlight ip tunnel add gre3 mode gre key af8cce43 local *.*.*.* remote *.*.*.* ttl 255 invalid value for "key": "af8cce43"; it should be an unsigned integer ``` ---
**Author:** ![AnonymousCoward](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f9ae1b/32.png) [@AnonymousCoward](https://www.debian-fr.org/u/AnonymousCoward)\ **Post date:** [Mars 25, 2022, 9:57 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/15 "2022-03-25T09:57:14Z")
Hello, Oui, si tu entre une clé sous forme hexadécimale il faut le préfixe **`0x`**. Par exemple : ```bash 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 ---
**Author:** ![Doudou67](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/d/c5a1d2/32.png) [@Doudou67](https://www.debian-fr.org/u/Doudou67)\ **Post date:** [Mars 25, 2022, 10:53 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/16 "2022-03-25T10:53:43Z")
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 ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Mars 25, 2022, 1:39 UTC](https://www.debian-fr.org/t/2-tunnels-gre/86283/17 "2022-03-25T13:39:06Z")
> [@Doudou67](#): > > ```plaintext > :~# xxd -p -l 4 /dev/urandom > af8cce43 > > ``` 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…