La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: devianur le 25 mai 2022 à 18:16:36
-
Bonjour,
J'ai pris récemment un tunnel GRE chez MW afin d'avoir un reverse dns pour mon serveur mail. Pour l'instant ce dernier est toujours sur un vpn fdn mais openvpn prend un peu trop de ressources cpu à mon goût.
J'ai créé un network namespace (que je nomme mw) pour y faire tourner mon serveur mail sans les autres programmes, jusque là c'est bon, lorsque je fais
ip netns exec mw curl ipinfo.io
Il me retourne bien l'adresse ipv4 publique du tunnel chez MW.
Cependant le débit est très bas, un speedtest me donne 2528.47 ms et 2 à 3Mbits lorsqu'un speedtest sans le tunnel me donne 500Mbits
Je suis chez Free avec une box mini 4K avec un dmz pointant sur mon serveur.
Voici le résultat des commandes ip a et ip route:
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 45.13.104.95/32 scope global lo
valid_lft forever preferred_lft forever
inet6 2a0e:e701:11ce::1/128 scope global
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 7e:9b:8d:f6:a9:1b brd ff:ff:ff:ff:ff:ff
inet 192.168.1.176/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::7c9b:8dff:fef6:a91b/64 scope link
valid_lft forever preferred_lft forever
3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
ip route
default via 192.168.1.1 dev eth0 onlink
169.254.0.0/16 dev eth0 scope link metric 1000
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.176
et pour le network namespace:
ip netns exec mw ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 45.13.104.95/32 scope global lo
valid_lft forever preferred_lft forever
inet6 2a0e:e701:11ce::1/128 scope global
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
4: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000
link/gre 192.168.1.176 peer 80.67.167.26 link-netnsid 0
inet 10.1.1.82/30 scope global gre1
valid_lft forever preferred_lft forever
inet6 2a0b:cbc0:1::1fa/126 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c0a8:1b0/64 scope link
valid_lft forever preferred_lft forever
ip netns exec mw ip route
default via 10.1.1.81 dev gre1 src 45.13.104.95
10.1.1.80/30 dev gre1 proto kernel scope link src 10.1.1.82
Est-ce que quelque chose cloche dans ma configuration ? ???
-
:o
Je précise que c'est la première fois que je mets en place ce genre de configuration.
Voici la procédure que j'ai effectué:
ip netns add mw
ip netns exec mw ip link set dev lo up
ip link set gre1 netns mw
ip netns exec mw ip tunnel add gre1 mode gre remote 80.67.167.26 local 192.168.1.176 ttl 255
ip netns exec mw ip link set gre1 up
ip netns exec mw ip addr add 10.1.1.82/30 dev gre1
ip netns exec mw ip addr add 45.13.104.95/32 dev lo
ip netns exec mw ip -6 addr add 2a0b:cbc0:1::1fa/126 dev gre1
ip netns exec mw ip -6 addr add 2a0e:e701:11ce::1/128 dev lo
ip netns exec mw ip route replace default via 10.1.1.81 src 45.13.104.95
ip netns exec mw ip route add 80.67.167.26/32 via 192.168.1.1
ip netns exec mw ip -6 route replace default via 2a0b:cbc0:1::1f9 src 2a0e:e701:11ce::1
-
J'ai du faire de la modération (!)
Les messages sans lien avec la problématique ou visant à faire polémique seront supprimés.
Vivien.
-
J'ai du faire de la modération (!)
Les messages sans lien avec la problématique ou visant à faire polémique seront supprimés.
Vivien.
C'est chez Milkywan, c'est à Milkywan de résoudre les problèmes de ses clients.
-
Hello
Ton problème me rappelle un problème de MTU où le paquet GRE peut se faire fragmenter au niveau du transport, provoquant des chutes dramatiques de débit. T'es en ZMD Free (avec le tunnel 4rd IPv4) ?
Je te propose de tester ton MTU jusqu'à MW avec ping -M do -s 1472 80.67.167.26.
-Pingex
-
Et moi j'ajoute un souci de MSS à résoudre avec une commande iptables qui va bien :
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss 1436
à adapter avec les bonnes interfaces, à voir ce qu'en pense le namespace, je n'utilise pas ça.
-
Si cela ne choque personne de comment est monté le tunnel tout vas bien.
Avec le MASQUERADE , cela va tomber en marche.
C'est très bien d'utiliser le namespace, ce qui était implémenté au niveau des tables remonte au namespace.
C'est l'évolution naturelle.
-
Cependant le débit est très bas, un speedtest me donne 2528.47 ms et 2 à 3Mbits lorsqu'un speedtest sans le tunnel me donne 500Mbits
Pour la bonne forme, peux-tu confirmer ta méthodologie de mesure ? Perso je recommande iperf3 vers une cible réputée, par exemple (imo) ping.online.net (http://ping.online.net/).
Si t'as une DMZ, ça devrait suffire pour que le tunnel monte. Sinon, forwarder le proto 47 vers ta boîte Linux si la fbx le permet. Mais vu que ça semble passer, même de manière dégradée, pour moi il n'y a donc pas de sujet de NAT outer. Autrement, peux-tu confirmer que tu as un ping raisonnable en testant vers 10.1.1.81 dans ton netns ?
Et moi j'ajoute un souci de MSS à résoudre avec une commande iptables qui va bien :
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss 1436
à adapter avec les bonnes interfaces, à voir ce qu'en pense le namespace, je n'utilise pas ça.
Afin d'éviter toute confusion, la règle est à appliquer dans ton cas sur gre0, et non sur eth0. La table mangle n'agit pas sur le trafic encapsulé dans un protocole de tunnel, il faut donc cibler l'interface tunnel pour agir sur le trafic contenu dans ce dernier.
-Pingex
-
Merci pour vos réponses, je suis en train de faire pas mal de test.
En fait je me demande comment mon namespace a pu marcher vu qu'à priori il n'avait pas accès à l'interface physique eth0.
J'ai fait un iperf avec gre sans namespace et j'obtiens environ 90Mbits, ce qui est déjà bien mieux mais pourquoi une telle baisse de débit par rapport à un iperf sans gre qui me donne 380Mbits.
Je vais mettre en clair les résultats un peu plus tard.
-
Essaie en corrigeant la MSS :)
-
Essaie en corrigeant la MSS :)
Comment calculer la bonne valeur du MSS ? si j'utilise 1436 et que je fais un iperf, il répond de temps en temps (en utilisant gre sans namespace)
iperf3: error - unable to send control message: Broken pipeou
iperf3: error - unable to send control message: Connection reset by peer
Et parfois il fait le speedtest correctement.
-
MTU - 40 :)
La MTU du tunnel GRE étant de 1476, tu as la bonne valeur.
-
Bon alors j'ai changé la manière donc je créé le namespace en utilisant ce script: https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99
Voici donc la procédure depuis le début pour ne rien manquer:
iperf3 -c ping.online.net -p 5200
Connecting to host ping.online.net, port 5200
[ 5] local 192.168.1.176 port 50290 connected to 62.210.18.40 port 5200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 40.1 MBytes 336 Mbits/sec 106 539 KBytes
[ 5] 1.00-2.00 sec 43.8 MBytes 367 Mbits/sec 0 643 KBytes
[ 5] 2.00-3.00 sec 32.5 MBytes 273 Mbits/sec 7 407 KBytes
[ 5] 3.00-4.00 sec 33.8 MBytes 283 Mbits/sec 0 513 KBytes
[ 5] 4.00-5.00 sec 41.2 MBytes 346 Mbits/sec 0 619 KBytes
[ 5] 5.00-6.00 sec 47.5 MBytes 399 Mbits/sec 0 718 KBytes
[ 5] 6.00-7.00 sec 55.0 MBytes 461 Mbits/sec 0 822 KBytes
[ 5] 7.00-8.00 sec 56.2 MBytes 472 Mbits/sec 2 475 KBytes
[ 5] 8.00-9.00 sec 38.8 MBytes 325 Mbits/sec 0 580 KBytes
[ 5] 9.00-10.00 sec 45.0 MBytes 378 Mbits/sec 0 682 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 434 MBytes 364 Mbits/sec 115 sender
[ 5] 0.00-10.00 sec 431 MBytes 362 Mbits/sec receiver
iperf Done.
./net-ns eth0
(je suis maintenant dans un shell dans le namespace)
ip tunnel add gre1 mode gre remote 80.67.167.26 local 10.200.1.2 ttl 255
ip link set gre1 up
ip addr add 10.1.1.82/30 dev gre1
ip addr add 45.13.104.95/32 dev lo
ip -6 addr add 2a0b:cbc0:1::1fa/126 dev gre1
ip -6 addr add 2a0e:e701:11ce::1/128 dev lo
ip route replace default via 10.1.1.81 src 45.13.104.95
ip route add 80.67.167.26/32 via 10.200.1.1
ip -6 route replace default via 2a0b:cbc0:1::1f9 src 2a0e:e701:11ce::1
maintenant que le tunnel gre est bien actif, je fais un nouveau test de débit.
iperf3 -c ping.online.net -p 5200
Connecting to host ping.online.net, port 5200
[ 5] local 45.13.104.95 port 40122 connected to 62.210.18.40 port 5200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 15.8 MBytes 133 Mbits/sec 1024 637 KBytes
[ 5] 1.00-2.00 sec 15.0 MBytes 126 Mbits/sec 6 668 KBytes
[ 5] 2.00-3.00 sec 15.0 MBytes 126 Mbits/sec 0 698 KBytes
[ 5] 3.00-4.00 sec 15.0 MBytes 126 Mbits/sec 0 726 KBytes
[ 5] 4.00-5.00 sec 15.0 MBytes 126 Mbits/sec 0 752 KBytes
[ 5] 5.00-6.00 sec 15.0 MBytes 126 Mbits/sec 0 779 KBytes
[ 5] 6.00-7.00 sec 13.8 MBytes 115 Mbits/sec 0 804 KBytes
[ 5] 7.00-8.00 sec 16.2 MBytes 136 Mbits/sec 0 830 KBytes
[ 5] 8.00-9.00 sec 15.0 MBytes 126 Mbits/sec 0 854 KBytes
[ 5] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec 0 877 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 151 MBytes 127 Mbits/sec 1030 sender
[ 5] 0.00-10.00 sec 149 MBytes 125 Mbits/sec receiver
iperf Done.
J'applique le MSS à 1436 (le MTU de gre1 est bien à 1476).
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o gre1 -j TCPMSS --set-mss 1436
iperf3 -c ping.online.net -p 5200
Connecting to host ping.online.net, port 5200
[ 5] local 45.13.104.95 port 40142 connected to 62.210.18.40 port 5200
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 14.6 MBytes 123 Mbits/sec 1142 670 KBytes
[ 5] 1.00-2.00 sec 16.2 MBytes 136 Mbits/sec 0 699 KBytes
[ 5] 2.00-3.00 sec 16.2 MBytes 136 Mbits/sec 0 729 KBytes
[ 5] 3.00-4.00 sec 15.0 MBytes 126 Mbits/sec 0 756 KBytes
[ 5] 4.00-5.00 sec 16.2 MBytes 136 Mbits/sec 0 784 KBytes
[ 5] 5.00-6.00 sec 15.0 MBytes 126 Mbits/sec 0 811 KBytes
[ 5] 6.00-7.00 sec 16.2 MBytes 136 Mbits/sec 0 836 KBytes
[ 5] 7.00-8.00 sec 16.2 MBytes 136 Mbits/sec 0 861 KBytes
[ 5] 8.00-9.00 sec 15.0 MBytes 126 Mbits/sec 0 883 KBytes
[ 5] 9.00-10.00 sec 15.0 MBytes 126 Mbits/sec 0 907 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 156 MBytes 131 Mbits/sec 1142 sender
[ 5] 0.00-10.00 sec 154 MBytes 129 Mbits/sec receiver
iperf Done.
Le résultat du test de débit est sensiblement le même que le précédent.
Donc dans l'état actuel des choses je passe de 360Mbits à 130Mbits en utilisant le GRE.
-
Et que dit https://milkywan.speedtest.net sans tunnel ?
Si le débit est conforme, c'est que c'est la freebox qui n'accélère pas le GRE en NAT, ce qui ne serait pas choquant vu l'âge de la Mini 4K.
-
Et que dit https://milkywan.speedtest.net sans tunnel ?
Si le débit est conforme, c'est que c'est la freebox qui n'accélère pas le GRE en NAT, ce qui ne serait pas choquant vu l'âge de la Mini 4K.
Depuis mon pc connecté par câble ethernet à la box mini 4K
(https://www.speedtest.net/result/13206558205.png) (https://www.speedtest.net/result/13206558205)
-
Donc le souci est sur la Mini 4K.
Deux choix :
- Passer en Bridge
- Passer en Gre6
-
Donc le souci est sur la Mini 4K.
Deux choix :
- Passer en Bridge
- Passer en Gre6
Pour faire du gre6 il faut que je donne mon ipv6 statique à MW ?
-
oui
-
J'ai un gros doute: faut-il que je donne l'ipv6 de ma boxe ou du serveur directement ?
Sachant que chez free le parefeu ipv6 ne peut être configuré à part activé/désactivé, il faudrait que j'ajoute un routeur entre la boxe et mon réseau local si je veux garder un parfeu pour le réseau local. Dans ce cas autant mettre ma boxe en bridge.
-
Serveur.
-
Après avoir bien galéré et chercher de la doc d'ipv6 pendant quelques heures, j'ai enfin réussi à mettre en place mon namespace et y monter le gre6
Le débit a doublé, pas mal !
iperf3 -c ping6.online.net -p 5207
Connecting to host ping6.online.net, port 5207
[ 5] local 2a0e:e701:11ce::1 port 39480 connected to 2001:bc8:1::40 port 5207
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 28.0 MBytes 235 Mbits/sec 1146 661 KBytes
[ 5] 1.00-2.00 sec 28.8 MBytes 241 Mbits/sec 0 718 KBytes
[ 5] 2.00-3.00 sec 27.5 MBytes 231 Mbits/sec 0 769 KBytes
[ 5] 3.00-4.00 sec 28.8 MBytes 241 Mbits/sec 0 818 KBytes
[ 5] 4.00-5.00 sec 30.0 MBytes 252 Mbits/sec 0 867 KBytes
[ 5] 5.00-6.00 sec 28.8 MBytes 241 Mbits/sec 0 911 KBytes
[ 5] 6.00-7.00 sec 26.2 MBytes 220 Mbits/sec 0 949 KBytes
[ 5] 7.00-8.00 sec 27.5 MBytes 231 Mbits/sec 0 985 KBytes
[ 5] 8.00-9.00 sec 27.5 MBytes 231 Mbits/sec 0 1023 KBytes
[ 5] 9.00-10.00 sec 27.5 MBytes 231 Mbits/sec 0 1.03 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 281 MBytes 235 Mbits/sec 1146 sender
[ 5] 0.00-10.00 sec 279 MBytes 234 Mbits/sec receiver
iperf Done.