NGINX SSL ne répond pas sur IPv6

10

Sur un serveur Debian avec nginx, je ne reçois aucune réponse d'un serveur Web via HTTPS et IPv6. HTTP fonctionne bien.

  • netstat signale que le port 443 écoute sur l'adresse IPv6
  • le pare-feu est ouvert, ipv6scanner.com signale que le port 443 est ouvert
  • localement (sur le terminal) wget et curl reçoivent une réponse correcte, donc la configuration nginx est OK
  • aucun signe d'erreur de nginx error.log
  • aucun enregistrement dans access.log en cas d'échec, de sorte que la communication n'atteint probablement pas le serveur Web
  • DNS est très bien. La traduction fonctionne et la connexion ne fonctionne pas même lorsque l'adresse IP est accessible directement

Chaque tentative de connexion depuis "l'extérieur" (c'est-à-dire en dehors du réseau, depuis Internet) échoue (navigateur web, telnet, ipv6-test.com, curl ...). Il n'y a aucune réponse.

Il peut être testé sur www.ekasparova.eu. Je n'ai aucune idée. Que puis-je vérifier d'autre?

Éditer:

la sortie de traceroute6 --mtu www.google.comest la suivante:

traceroute to www.google.com (2a00:1450:4014:800::2004), 30 hops max, 65000 byte packets
1  * F=1500 * *
2  * * *
~
30  * * *

Alors ça n'arrive jamais à la fin ...

edit2:

Ma sortie ip6tables-save (pare-feu local):

# Generated by ip6tables-save v1.6.0 on Wed Oct 17 06:25:40 2018
*filter
:INPUT DROP [32:9320]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw6-after-forward - [0:0]
:ufw6-after-input - [0:0]
:ufw6-after-logging-forward - [0:0]
:ufw6-after-logging-input - [0:0]
:ufw6-after-logging-output - [0:0]
:ufw6-after-output - [0:0]
:ufw6-before-forward - [0:0]
:ufw6-before-input - [0:0]
:ufw6-before-logging-forward - [0:0]
:ufw6-before-logging-input - [0:0]
:ufw6-before-logging-output - [0:0]
:ufw6-before-output - [0:0]
:ufw6-logging-allow - [0:0]
:ufw6-logging-deny - [0:0]
:ufw6-reject-forward - [0:0]
:ufw6-reject-input - [0:0]
:ufw6-reject-output - [0:0]
:ufw6-skip-to-policy-forward - [0:0]
:ufw6-skip-to-policy-input - [0:0]
:ufw6-skip-to-policy-output - [0:0]
:ufw6-track-forward - [0:0]
:ufw6-track-input - [0:0]
:ufw6-track-output - [0:0]
:ufw6-user-forward - [0:0]
:ufw6-user-input - [0:0]
:ufw6-user-limit - [0:0]
:ufw6-user-limit-accept - [0:0]
:ufw6-user-logging-forward - [0:0]
:ufw6-user-logging-input - [0:0]
:ufw6-user-logging-output - [0:0]
:ufw6-user-output - [0:0]
-A INPUT -j ufw6-before-logging-input
-A INPUT -j ufw6-before-input
-A INPUT -j ufw6-after-input
-A INPUT -j ufw6-after-logging-input
-A INPUT -j ufw6-reject-input
-A INPUT -j ufw6-track-input
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j ufw6-before-logging-forward
-A FORWARD -j ufw6-before-forward
-A FORWARD -j ufw6-after-forward
-A FORWARD -j ufw6-after-logging-forward
-A FORWARD -j ufw6-reject-forward
-A FORWARD -j ufw6-track-forward
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A OUTPUT -j ufw6-before-logging-output
-A OUTPUT -j ufw6-before-output
-A OUTPUT -j ufw6-after-output
-A OUTPUT -j ufw6-after-logging-output
-A OUTPUT -j ufw6-reject-output
-A OUTPUT -j ufw6-track-output
-A ufw6-after-input -p udp -m udp --dport 137 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 138 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 139 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 445 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 546 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 547 -j ufw6-skip-to-policy-input
-A ufw6-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-before-forward -m rt --rt-type 0 -j DROP
-A ufw6-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-forward -j ufw6-user-forward
-A ufw6-before-input -i lo -j ACCEPT
-A ufw6-before-input -m rt --rt-type 0 -j DROP
-A ufw6-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-input -m conntrack --ctstate INVALID -j ufw6-logging-deny
-A ufw6-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 144 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 145 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 146 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -j ACCEPT
-A ufw6-before-input -d ff02::fb/128 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw6-before-input -d ff02::f/128 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw6-before-input -j ufw6-user-input
-A ufw6-before-output -o lo -j ACCEPT
-A ufw6-before-output -m rt --rt-type 0 -j DROP
-A ufw6-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -j ufw6-user-output
-A ufw6-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw6-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw6-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-skip-to-policy-forward -j DROP
-A ufw6-skip-to-policy-input -j DROP
-A ufw6-skip-to-policy-output -j ACCEPT
-A ufw6-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 20 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 21 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 110 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 143 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 587 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 993 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 995 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8080 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8081 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 10000 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m multiport --dports 29799:29899 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8082 -j ACCEPT
-A ufw6-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw6-user-limit -j REJECT --reject-with icmp6-port-unreachable
-A ufw6-user-limit-accept -j ACCEPT
COMMIT
# Completed on Wed Oct 17 06:25:40 2018

edit3:

Grâce à l'aide de tous, j'ai pu convaincre l'opérateur du centre de données que le problème est dans leur infrastructure. Le problème était vraiment dans le paramètre MTU sur un routeur virtuel sur le chemin d'Internet.

nginx ssl ipv6 j.kaspar
la source
Outside = En dehors du réseau sur un segment LAN séparé, ou depuis un ordinateur assis sur le même segment LAN?
IceMage
1
@IceMage Outside signifie Internet. En dehors du réseau. Je vais modifier la question pour clarifier
j.kaspar
Avez-vous configuré un pare-feu sur le serveur? Si le serveur exécute Linux, la sortie de ip6table-saveserait pertinente.
kasperd
@kasperd J'ai ajouté toutes les règles liées à l'
ICMP
@ j.kaspar C'est la sortie de que ip6tables-saveje voulais voir. Cette commande affichera les règles complètes.
kasperd

Réponses:

19

Vous avez un problème MTU.

J'ai testé wget -O /dev/null https://www.ekasparova.eutout en observant le trafic avec tcpdump. Voici ce que j'ai vu:

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0

Les 3 premiers paquets sont la poignée de main. Les deux extrémités annoncent mss 1440ce qui signifie qu'elles sont capables de recevoir des paquets avec 1440 octets de charge utile TCP, en comptant les en-têtes et cela totalise jusqu'à 1500 octets de trafic IP, ce que Ethernet prend généralement en charge.

Les 2 paquets suivants sont le bonjour au client et l'accusé de réception a été reçu par le serveur.

Les 2 derniers paquets sont là où les choses deviennent intéressantes. Par défaut, tcpdumpaffiche les numéros de séquence relatifs, qui dans ce cas facilitent la lecture de la capture. Dans le paquet du serveur, c'est la partie intéressante seq 2857:3678. Nous voyons un saut de 1à ce 2857qui signifie qu'il ya un écart de 2856 octets que le client n'a pas encore RECEIVE. 2856 octets correspond à deux paquets de 1428 octets. La différence entre 1440 et 1428 est la taille d'une option d'horodatage.

Ainsi, le serveur a envoyé le serveur bonjour divisé en 3 paquets. Mais les deux premiers étaient trop volumineux pour le réseau et n'ont pas été livrés au client.

Dans le paquet final du client au serveur, nous voyons cela sack 1 {2857:3678}. Il s'agit d'un accusé de réception sélectif envoyé par le client informant le serveur qu'il existe un écart dans les données qu'il a reçues jusqu'à présent.

Il est probable que le serveur envoie sans cesse les deux paquets perdus. Mais peu importe combien de fois il retransmet les deux mêmes paquets, ils restent trop gros pour le réseau. Et probablement un routeur sur le chemin envoie un message d'erreur au serveur l'informant que les paquets sont trop gros et doivent être retransmis en paquets plus petits.

Si le serveur recevait ces messages d'erreur, il retransmettrait les paquets plus petits selon les besoins. Et il se souviendrait du PMTU plus petit, de sorte que lors des demandes ultérieures, il n'aurait pas à répéter cette étape de découverte.

Une explication possible de tout cela est que vous avez un pare-feu mal configuré qui supprime tous les messages d'erreur informant votre serveur qu'il doit retransmettre les données en paquets plus petits.

kasperd
la source
1
Intéressant. Je vous remercie! Ces messages d'erreur - je suppose que c'est le protocole ICMP ... Y a-t-il un moyen de le tester? Le pare-feu sur le serveur et le pare-feu entre le serveur et Internet doivent être ouverts pour toutes les communications ICMP.
j.kaspar
@ j.kaspar Quels sont les pare-feu? Comment sont-ils configurés? Comment les avez-vous testés?
Michael Hampton
@MichaelHampton, un pare-feu iptables est installé directement sur le serveur. Le second appartient au datacenter et je suis capable de gérer ses règles. Je ne sais pas vraiment comment tester l'ICMP. Mais les règles des deux sont définies n'importe où <-> n'importe où autorisé pour ICMP
j.kaspar
1
@ j.kaspar Sur un serveur Linux, essayez de traceroute6 --mtu www.google.comchercher F=####inséré dans les lignes de sortie, ou les lignes de sortie où aucune réponse ne revient du tout. Après réflexion, exécutez-le et modifiez votre question avec la sortie.
Michael Hampton
@MichaelHampton Done. Cependant, je ne sais pas comment interpréter le résultat. Est-ce à dire que la communication ne passe pas du tout le deuxième saut?
j.kaspar
1

Je suis d'accord avec @kasperd qu'il s'agit d'un problème MTU. Par exemple, par défaut, wget -6 -O/dev/null http://www.ekasparova.eucela ne fonctionnerait pas (il obtiendrait une redirection courte vers la https://www.babysoul.cz/même IP, mais il se bloquerait ensuite sur le prochain paquet plus gros). Ensuite, j'ai réduit le MSS de force pour votre hôte:

ip -6 ro add 2a04:f310:100:3:f816:3eff:fea3:4553 advmss 1000 via $MY_GW

et après cela wgetfonctionne normalement. C'est donc un problème de MTU. La comparaison de la sortie de mtr -6 -n --psize 1410 www.ekasparova.eu(qui fonctionne) avec mtr -6 -n --psize 1411 www.ekasparova.euindiquerait que le problème est soit sur votre hôte, 2a04:f310:100:3:f816:3eff:fea3:4553soit en amont sur2a04:f310:100::125

Ce que vous pourriez faire comme solution de contournement (à part contacter votre amont):

Testez à quelle taille de paquet il casse (c.-à-d. wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.datNe fonctionnera probablement pas pour vous alors qu'il le devrait, mais wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.datfonctionnera très bien), puis soit:

  • (pire) bloquez votre MSS pour la route IPv6 par défaut (comme je l'ai fait ci-dessus). Notez que cela ne fonctionnera que pour TCP; par exemple, les paquets DNS UDP seront toujours rompus, ou
  • (mieux) réduisez votre interface MTU (par exemple ifconfig eth0 mtu 1200). Cela devrait fonctionner pour tous les paquets. Le problème est que si quelque chose sur le chemin a un MTU encore plus bas, vous ne pourrez pas communiquer avec eux. Et la baisse de MTU entraînera des performances quelque peu inférieures (ce n'est pas grave, sauf si vous êtes généralement un gros site)
  • (mieux) essayez si la suppression du pare-feu IPv6 (le vôtre et à votre amont) aide; et lorsque vous le découvrez, essayez de le remonter étape par étape sans interrompre la découverte de PMTU, jusqu'à ce que vous trouviez une ligne problématique. Le problème est qu'il nécessite plus de travail et de coopération de votre FAI (et l'ouverture du pare-feu pourrait vous rendre vulnérable pour le moment).
Matija Nalis
la source
Réduire MSS sur la route par défaut n'est pas une mauvaise suggestion. C'est quelque chose que j'ai fait dans des environnements de production pour contourner les problèmes de MTU dans les réseaux d'autres personnes. Mais je ne descends pas aussi bas que 1000. 1220 est suffisamment petit pour garder le paquet complet dans les 1280 octets qu'IPv6 garantit de fonctionner de bout en bout. Cependant, le problème en question n'aurait pas été atténué en réduisant MSS sur la route par défaut car il n'affecte que la taille des paquets dans une direction.
kasperd
On peut manipuler le MSS en transit (cela devrait être possible avec ip6tables). Vous n'êtes pas censé faire cela, mais il s'avère que le serrage du MSS en transit à un maximum de 1220 est une solution de contournement très efficace pour les problèmes de MTU. Et cela peut être fait sur l'un ou l'autre des terminaux ou sur n'importe quel routeur intermédiaire, et cela atténuera les problèmes de MTU pour TCP dans les deux sens.
kasperd
L'abaissement de la MTU sur un point d'extrémité influencera le MSS sortant et limitera également les paquets que vous envoyez même si vous avez reçu un MSS supérieur. Ainsi, une MTU inférieure à un point d'extrémité peut atténuer les problèmes de MTU pour TCP dans les deux sens. Cependant, cela n'aide UDP que dans une seule direction. Et réduire le MTU sur les routeurs entre les deux peut atténuer le problème MTU ou introduire de nouveaux problèmes MTU selon les circonstances. Ainsi, la réduction du MSS est la seule atténuation qui peut aider sans potentiellement introduire de nouveaux problèmes MTU.
kasperd
@kasperd ne devrait pas abaisser le MSS d'un côté pour le trafic circulant dans les deux sens, car il est négocié (en tant que MSS inférieur) pour toute la session TCP pendant la prise de contact à 3 voies? Quant à la baisse du MTU et à la rupture des UDP entrants, bien qu'il soit vrai que cela ne résoudra pas le problème, cela ne devrait pas créer de problèmes supplémentaires car ces trop gros UDP ne fonctionneraient pas de toute façon (car son brisé en amont les supprimerait de toute façon) .
Matija Nalis
1
Non. Le SMS est négocié indépendamment pour les deux directions. Chaque partie connaît le maximum qu'elle est prête à envoyer et indique à l'autre extrémité le maximum qu'elle souhaite recevoir. Lorsque vous définissez, advmssvous n'influencez que la taille des segments que vous allez recevoir et non les segments que vous allez envoyer. Le maximum que vous êtes prêt à envoyer n'est pas communiqué - car cela n'est pas nécessaire. Les deux dérivent leur valeur par défaut du MTU, l'un des deux peut être remplacé par advmss. Je ne connais pas un moyen pour une entrée de routage de remplacer l'autre, mais s'il y en a un, j'aimerais apprendre.
kasperd