En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.
El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:
dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)
dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)
Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.
Intente disminuir el MTU de la interfaz eth0:
debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:
1000 Metric:1
Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.
Capaz era problema se relacionaba con el MTU discovery
"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"
Luego de volver a correr "mailq -q", seguia dando el mismo error.
Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.
"debian:/home/xxxx# tcpdump -i eth0 port 25"
Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).
Comparte con ustedes lo que vi en Wireshark
Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.
Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.
debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off
debian:/home/xxxx# ethtool --offload eth0 tx off
y luego
debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off
Al hacer esto, los correos empezaron a salir :)....
Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;
"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."
Mas detallado:
"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."
En este sentido, me interesa tomar el bit RD cuando se encuentre encendido. Debido a que tcpdump permite obtener el encendido/apagado de los bits pero en octetos hay que darse cuenta que el bit RD es el bit menos significativo del octeto numero 10 dentro del paquete UDP.
En otras palabras, en el gráfico anterior cada "linea" tiene 4 octetos (32 bits). Si comenzamos a contar desde el Campo Source Port de UDP hasta el campo Query ID (incluyendo) existen 9 octetos. Por ello los próximos 8 bits son los flags del paquete DNS y el último de estos 8 (de izquierda a derecha) es el RD.
En un query standard DNS estos 8 bits generalmente vienen de la manera: 00000001, por ello el comando tcpdump que necesitamos es el siguiente:
#tcpdump -i eth0 udp[10] == 1 and port 53
Captura del wireshark:
Links importantes:
http://www.unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
Mr DNS Podcast
