Hagamos un descubrimiento de ruta MTU entre dos hosts Debian separados por un enrutador Debian que ejecuta las reglas de iptables generadas por Shorewall. Cada uno de los dos hosts usa un solo enlace Ethernet, mientras que el enrutador usa VLAN etiquetadas en dos enlaces Ethernet agregados.
Usando scamper :
root@kitandara:/home/jm# scamper -I "trace -M 10.64.0.2"
traceroute from 10.1.0.5 to 10.64.0.2
1 10.1.0.1 0.180 ms [mtu: 6128]
2 10.64.0.2 0.243 ms [mtu: 6128]
Bueno: el resultado esperado es 6128 bytes (los adaptadores Realtek Ethernet baratos no pueden manejar tramas gigantes de un tamaño decente).
Ahora, deje que iperf realice una prueba de rendimiento y cuéntenos sobre la MTU por cierto:
root@kitandara:/home/jm# iperf -c 10.64.0.2 -N -m
------------------------------------------------------------
Client connecting to 10.64.0.2, TCP port 5001
TCP window size: 66.2 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.0.5 port 59828 connected with 10.64.0.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1011 MBytes 848 Mbits/sec
[ 3] MSS size 6076 bytes (MTU 6116 bytes, unknown interface)
6116 bytes? Por qué ?
Y ahora, para algo completamente diferente, veamos qué contiene realmente el tráfico de esta sesión:
root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)" | head
Capturing on eth0
1.308557 10.1.0.5 -> 10.64.0.2 TCP 74 60310 > 5001 [SYN] Seq=0 Win=5340 Len=0 MSS=534 SACK_PERM=1 TSval=101928961 TSecr=0 WS=16
1.308801 10.64.0.2 -> 10.1.0.5 TCP 74 5001 > 60310 [SYN, ACK] Seq=0 Ack=1 Win=18328 Len=0 MSS=6088 SACK_PERM=1 TSval=3764064056 TSecr=101928961 WS=64
6088 bytes MSS, lo que significa una MTU 6128 ... Bien. Pero entonces, ¿por qué iperf anuncia una MTU de 6116 bytes?
En ese punto, la minuciosidad requiere una mirada más cercana a lo que sucede durante la sesión de rastreo de estafadores:
root@kitandara:/home/jm# tshark -i eth0 -R "(ip.dst == 10.64.0.2) || (ip.src == 10.64.0.2)"
Capturing on eth0
0.000000 10.1.0.5 -> 10.64.0.2 UDP 58 Source port: 43870 Destination port: 33435
0.000175 10.1.0.1 -> 10.1.0.5 ICMP 86 Time-to-live exceeded (Time to live exceeded in transit)
0.050358 10.1.0.5 -> 10.64.0.2 UDP 58 Source port: 43870 Destination port: 33436
0.050592 10.64.0.2 -> 10.1.0.5 ICMP 86 Destination unreachable (Port unreachable)
0.099790 10.1.0.5 -> 10.64.0.2 UDP 6142 Source port: 43870 Destination port: 33437
0.100912 10.64.0.2 -> 10.1.0.5 ICMP 590 Destination unreachable (Port unreachable)
Todos esos paquetes tienen una longitud udp. De 24 excepto los dos últimos que tienen una longitud udp. De 6108 ... Pero entonces, ¿cómo nos dice el estafador que la ruta MTU es 6128?
6108, 6116, 6128 ... ¡Cuántas MTU para elegir!
Respuestas:
Muy interesante.
MSS (tamaño máximo de segmento) = MTU - encabezado IP = 6076.
6076 + 40 = 6116.
¿Podría ser que Debian está utilizando los campos de opciones de IP en el encabezado de IP? Esos podrían ser los 12 bytes adicionales ...
fuente
tshark informa el tamaño de trama de ethernet: 6142-14 (encabezado de ethernet) = 6128 bytes IP.
scamper realiza un traceroute con paquetes pequeños antes de sondear con paquetes grandes para el descubrimiento de MTU (es por eso que ve paquetes pequeños seguidos de uno grande). Esto es útil para distinguir entre todos los paquetes que se descartan / no responden y solo los grandes.
https://www.usenix.org/conference/imc-05/inferring-and-debugging-path-mtu-discovery-failures
fuente