NGINX SSL no responde a través de IPv6

En un servidor Debian con nginx, no recibo respuesta de un servidor web a través de HTTPS e IPv6. HTTP funciona bien.

netstat informa que el puerto 443 escucha en la dirección IPv6
el firewall está abierto, ipv6scanner.com informa que el puerto 443 está abierto
localmente (sobre terminal) wget y curl reciben una respuesta correcta, por lo que la configuración de nginx está bien
no hay signos de un error de nginx error.log
no hay registro en access.log cuando falla, por lo que la comunicación probablemente no llegue al servidor web
El DNS está bien. La traducción funciona y la conexión no funciona incluso cuando se accede directamente a la dirección IP

Todo intento de conectarse desde "fuera" (es decir, fuera de la red, desde Internet) falla (navegador web, telnet, ipv6-test.com, curl ...). No hay respuesta en absoluto.

Se puede probar en www.ekasparova.eu. No tengo ni idea. ¿Qué más puedo consultar?

editar:

La salida de traceroute6 --mtu www.google.comes la siguiente:

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

Entonces nunca llega al final ...

edit2:

Mi salida de ip6tables-save (firewall 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:

Gracias a la ayuda de todos pude convencer al operador del centro de datos de que el problema está en su infraestructura. El problema realmente estaba en la configuración de MTU en un enrutador virtual en el camino a internet.

nginx ssl ipv6 j.kaspar
fuente

Fuera = ¿Fuera de la red en un segmento LAN separado o desde una computadora que se encuentra en el mismo segmento LAN?

IceMage

@IceMage Outside significa de internet. Fuera de la red. Voy a editar la pregunta para aclarar

j.kaspar

¿Has configurado un firewall en el servidor? Si el servidor está ejecutando Linux, entonces la salida de ip6table-savesería relevante.

Kasperd

@kasperd Agregué todas las reglas relacionadas con

icmp

@ j.kaspar Es la salida de lo ip6tables-saveque quería ver. Ese comando generará las reglas completas.

kasperd

Respuestas:

Tienes un problema de MTU.

Probé wget -O /dev/null https://www.ekasparova.eumientras observaba el tráfico con tcpdump. Esto es lo que vi:

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

Los primeros 3 paquetes son el apretón de manos. Ambos extremos anuncian lo mss 1440que significa que son capaces de recibir paquetes con 1440 bytes de carga TCP, contando los encabezados y un total de 1500 bytes de tráfico IP, que es lo que Ethernet admite comúnmente.

Los siguientes 2 paquetes son el saludo del cliente y la confirmación de que el servidor lo recibió.

Los 2 paquetes finales es donde las cosas se ponen interesantes. Por defecto tcpdumpmuestra números de secuencia relativos, que en este caso hacen que la captura sea más fácil de leer. En el paquete del servidor, esta es la parte interesante seq 2857:3678. Vemos un salto de 1a 2857lo que significa que hay una brecha de 2856 bytes que todavía no ha recibido el cliente. 2856 bytes corresponden a dos paquetes de 1428 bytes. La diferencia entre 1440 y 1428 es el tamaño de una opción de marca de tiempo.

Entonces, el servidor envió al servidor hola dividido en 3 paquetes. Pero los dos primeros eran demasiado grandes para la red y no se entregaron al cliente.

En el paquete final del cliente al servidor vemos esto sack 1 {2857:3678}. Este es un reconocimiento selectivo enviado por el cliente informando al servidor que hay un vacío en los datos que ha recibido hasta ahora.

Probablemente el servidor sigue enviando los dos paquetes perdidos una y otra vez. Pero no importa cuántas veces retransmita los mismos dos paquetes, siguen siendo demasiado grandes para la red. Y, probablemente, un enrutador en la ruta envía un mensaje de error al servidor informándole que los paquetes son demasiado grandes y deben ser retransmitidos en paquetes más pequeños.

Si el servidor recibiera esos mensajes de error, retransmitiría los paquetes más pequeños según sea necesario. Y recordaría el PMTU más pequeño de tal manera que en solicitudes posteriores no tenga que repetir este paso de descubrimiento.

Una posible explicación de todo esto es que tiene un firewall mal configurado que elimina todos los mensajes de error que informan a su servidor que necesita retransmitir los datos en paquetes más pequeños.

kasperd
fuente

Interesante. ¡Gracias! Esos mensajes de error: supongo que es el protocolo ICMP ... ¿Hay alguna forma de probarlo? El firewall en el servidor y el firewall entre el servidor e Internet deben estar abiertos para toda comunicación ICMP.

j.kaspar

@ j.kaspar ¿Qué son los firewalls? ¿Cómo se configuran? ¿Cómo los probaste?

Michael Hampton

@MichaelHampton hay un firewall de iptables instalado directamente en el servidor. El segundo pertenece al centro de datos y puedo administrar sus reglas. Realmente no sé cómo probar el ICMP. Pero las reglas en ambos están establecidas en cualquier lugar <-> en cualquier lugar permitido para ICMP

j.kaspar

@ j.kaspar En un servidor Linux, intente traceroute6 --mtu www.google.combuscar F=####insertadas en las líneas de salida, o líneas de salida donde no hay respuesta alguna. Pensándolo bien, simplemente ejecútelo y edite su pregunta con el resultado.

Michael Hampton

@MichaelHampton Hecho. Sin embargo, no estoy seguro de cómo interpretar el resultado. ¿Eso significa que la comunicación no pasa el segundo salto?

j.kaspar

Estoy de acuerdo con @kasperd en que es un problema de MTU. Por ejemplo, por defecto wget -6 -O/dev/null http://www.ekasparova.euno funcionaría (obtendría una redirección corta a la https://www.babysoul.cz/misma IP, pero luego se colgaría en el siguiente paquete más grande). Luego forcé MSS reducido para su host:

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

y después de eso wgetfunciona normalmente. Entonces, es un problema de MTU. La comparación de la salida de mtr -6 -n --psize 1410 www.ekasparova.eu(que funciona) con mtr -6 -n --psize 1411 www.ekasparova.euindicaría que el problema está en su host 2a04:f310:100:3:f816:3eff:fea3:4553o en su flujo ascendente en2a04:f310:100::125

Lo que podría hacer como solución alternativa (además de ponerse en contacto con su upstream):

Pruebe en qué tamaño de paquete se rompe (es decir, wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.datprobablemente no funcionará para usted mientras debería, pero wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.datfuncionará bien), y luego:

(peor) sujete su MSS para la ruta IPv6 predeterminada (como hice anteriormente). Tenga en cuenta que solo funcionará para TCP; por ejemplo, los paquetes UDP UDP seguirán rotos, o
(mejor) reduzca su interfaz MTU (por ejemplo ifconfig eth0 mtu 1200). Esto debería funcionar para todos los paquetes. El problema es que si algo en el camino tiene una MTU aún más baja, no podrá comunicarse con ellos. Y reducir MTU dará como resultado un rendimiento algo menor (no es un gran problema a menos que sea un sitio grande por lo general)
(mejor) intente si eliminar el cortafuegos de IPv6 (el suyo y en su dirección ascendente) ayuda; y cuando descubra que lo hace, intente volver a armarlo paso a paso sin romper el descubrimiento de PMTU, hasta que encuentre una línea problemática. El problema es que requiere más trabajo y cooperación por parte de su ISP (y abrir el firewall puede hacerlo vulnerable por el momento).

Matija Nalis
fuente

Reducir MSS en la ruta predeterminada no es una mala sugerencia. Es algo que he estado haciendo en entornos de producción para solucionar problemas de MTU en las redes de otras personas. Sin embargo, no voy tan bajo como 1000. 1220 es lo suficientemente pequeño como para mantener el paquete completo dentro de los 1280 bytes que IPv6 garantiza para funcionar de extremo a extremo. Sin embargo, el problema en cuestión no se habría mitigado al reducir el MSS en la ruta predeterminada, ya que solo afecta el tamaño de los paquetes en una dirección.

kasperd

Uno puede destrozar el MSS en tránsito (debería ser posible hacerlo con ip6tables). Se supone que no debe hacer eso, pero resulta que sujetar el MSS en tránsito a un máximo de 1220 es una solución muy eficiente para los problemas de MTU. Y se puede hacer en cualquier punto final o en cualquier router intermedio, y mitigará los problemas de MTU para TCP en ambas direcciones.

kasperd

Bajar la MTU en un punto final influirá en el MSS saliente y también limitará los paquetes que envíe, incluso si recibió un MSS más alto. Por lo tanto, una MTU más baja en un punto final puede mitigar los problemas de MTU para TCP en ambas direcciones. Sin embargo, solo ayuda para UDP en una dirección. Y reducir la MTU en los enrutadores intermedios puede mitigar el problema de MTU o introducir nuevos problemas de MTU dependiendo de las circunstancias. Por lo tanto, la reducción de MSS es la única mitigación que puede ayudar sin introducir potencialmente nuevos problemas de MTU.

kasperd

@kasperd no debería bajar el MSS de un lado para que el tráfico fluya en ambos sentidos, ya que se negocia (como un MSS más bajo) para toda la sesión TCP durante el protocolo de enlace de 3 vías. En cuanto a reducir MTU y romper UDP entrantes, si bien es cierto que no resolverá el problema, no debería crear problemas adicionales ya que esos UDP demasiado grandes no funcionarían de todos modos (ya que su flujo ascendente roto los dejaría caer de todos modos) .

Matija Nalis el

No. MSS se negocia independientemente para las dos direcciones. Cada lado sabe el máximo que está dispuesto a enviar y le dice al otro extremo el máximo que está dispuesto a recibir. Cuando configura advmsssolo influye en el tamaño de los segmentos que va a recibir, no en los segmentos que va a enviar. El máximo que está dispuesto a enviar no se comunica, porque no hay necesidad de eso. Ambos derivan su valor predeterminado de la MTU, uno de los dos se puede anular advmss. No conozco una forma para que una entrada de enrutamiento anule a la otra, pero si hay una forma, me gustaría aprender.

kasperd