La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: maximushugus le 05 février 2021 à 23:28:57
-
Bonjour, je me permets de poster ici pour que mes problèmes de configuration puissent en aider d'autres à l'avenir.
J'ai pris un tunnel GRE chez Milkywan, avec un /48 IPv6 et une IPv4 publique qui me sont donc fournies.
Ce tunnel à une "endpoint", une IPv4 de MW.
Sur ce tunnel il y a des IP d'interconnexion : IPv4 d'interco côté MilkyWan: 10.1.0.245/30, IPv4 d'interco de ton côté: 10.1.0.246/30
Il y a également des interconnexions via IPv6.
Je cherche à configurer ce tunnel sur mon routeur qui tourne sous OpenWrt : voici la configuration que j'ai pour le moment (fichier /etc/config/network) :
config interface 'tunnelMW'
option proto 'gre'
option peeraddr 'IPv4endpoint'
config interface 'intercoMW'
option proto 'static'
option ifname '@tunnelMW'
option ipaddr '10.1.0.246'
option netmask '255.255.255.252'
Avec cette configuration j'arrive à pinger 10.1.0.245, donc l'interconnexion coté Milkywan, donc le tunnel semble fonctionner.
De plus si je configure une route de 45.13.104.0/22 avec 10.1.0.245, je peux pinger via cette interface/via le tunnel, les IP de Milkywan.
Maintenant je souhaiterais configurer l'IPv4 que me fourni Milkywan.
J'ai donc essayé de rajouter une interface sur mon routeur, en mettant l'IP statique celle fournie par MW et la gateway l'IP d'interconnexion du tunnel coté MW :
config interface 'milkwyan'
option ifname '@tunnelMW'
option proto 'static'
option ipaddr 'IPv4fournieparMW'
option netmask '255.255.252.0'
option gateway '10.1.0.245'
Voici (une partie de) ma table de routage avec cette configuration :
default via 10.1.0.245 dev gre4-tunnelMW proto static
10.1.0.244/30 dev gre4-tunnelMW proto kernel scope link src 10.1.0.246
45.13.104.0/22 dev gre4-tunnelMW proto kernel scope link src IPV4fournieparMW
IPV4del'endpoint via MonIPPublicdemonFAI dev eth0.1 proto static
Mais avec cette configuration, plus rien ne fonctionne. Je ne peux ni pinger internet, ni pinger les IP de 45.13.104.0/22 :
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 10.1.0.245 (10.1.0.245) 10.153 ms 8.822 ms 9.109 ms
2 te4.ccr2004.edge.th2.bb.ip4.milkywan.net (80.67.167.202) 9.063 ms 12.415 ms 9.330 ms
3 tfe1.2983.ccr2004.edge.vnx.bb.ip4.milkywan.net (80.67.167.249) 15.487 ms 18.413 ms 18.424 ms
4 *
Je ne peux pas non plus pinger l'IPv4 que me fourni MilkyWan depuis un autre réseau (mon smartphone en LTE)
Est ce que quelqu'un saurait comme configurer correctement ce tunnel ?
Merci
-
Ajoute l'IPv4 publique sur la loopback, change ton NAT par du srcnat avec comme ip source cette ip publique, et tout marchera :)
-
Ajoute l'IPv4 publique sur la loopback, change ton NAT par du srcnat avec comme ip source cette ip publique, et tout marchera :)
Ok j'essaye ça (faut que je vois exactement comment le faire sur OpenWrt, merci
-
Tu peux garder ton inferface 'milkwyan', c'est le masque (netmask) qui n'est pas bon (de ton coté tu as qu'un IPv4 donc un /32 et pas un /22)
Tu n'est pas forcé de SNAT/masquerade l'ipv4 fournie par MW tout dépend de ton usage.
Si tu as besoin de la partager avec d'autres appareils sur le LAN, il faut effectivement faire du SNAT ou du "masquerade" sur l'interface milkwyan dans la conf firewall.
- soit avec des zones firewall qui référencent des interfaces nommées comme la conf par défaut d'Openwrt ('lan', 'wan') ce qui évite de mettre les IPs en dur dans la config firewall. c'est la méthode plus dans l'esprit d''openwrt'
la config par défaut ( /etc/config/firewall ) contient:
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
C'est la combination "forwarding" + option "masq" qui fait le NAT. en plus ca active le "conn tracking" et permet les flux de retour (statefull firewalling).
si tu as déja une zone 'wan' pour ton accès Internet, tu peux en créer une autre pour ton tunnel (wanMW par exemple), et faire un "config forwarding" de lan a wanMW, tes routes décideront ensuite lequel des 2 forwarding est utilisé (tu peux ainsi partagé ton IPv4 MW pour accéder a une partie d'Internet et ton autre IPv4 public pour une autre partie d'Internet par exemple).
- soit avec un SNAT direct (config redirect)
Mais avant tout je te conseille de lire: https://openwrt.org/docs/guide-user/firewall/firewall_configuration ce n'est pas long et instructif. (rtfm quoi ... )
-
Tu peux garder ton inferface 'milkwyan', c'est le masque (netmask) qui n'est pas bon (de ton coté tu as qu'un IPv4 donc un /32 et pas un /22)
Tu n'est pas forcé de SNAT/masquerade l'ipv4 fournie par MW tout dépend de ton usage.
Si tu as besoin de la partager avec d'autres appareils sur le LAN, il faut effectivement faire du SNAT ou du "masquerade" sur l'interface milkwyan dans la conf firewall.
- soit avec des zones firewall qui référencent des interfaces nommées comme la conf par défaut d'Openwrt ('lan', 'wan') ce qui évite de mettre les IPs en dur dans la config firewall. c'est la méthode plus dans l'esprit d''openwrt'
la config par défaut ( /etc/config/firewall ) contient:
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
C'est la combination "forwarding" + option "masq" qui fait le NAT. en plus ca active le "conn tracking" et permet les flux de retour (statefull firewalling).
si tu as déja une zone 'wan' pour ton accès Internet, tu peux en créer une autre pour ton tunnel (wanMW par exemple), et faire un "config forwarding" de lan a wanMW, tes routes décideront ensuite lequel des 2 forwarding est utilisé (tu peux ainsi partagé ton IPv4 MW pour accéder a une partie d'Internet et ton autre IPv4 public pour une autre partie d'Internet par exemple).
- soit avec un SNAT direct (config redirect)
Mais avant tout je te conseille de lire: https://openwrt.org/docs/guide-user/firewall/firewall_configuration ce n'est pas long et instructif. (rtfm quoi ... )
Tout d'abord merci pour la réponse.
J'avais effectivement fait cette configuration :
Pour /etc/config/network
config interface 'tunnelMW'
option proto 'gre'
option peeraddr 'IPv4endpoint'
config interface 'intercoMW'
option proto 'static'
option ifname '@tunnelMW'
option ipaddr '10.1.0.246'
option netmask '255.255.255.252'
config interface 'milkwyan'
option ifname '@tunnelMW'
option proto 'static'
option ipaddr 'IPv4fournieparMW'
option netmask '255.255.252.0'
option gateway '10.1.0.245'
Pour /etc/config/firewall :
config zone
option network 'intercoMW milkwyan tunnelMW'
option name 'wanMW'
option mtu_fix '1'
option input 'REJECT'
option forward 'REJECT'
option masq '1'
option output 'ACCEPT'
config forwarding
option dest 'wanMW'
option src 'lan'
Néanmoins avec cette configuration, voici (une partie de) la table de routage que j'obtiens :
default via 10.1.0.245 dev gre4-tunnelMW proto static
10.1.0.244/30 dev gre4-tunnelMW proto kernel scope link src 10.1.0.246
à comparer à ma table de routage "de base", avant cette configuration :
default via 10X.XX.XXX.1 dev eth0.1 proto static src 1XX.XX.XXX.7
On voit que "de base", ma route par défaut contient "src MONIPV4PUBLICSFR", alors qu'avec la configuration pour le tunnel ajouté, ma route par défaut ne contient pas "src MONIPV4MW". D'où le fait que mes traceroutes (cf premier message) arrivent sur le réseau MW mais impossible d'en sortir, puisque je doit alors communiquer sur le réseau MW avec l'IP 10.1.0.246, qui n'est pas routable sur internet.
Il faut que j'arrive à rajouter "src MONIPV4MW' dans ma table par défaut à mon avis.
-
Indique ce que tu veux faire avec ce tunnel : faire passer tout le trafic du LAN ou juste une partie ? on ne sait toujours pas ton objectif..
Tu n'as pas corrigé le netmask comme indiqué dans la 1ere ligne de mon commentaire précédent.
option netmask '255.255.255.255' // c'est un /32 ici, il n'y a qu'une seule IP de ton coté
repost toute la config pas que des bouts (du moins le routage et le firewall: /etc/config/network et /etc/config/firewall et la table de routage entiere).
Tu dois explicitement indiquer quelle route par défaut tu veux. Le système de peut pas deviner pour toi et il en faut qu'une (sauf à faire du double wan ce qui n'est pas le but je présume).
Tu peux définir la gateway en dehors des interfaces ,c'est plus clean a mon sens. utilise une 'config route'.
Dns la "config zone" de wanMW il ne faut mettre que l'interface milkwyan pas trois interfaces ...
-
Indique ce que tu veux faire avec ce tunnel : faire passer tout le trafic du LAN ou juste une partie ? on ne sait toujours pas ton objectif..
Pour l'instant je souhaite faire passer l'ensemble du trafic IPv4 dans le tunnel (et lorsque cela fonctionnera je m’attellerai de même de même à l'IPv6
Tu n'as pas corrigé le netmask comme indiqué dans la 1ere ligne de mon commentaire précédent
En fait si, c'est juste que j'avais fait un copier coller de la config postée à la permière page par flemme de remodifier/masquer les IP et j'ai oublié de modifier le netmask mais c'était bien fait ;)
Dans la "config zone" de wanMW il ne faut mettre que l'interface milkwyan pas trois interfaces ...
Ok je corrige ça
-
reposte toute la config pas que des bouts (du moins le routage et le firewall: /etc/config/network et /etc/config/firewall et la table de routage entiere).
Voici donc la configuration complète :
/etc/config/network (je n'ai pas mis mes interfaces IOT et invité etc.. :
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'lan'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.3.1'
option ifname 'eth0.3'
option igmp_snooping '1'
option ip6hint '3'
option ip6assign '64'
config interface 'wan'
option proto 'dhcp'
option vendorid 'neufbox_NB6VAC-XXXXXXXXX'
option peerdns '0'
option ifname 'eth0.1'
option metric '0'
config interface 'wan6'
option ifname 'eth0.1'
option proto 'dhcpv6'
option reqprefix 'auto'
option reqaddress 'try'
option peerdns '0'
config interface 'tunnelMW'
option proto 'gre'
option peeraddr 'IPV4endpoint'
config interface 'intercoMW'
option proto 'static'
option ifname '@tunnelMW'
option ipaddr '10.1.0.246'
option netmask '255.255.255.252'
config interface 'milkywan'
option ifname '@tunnelMW'
option proto 'static'
option ipaddr 'IPv4MW'
option netmask '255.255.255.255'
option gateway '10.1.0.245'
/etc/config/firewall :
config defaults
option syn_flood '1'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option flow_offloading '1'
option flow_offloading_hw '1'
option drop_invalid '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
option network 'lan'
config zone
option name 'wan'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
option input 'REJECT'
option network 'wan wan6'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config include
option path '/etc/firewall.user'
config forwarding
option dest 'wan'
option src 'lan'
config zone
option network 'milkwyan'
option name 'wanMW'
option mtu_fix '1'
option input 'REJECT'
option forward 'REJECT'
option masq '1'
option output 'ACCEPT'
config forwarding
option dest 'wanMW'
option src 'lan'
Avec cette configuration, voici la table de routage que j'obtiens :
default via 10.1.0.245 dev gre4-tunnelMW proto static
10.1.0.244/30 dev gre4-tunnelMW proto kernel scope link src 10.1.0.246
IPV4endpoint via 1XX.XX.XXX.1 dev eth0.1 proto static
1XX.XX.XXX.0/24 dev eth0.1 proto kernel scope link src 1XX.XX.XXX.X (mon IPV4SFR)
192.168.3.0/24 dev br-lan proto kernel scope link src 192.168.3.1
J'ai donc essayé de définir ma route par défaut avec :
ip route change default via 10.1.0.245 dev gre4-tunnelMW proto static src IPv4MW
J'obtiens alors :
default via 10.1.0.245 dev gre4-tunnelMW proto static src IPV4MW
10.1.0.244/30 dev gre4-tunnelMW proto kernel scope link src 10.1.0.246
IPV4endpoint via 1XX.XX.XXX.1 dev eth0.1 proto static
1XX.XX.XXX.0/24 dev eth0.1 proto kernel scope link src 1XX.XX.XXX.X (mon IPV4SFR)
192.168.3.0/24 dev br-lan proto kernel scope link src 192.168.3.1
Mais cette fois ci je n'arrive plus à pinger quoi que ce soit
-
Bon, j'ai fait pas mal de tests et je ne comprends pas.
J'ai bien ma route par défaut vers 10.1.0.245, c'est à dire l'IP de l'interconnexion côté Milkywan puisque, avec la configuration donnée ci dessus (sans la modification / définition de route dont je parlais à la fin du dernier message), lorsque le fait un traceroute vers internet (8.8.8.8 ), j'obtiens ceci :
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 10.1.0.245 (10.1.0.245) 8.273 ms 9.343 ms 8.834 ms
2 te4.ccr2004.edge.th2.bb.ip4.milkywan.net (80.67.167.202) 9.032 ms 8.057 ms 9.107 ms
3 tfe1.2983.ccr2004.edge.vnx.bb.ip4.milkywan.net (80.67.167.249) 15.965 ms 17.432 ms 18.474 ms
4 * * *
5 * * *Donc je passe bien par le réseau Milkywan mais je ne peux en sortir. En effet, l'IP qui contacte l'interconnexion coté milkywan (10.1.0.245) est l'IP de l'interconnexion de mon coté, à savoir 10.1.0.246. J'ai des captures Wireshark de l'interface du tunnel GRE sur mon routeur qui montrent bien ça (à savoir des packets de source 10.1.0.246 à destination de 8.8.8.8) lorsque je fais ce traceroute.
J'ai donc mis en place une règle SNAT, convertissant l'adresse 10.1.0.246 (l'interconnexion de mon coté) en l'adresse IPv4 publique que me fournit Milkywan. Lorsque je fais le même traceroute vers 8.8.8.8, sans changer ma table de routage, qui oriente donc vers 10.1.0.245 (l'interconnexion du tunnel GRE coté Milkywan), je vois bien sur mes capture Wireshark que la source du packet a changé, et est cette fois bien devenu l'IPv4 publique (fournie par Milkywan). Néanmoins je ne passe pas plus loin que l'interconnexion du tunnel côté Milkywan pas et le résultat du traceroute est :
traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
1 10.1.0.245 (10.1.0.245) 9.895 ms 9.257 ms 8.787 ms
2 * * *
3 * * *
4 * * *
Je ne comprends pas d'où vient le problème...
PS : je peux si besoin fournir les captures Wireshark
-
Tu peux me mail ou venir sur IRC ? On va faire des tests synchro :)
-
Oui je fais ça tout de suite merci :)
-
Cherches-tu a apprendre OpenWrt et faire la config toi-meme ou tu cherches juste une config tout faite sans comprendre comment elle marche ? si c'est le 2eme cas, demande a MW une config tout faite tu es leur client apres tout et ca sera plus simple pour toi.
si t'es dans le premier cas:
- attention ta zone firewall 'wanMW' bloque les entrées: met ACCEPT pour input et forward pour le moment (plus tard quand ca marchera tu peux renforcé la sécurité en faisant des regles comme pour "wan" ou intégré ton tunnel dans 'wan' mais en faisant attention)
- mélange pas les commandes openwrt et linux("ip route"). openwrt est une surcouche qui derrière utilise les commandes linux donc il faut mieux travailler a un seul niveau.
- pinger depuis le routeur ou depuis un appareil sur le lan n'implique pas les memes mécanismes. Dans un cas il y a translation d'adresse avec suivi (conntrack) , dans l'autre c'est via en changeant/spécifiant l'adresse source.
Dans ton cas, si tu veux pinger des 2:
- enleve "option gateway" dans l' interface et definit la gateway directement:
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 '0.0.0.0'
option netmask '0.0.0.0'
option source 'IPv4MW'
option gateway '10.1.0.245'
la 'config route' revient à faire un "ip route ..." mais au niveau openwrt pas au niveau en dessous.
une fois que ca marche (local et lan) tu peux remettre les REJECT dans la config firewall de la zone wanMW ou fusionner le tout dans une seule zone 'wan' (je recommande pas trop mais si c'est possible).
edit: ma réponse a croisé celle de Hugues, du coup vois avec lui ca sera plus simple.
-
On n'a pas de conf toute faite pour OpenWRT, donc vaut mieux qu'il apprenne à pécher plutôt qu'on lui donne un poisson, mais je peux aiguiller pour dire pourquoi ça ne marche pas :)
-
Oui tant qu'à faire je préfère comprendre ;)
-
Voici, pour information, ma configuration qui fonctionne pour monter le tunnel GRE avec un bloc /48 d'IPv6 et une IPv4 publique fournie par MilkyWan sur un routeur OpenWrt, si cela peut aider des gens ultérieurement :
/etc/config/network :
config interface 'tunnelMW'
option proto 'gre'
option peeraddr 'IPendpoint'
option mtu '1476' #MTU de 1476 car je suis sur un tunnel GRE (pas GRE6) depuis une ligne FTTH de MTU 1500 donc 1500 - 20 (protocole IPv4) - 4 protocole GRE = 1476
config interface 'intercoMW'
option proto 'static'
option ifname '@tunnelMW'
option ipaddr '10.1.0.246' #IPv4 de l'interconnexion du tunnel GRE coté client
option netmask '255.255.255.252'
list ip6addr '2a0b:cbc0:x::xxx/126' #IPv6 de l'interconnexion du tunnel GRE côté client
option mtu '1476' #MTU de 1476 car je suis sur un tunnel GRE (pas GRE6) depuis une ligne FTTH de MTU 1500 donc 1500 - 20 (protocole IPv4) - 4 protocole GRE = 1476
config interface 'milkywan'
option proto 'static'
option ipaddr 'IPv4MW' #si vous avez une IPv4 fournie par MW
option netmask '255.255.255.255' #si vous avez une IPv4 fournie par MW
option gateway '10.1.0.245' #si vous avez une IPv4 fournie par MW
option ifname '@tunnelMW'
option ip6prefix '2a0e:e70x:xxx::/48' # bloc d'IPv6 fourni par MW
option ip6gw '2a0b:cbc0:x::xxx' #IPv6 de l'interconnexion du tunnel GRE côté client
list ip6addr '2a0e:e70x:xxx::x/64' #une IPv6 parmi le bloc /48 qui sera celle du routeur sur son interface milkywan
option mtu '1476' #MTU de 1476 car je suis sur un tunnel GRE (pas GRE6) depuis une ligne FTTH de MTU 1500 donc 1500 - 20 (protocole IPv4) - 4 protocole GRE = 1476
/etc/config/firewall :
config zone #paramètre de la zone milkywan
option forward 'REJECT'
option name 'milkywan'
option output 'ACCEPT'
option input 'REJECT'
option network 'intercoMW milkywan tunnelMW'
config forwarding #autoriser le transfère de la zone lan vers la zone milkywan
option dest 'milkywan'
option src 'lan'
config nat #si vous avez une IPv4 fournie par MW : ce SNAT sers à transformer l'IP d'interconnexion en l'IPv4 fournie par MW, car cette dernière est rootable sur internet contrairement à celle d'interconnexion
option src 'milkywan'
option name 'milkywan'
option target 'SNAT'
option snat_ip 'IPv4MW'
list proto 'all'
-
Dans ton cas, si tu veux pinger des 2:
- enleve "option gateway" dans l' interface et definit la gateway directement:
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 '0.0.0.0'
option netmask '0.0.0.0'
option source 'IPv4MW'
option gateway '10.1.0.245'
Si je mets en place cette route, je perds l'accès à mon routeur (et à internet par ailleurs) et je dois reset mon routeur : je pense que cette route écrase les routes pour les interfaces "lan" "wan" etc.
Je vais essayer de faire une configuration plus "propre" que celle que j'ai faite sur le message précédent.
Merci tous les 2 pour l'aide en tout cas :)
-
J'ai testé avec cette configuration pour retirer la règle de SNAT dans le firewall:
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'
Mais cela ne fonctionne pas : les packets doivent passer de l'interface "milkywan" à interface "intercoMW" pour atteindre 10.1.0.245. Donc les packets sortent du tunnel en direction du réseau MW avec l'IP de l'interconnexion de mon coté, à savoir 10.1.0.246, qui n'est pas routable sur internet, donc je n'ai accès que réseau de MW mais pas plus loin.
Je suis donc obligé de laisser la règle de SNAT telle que décrite plus haut.
En effet je pense que les règle de masquage / masquerade sont faites remplacer l'IP d'un client (d'un réseau lan) par l'IP du routeur sur la pâte de son interface WAN. Or dans mon cas, l'interface "milkywan" passe par une gateway qui l'oblige à sortir par l'interface "intercoMW" et donc de sortir avec 10.1.0.246 quel que soit les règles de mascage / masquerade sur les interfaces "milkywan" et "intercoMW"
Si quelqu'un a une méthode plus propre que ce que j'ai mis en place je suis preneur, car je n'en vois pas d'autres actuellement.
-
ce n'est pas clair ce qui marche/ marche pas ...
tu parle du routeur ou des équipements sur le LAN ?
J'ai testé avec cette configuration pour retirer la règle de SNAT dans le firewall:
qu'appele tu la "règle de SNAT dans le firewall" ?
les packets doivent passer de l'interface "milkywan" à interface "intercoMW" pour atteindre 10.1.0.245
tu n'a pas 3 interfaces. il y en a qu'une. les 2 autres sont des "alias", notion propre a OpenWrt.
la commande "ip a" permet de voir les interfaces. tu verras surement une interface seule a 3 IP différents (ou 2 si l'interface de base n'a pas d'IP définie). on ne peut router d'une interface a elle meme (faire passer les paquets d'une interface a elle meme).
par contre on peut éventuellement changer les ip sources ou destination quand on sort/entre d'une interface.
la table de routage (ip route) affiche l'ip source utilisée suivant la destination.
exemple:
routeur: 192.168.1.1
PC: 192.168.1.2
default via 10.1.0.245 dev tunnel src A.B.C.D
10.1.0.244/30 dev tunnel scope link src 10.1.0.246
192.168.1.0/24 dev lan scope link src 192.168.1.1
la route par défaut sort par 10.1.0.245 mais prend A.B.C.D comme adresse source quand c'est le routeur qui émet le trafic. si le routeur ne fait que router il ne touche pas a l'adresse source. Sans le 'option source A.B.C.D' (= "src A.B.C.D" dans la route par défaut) le routeur utilise son adresse sur l'interface pour sortir donc 10.1.0.246 dans ce cas.
Donc PC sort avec son IP. comme celle-ci est privée il faut faire du masquerade (statefull NAT) pour sortie sur le Net.
Si le masquerade (NAT) n'utilise pas A.B.C.D en sortie c'est qu'il y a un souci de configuration (ou une limitation d'OpenWrt) ?
que donne "iptables -S" et "iptables -L" ?
tu peux tracer le NAT en faisant:
ping -W 1 -c 1 1.1.1.1
cat /proc/net/nf_conntrack | grep 1.1.1.1
puis de même depuis un PC (que le ping bien sur, le cat .. sur le routeur) pour voir la différence.
ca devrait donné une indication d'où ca cloche.
-
ce n'est pas clair ce qui marche/ marche pas ...
tu parle du routeur ou des équipements sur le LAN ?
Avec la configuration seule, que j'avais mise dans mon dernier message, je ne peux pas ping internet que ce soit directement depuis le routeur ou via les client LAN.
qu'appele tu la "règle de SNAT dans le firewall" ?
Il s'agit de cette règle, qui fait fonctionner le tunnel vers internet :
config nat
option src 'milkywan'
option name 'milkywan'
option target 'SNAT'
option snat_ip 'IPv4MW'
list proto 'all'
Si le masquerade (NAT) n'utilise pas A.B.C.D en sortie c'est qu'il y a un souci de configuration (ou une limitation d'OpenWrt) ?
J'ai bien l'impression que c'est le problème, que l'option masquerade soit activée ou non... De base avec la configuration que j'ai :
default via 10.1.0.245 dev gre4-tunnelMW proto staticDonc sans le "src A.B.C.D" qui donnerait mon IPv4MW.
Lorsque je le rajoute via la commande
ip route change default via 10.1.0.245 dev gre4-tunnelMW proto static src A.B.C.D
ip route flush cacheAlors j'ai bien
default via 10.1.0.245 dev gre4-tunnelMW proto static src A.B.C.Dcomme je le souhaite mais je ne peux toujours ping que le réseaux de MW et pas plus loin, pas internet. D'ailleurs avec cette route, si je fais une capture Wireshark de l'interface "gre4-tunnelMW", je vois bien que mes ping sortent toujours avec l'adresse source 10.1.0.246. C'est pour ça que je suis obligé de mettre en place la règle de SNAT citée précédement, qui corrige cela, et qui me permet d'accéder au net.
-
Pour information voici mon "iptables -S" (non filtré, avc mes zones invités, IOT etc)
https://hastebin.milkywan.fr/irufokariq.sql (https://hastebin.milkywan.fr/irufokariq.sql)
et mon iptables -L :
https://hastebin.milkywan.fr/guloyaqudo.sql (https://hastebin.milkywan.fr/guloyaqudo.sql)
Pour les tests j'essayerai de les faire plus tard
-
En faisant un ping sur 8.8.8.8 directement depuis le routeur, avec ma règle SNAT désactivée, j'obtiens :
root@router:~# cat /proc/net/nf_conntrack | grep 8.8.8.8
ipv4 2 icmp 1 28 src=10.1.0.246 dst=8.8.8.8 type=8 code=0 id=50717 packets=1 bytes=84 src=8.8.8.8 dst=10.1.0.246 type=0 code=0 id=50717 packets=1 bytes=84 mark=0 zone=0 use=2
et j'ai le même résultat avec la règle de masquerade activée ou désactivée sur la zone milkywan
Même résultats en lançant le ping depuis un appareil du lan
En revanche dès que j'active la règle SNAT citée précédemment (avec masquerade activé comme désactivé) :
root@routeur:~# cat /proc/net/nf_conntrack | grep 8.8.8.8
ipv4 2 icmp 1 28 src=10.1.0.246 dst=8.8.8.8 type=8 code=0 id=19742 packets=1 bytes=84 src=8.8.8.8 dst=IPv4MW type=0 code=0 id=19742 packets=1 bytes=84 mark=0 zone=0 use=2
-
oui donc ca marche ou pas ? c'est la ou ce n'est pas clair. ;D
-
ah, oui avec la configuration que j'ai publiée avec la règle SNAT, cela fonctionne 😅. Mais c'est juste que c'est une solution pas classique. Je pense qu'OpenWrt n'est pas fait pour passer une IPv4 publique sur un tunnel, et du coup il faut cette solution un peu bricolage
-
par contre pourquoi le SNAT marche et pas le "config route" ... c'est ca qui m'échappe.
-
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
-
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.
-
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.
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 :
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 ?
-
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é.
-
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 :
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).
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...).
-
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
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep
10 milkywan
-
Merci Vivien ! J'attends tes tests de connectivité avec impatience, tu peux envoyer la sauce, y'a 1G symétriques derrière :D
-
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.
-
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.
-
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).
-
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
-
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 :)
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
-
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.
Est ce qu'on pourrait avoir un peu plus de détails sur cette configuration, par curiosité, si ce n'est pas indiscret ou dangereux sur le plan sécurité ?
C'est une connexion physique directe ? Cela implique l'hébergement sur une serveur Milkywan ?
-
Rien de spécial, y'a un L2 entre MilkyWan et le serveur de Lafibre.info :)
-
Le LyonIX (qui a depuis fusionné avec Rezopole) est présent au Maxnod et ils ont mis un lan2lan entre Maxnod (le switch de NetSyst) et le Netcenter SFR (où Milkywan est présent).
Sur mon serveur l'interface N°1 est connecté à Adeli et l'interface N°2 est connecté à NetSyst où je récupère uniquement l'IPv4 et IPv6 Milkywan.