Auteur Sujet: Configuration / routage tunnel GRE Milkywan (Lu 9532 fois)

maximushugus · « **Réponse #24 le:** 07 février 2021 à 21:14:35 »

oui c'est pour ça que je disais que j'allais essayer de trouver une autre configuration mais pour l'instant la seule qui fonctionne c'est avec la règle SNAT. Je pense que c'est qu'OpenWrt est conçu pour remplacer l'IP source par l'IP de l'interface logicielle elle même, et pas celle d'une autre, et donc je suis obligé de le faire manuellement

kgersen · « **Réponse #25 le:** 07 février 2021 à 21:23:30 »

openwrt n'est qu'un surcouche.

Ce qu'on fait en dessous (niveau linux) marche avec les 2 méthodes donc doit marcher avec les 2 méthodes dans openwrt.

En théorie un snat (ta méthode) en moins performant qu'un hint pour l'adresse source de l'"address selection algorithm" (ma méthode).

bon apres si ca marche comme ca.

et ca reste de l'openwrt, tout est faisable dans openwrt sans passer plus bas niveau.

maximushugus · « **Réponse #26 le:** 07 février 2021 à 21:33:22 »

Oui je pense qu'il y a effectivement moyen que cela me fasse perdre en performance... c'est dommage car pour l'instant je plafonne à 400 Mb/s sur le tunnel, contre 1 Gb/s pour ma connexion FTTH, donc si j'arrive à optimiser ce point, ce serait appréciable.
Je vais reprendre les tests un à un et voir ce que cela donne, mais c'est étrange qu'avec cette configuration, qui est presque là même que la "route" que tu proposais, cela ne fonctionne pas.

Code: [Sélectionner]

config interface 'milkywan'
	option ifname '@tunnelMW'
	option proto 'static'
	option ipaddr 'IPv4MW'
	option netmask '255.255.255.255'
	supprimer -> option gateway '10.1.0.245'

config route 'sortie'
        option interface 'milkywan'
        option target '10.1.0.245'
        option netmask '255.255.255.255'
        option source 'IPv4MW'
        option gateway '10.1.0.245'

Comme je disais, je ne peux pas mettre la "route" exacte que tu me proposais ("target 0.0.0.0 netmask 0.0.0.0") car je pers l'accès au routeur à l'application de cette configuration, qui doit écraser les routes vers le lan etc

Je pense que comme la gateway depuis l'interface "milkywan" est 10.1.0.245 (côté MilkyWan), et que la route correspondante est :

Code: [Sélectionner]

10.1.0.244/30 dev gre4-tunnelMW proto static scope linkalors l'adresse IPv4MW passe par 10.1.0.246 (mon côté de l'interconnexion) et prends alors cette IP comme source.
D'où la nécessité de mettre la règle de SNAT.

Est ce que ta configuration est supposée pallier à ce problème ?

kgersen · « **Réponse #27 le:** 07 février 2021 à 22:07:18 »

en théorie oui je testerais en lab demain.

si tu mets pas 0.0.0.0 ca ne peut marcher. C'est la route par défaut qu'il faut changer pour ajouter un 'src' (coté linux) d'ou l 'option source' (cote openwrt)

si tu perd l'accès au routeur c'est qu'il y a un problème ailleurs. La route par défaut n'impacte pas les routes déduites des configurations des interfaces donc la route vers le lan ne devrait pas etre concerné.

kgersen · « **Réponse #28 le:** 08 février 2021 à 20:25:57 »

apres check SNAT ou MASQUERADE + route src ne sont pas équivalents. car le processus SNAT / MASQUERADE se fait en 'postrouting' donc après que le routing ai changé l'ip source.
Du coup MASQUERADE va rechanger a nouveau avec l'ip src de l'interface d'où le problème avec le tunnel.

Dans ce cas précis de tunnel il faut donc utiliser SNAT.

Apres l'utilisation d'IP privés aux extrémités du tunnel est en pratique inutile et force ici d'utiliser SNAT.

Usuellement on fait de l'unnumbered. Ce qui économise un /30 et rend plus simple la config.

testé en labo avec openwrt :

Code: [Sélectionner]

config interface 'tunnelMW'
        option proto 'gre'
        option ipaddr 'x'
        option peeraddr 'y'

config interface 'intercoMW'
        option proto 'static'
        option ifname '@tunnelMW'
        list ipaddr 'A.B.C.D/32'

config route
        option netmask '0.0.0.0'
        option target '0.0.0.0'
        option interface 'tunnelMW'

et dans le firewall, la zone 'wanMW' option masq a 1 pour activer le NAT (version MASQUERADE).

Code: [Sélectionner]

ip route
default dev gre4-tunnelMW scope link
192.168.1.0/24 dev br-lan scope link  src 192.168.1.2

Nettement plus clean et simple que la config avec IPs sur le tunnel qui oblige à mettre A.B.C.D deux fois (dans network sur une interface et dans firewall pour le SNAT).

après tu peux essayer de ne pas mettre les IP privés du tunnel (10.1.0.246 10.1.0.245), suivant comment c'est configuré a l'autre bout ca peut fonctionner aussi (s'ils ont une route explicite vers 10.1.0.246 ca ne marchera pas mais s'il ont une route vers l'interface tunnel oui, tout dépend de leur protocole de routage et/ou l'IPAM, j'imagine que ce n'est pas fait a la main...).

vivien · « **Réponse #29 le:** 08 février 2021 à 21:05:53 »

Depuis ce matin il n'y a plus de tunnel GRE pour joindre LaFibre.info, je reçois directement l'IPv4 Milkiwan via un lan2lan Rezopole.
Un grand merci à Hugues qui a tout fait.

Je me suis dit que ma configuration précédente, celle avec le tunnel GRE Milkiwan pouvait en intéresser d'autres, si ils sont dans un cas proche du mien.

Dans mon cas j'ai deux interfaces réseaux connectées à deux opérateurs :
- Port em1 : opérateur Adeli qui est utilisé pour le trafic sortant du serveur (envois de mail) et pour le web IPv6. Quand le serveur acéde à internet il utilise ces IPv4 et IPv6.
- Port em2 : opérateur NetSyst qui me servait uniquement pour monter le tunnel GRE. L'IPv4 publique récupérée par le tunnel GRE (80.67.167.77) et utilisée pour l’accès web en IPv4. Elle est réservée pour le trafic entrant.

Pour éviter de consommer des IPv4 publiques pour l'IPv4 réseau, l'IPv4 routeur et l'IPv4 de broadcast, je monte une plage IPv4 privée MilkyWan (10.1.1.60/30).
- IPv4 d’interco côté MilkyWan: 10.1.1.61/30
- IPv4 d’interco coté serveur : 10.1.1.62/30
- Endpoint coté MilkyWan : 80.67.167.26
- IPv4 publique de l'accès internet N°2 (endpoint coté serveur) : 5.182.14.14 (sa passerelle est 5.182.14.1)
- IPv4 publique MilkyWan routée : 80.67.167.77/32 => une seulle IPv4 publique est consommée coté MilkyWan

Voici la confiuration :
sudo nano /etc/network/interfaces
# cat /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # Accès internet N°1 sur port em1, vlan 74, utilisé pour le mail et le web IPv6 auto em1.74 iface em1.74 inet static # IPv4 mail address 46.227.16.8/28 gateway 46.227.16.1 vlan-raw-device em1 iface em1.74 inet6 static # IPv6 mail address 2a01:6e00:10:410::2/64 gateway 2a01:6e00:10:410::1 dns-nameservers 2606:4700:4700::1111 2001:4860:4860::8888 # IPv6 web pre-up ip addr add 2a01:6e00:10:410::1a:f1b2:e/64 dev $IFACE preferred_lft 0 down ip addr del 2a01:6e00:10:410::1a:f1b2:e/64 dev $IFACE preferred_lft 0 # Accès internet N°2 sur port em2, utilisé pour le tunnel GRE Milkywan qui est utilisé pour le web IPv4 auto em2 iface em2 inet static # IPv4 de l'opérateur pour monter tunnel GRE address 5.182.14.14 netmask 255.255.255.240 # gateway 5.182.14.1 post-up ip tunnel add gre1 mode gre remote 80.67.167.26 local 5.182.14.14 ttl 225 post-up ip link set gre1 up post-up ip addr add 10.1.1.62/30 dev gre1 post-up ip addr add 80.67.167.77/32 dev lo post-up ip route add 80.67.167.26/32 via 5.182.14.1 post-up ip route add default via 10.1.1.61 table milkywan post-up ip rule add from 80.67.167.77/32 table milkywan pre-down ip rule del from 80.67.167.77/32 table milkywan pre-down ip route del default via 10.1.1.61 table milkywan pre-down ip route del 80.67.167.26/32 via 5.182.14.1

Il faut déclarer la table milywab dans /etc/iproute2/rt_tables
sudo nano /etc/iproute2/rt_tables

Code: [Sélectionner]

#
# reserved values
#
255	local
254	main
253	default
0	unspec
#
# local
#
#1	inr.ruhep
10	milkywan

Hugues · « **Réponse #30 le:** 08 février 2021 à 21:11:46 »

Merci Vivien ! J'attends tes tests de connectivité avec impatience, tu peux envoyer la sauce, y'a 1G symétriques derrière

kgersen · « **Réponse #31 le:** 08 février 2021 à 21:12:31 »

Citation de: vivien le 08 février 2021 à 21:05:53

Pour éviter de consommer des IPv4 publiques pour l'IPv4 réseau, l'IPv4 routeur et l'IPv4 de broadcast, je monte une plage IPv4 privée MilkyWan (10.1.1.60/30).
- IPv4 d’interco côté MilkyWan: 10.1.1.61/30
- IPv4 d’interco coté serveur : 10.1.1.62/30

oui mais ce n'est pas utile. Il ne devrait pas avoir besoin d'IPv4 pour le tunnel lui-même car c'est du point-a-point.

Hugues · « **Réponse #32 le:** 08 février 2021 à 21:29:46 »

Ca pose des soucis de compatibilité avec certains CPE donc on préfère passer par de l'interco. Ca rend les traceroute plus lisibles en cas de souci également.

maximushugus · « **Réponse #33 le:** 08 février 2021 à 22:29:03 »

Citation de: Hugues le 08 février 2021 à 21:29:46

Ca pose des soucis de compatibilité avec certains CPE donc on préfère passer par de l'interco. Ca rend les traceroute plus lisibles en cas de souci également.

Ok, donc si je comprends bien la configuration postée par kgersen précédemment ne peut pas fonctionner et je suis obligé d'utiliser la configuration actuelle avec le SNAT (qui fonctionne cependant bien).

Hugues · « **Réponse #34 le:** 08 février 2021 à 22:47:54 »

J'en sais rien, perso ça me semble logique de faire du srcnat avec l'ip publique, mais la conf enduser c'est pas ma passion

Et puis en v6 tu conf et ça marche, c'est vachement mieux

maximushugus · « **Réponse #35 le:** 08 février 2021 à 22:51:11 »

Citation de: Hugues le 08 février 2021 à 22:47:54

J'en sais rien, perso ça me semble logique de faire du srcnat avec l'ip publique, mais la conf enduser c'est pas ma passion

Ce qui compte c'est que ça fonction, et c'est le cas, et même super bien. Avec un endpoint à 3ms depuis chez moi, la prochaine étape c'est dans mon salon

Citation de: Hugues le 08 février 2021 à 22:47:54

Et puis en v6 tu conf et ça marche, c'est vachement mieux

C'est clair ! Vivement la démocratisation d'IPv6 de partout et qu'on en finisse avec les NAT