Otro intento para configurar QoS en Linux: Día 2

Hasta el momento y a grandes rasgos, hemos limitado el uso de ancho de banda a un límite especifíco. Luego, hemos modelado la cola para que esta reparta el uso de ancho de banda de manera casi equitativa entre todas las conexiones: Dicha política se verifica para todo el tráfico en nuestra red.

Lo siguiente será hacer una configuración que planteé precisamente el significado de QoS: Clasificaremos tráfico y vamos a aplicarle políticas específicas a cada tipo de tráfico. Puede pensarse un poco al revés: Estableceremos políticas y luego vamos a especificar a que tráfico le aplicamos cada una.

El primer intento de configuración va de la siguiente forma:

#!/bin/bash

## Borramos la configuración anterior. 
## Cuando se tenga la configuración por defecto, se lanza un mensaje de error "RTNETLINK answers: No such file or directory"
tc qdisc delete dev ens2 root

## Cambiamos qdisc de fast_fifo a htb. 
## Dentro del esquema de HTB, este es llamado ROOT
tc qdisc add dev ens2 root handle 1:0 htb default 10

## Agregamos la primera clase. 
## Dentro del esquema de HTB, este es llamado INNER. No hay shapping en este momento, pero es necesario configurarle para el funcionamiento de los leaf
tc class add dev ens2 parent 1:0 classid 1:1 htb rate 20480 ceil 20480

## Dentro del esquema de HTB, este es llamado LEAF. Este determina la política por defecto 
tc class add dev ens2 parent 1:1 classid 1:10 htb rate 2540 ceil 2540
### Creamos los nuevos LEAF que describen dos nuevas políticas para el tráfico. 
tc class add dev ens2 parent 1:1 classid 1:20 htb rate 7680 ceil 7680
tc class add dev ens2 parent 1:1 classid 1:22 htb rate 10240 ceil 10240

## Dentro de cada clase LEAF, agregamos una QDISC de tipo SFQ. 
## SFQ intentará repartir el ancho de banda de forma más o menos equitivativa
tc qdisc add dev ens2 parent 1:10 handle 130: sfq perturb 5
tc qdisc add dev ens2 parent 1:20 handle 140: sfq perturb 5
tc qdisc add dev ens2 parent 1:22 handle 150: sfq perturb 5

## Filtro en tc
## Se especifica mediante los filtros de tc que tráfico se envía a que política
## Usamos el filtro handle, es bastante simple y económico en términos de procesamiento
tc filter add dev ens2 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev ens2 parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22

## Pre-filtro en iptables
## Este es precisamente el filtraje del tráfico: Marcamos con iptables que tráfico es cada cosa
iptables -t mangle -F
iptables -t mangle -A POSTROUTING -p tcp -m multiport --sport 22 -j MARK --set-mark 20
iptables -t mangle -A POSTROUTING -p tcp -m multiport --dport 80,443 -j MARK --set-mark 22

Las clases por ahora se ven de la siguiente forma:

tc class show dev ens2
class htb 1:22 parent 1:1 leaf 150: prio 0 rate 10240bit ceil 10240bit burst 1600b cburst 1600b
class htb 1:1 root rate 20480bit ceil 20480bit burst 1600b cburst 1600b
class htb 1:10 parent 1:1 leaf 130: prio 0 rate 2536bit ceil 2536bit burst 1599b cburst 1599b
class htb 1:20 parent 1:1 leaf 140: prio 0 rate 7680bit ceil 7680bit burst 1599b cburst 1599b

La configuración consta de dos políticas implicítas y una por defecto. Limitan el ancho de banda: El tráfico SSH (Por ahora tendremos que servirnos de este) a 750kbps; tráfico web a 1 Mbps y el demás tráfico, todo aquello que no hallamos considerado, a 250kbps. Revisemos como es que funciona una configuración de este tipo

Un ping con alta latencia. Veamos que pasa al agregar un poco de tráfico HTTPS

La latencia del ping no cambia tanto como se espera, por otro lado, la descarga web parece ir bastante bien. Al agregar un poco de tráfico FTP, bastante conocido por saber acaparar el ancho de banda, tenemos lo siguiente

El uso de ancho de banda para FTP esta bastante contenido y apenas hizo mella en la descarga HTTP. Por ahora hemos verificado que los límites para el ancho de banda en realidad funciona. Hay un problema al que no pude sacarle captura de pantalla pero que se adivina en la alta latencia del ping: DNS puede llegar a dar timeout en estas condiciones. Esto es por la naturaleza misma del tráfico DNS. La solución a este problema es establecer prioridades para las políticas. Por defecto, todos tienen prioridad 0, así que en realidad lo que se hace es quitarle prioridad a ciertas reglas con la opción prio

...
## Dentro del esquema de HTB, este es llamado LEAF. Este determina la política por defecto 
tc class add dev ens2 parent 1:1 classid 1:10 htb rate 2540 ceil 2540 prio 1
### Creamos los nuevos LEAF que describen dos nuevas políticas para el tráfico. 
tc class add dev ens2 parent 1:1 classid 1:20 htb rate 7680 ceil 7680 prio 0
tc class add dev ens2 parent 1:1 classid 1:22 htb rate 10240 ceil 10240 prio 1
... 

Y marcar el tráfico ICMP de la siguiente forma

...
iptables -t mangle -A POSTROUTING -p icmp -j MARK --set-mark 20
...

Ahora, la tasa de transferencia para HTTP sigue con el mismo rendimiento: Es el tráfico ICMP el beneficiado, es posible ver como la latencia ha bajado considerablemente

En este punto, las políticas garantizan una máxima tasa de transferencia para el tráfico que así lo necesita, y la menor latencia posible para el tráfico que así lo requiera.

Otro intento para configurar QoS en Linux: Día 1

Nota: Pues que creo que he tenido problemas con las capturas de pantalla y no se corresponden del todo con el trabajo en curso. Igual lo publico, así las cosas. Excepto ese pequeño detalle, todo lo demás es funcional

La idea es que modelemos el tráfico de nuestra red aplicando la siguiente configuración en nuestro firewall linux. O en nuestro IPS inline, que no es tan mala idea como en un principio lo parece. Que incluso puede hacerse una cajita específicamente para esto: Lo importante es que la configuración de este equipo pueda modelar todo el tráfico de nuestra red, al pasar toda nuestra red mediante él.

Por defecto, nuestra configuración tiene la siguiente forma:

tc qdisc show 
qdisc noqueue 0: dev lo root refcnt 2
qdisc pfifo_fast 0: dev ens2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: 10.dev ens3 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ens4 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ens9 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

El usuario lo vería de la siguiente manera:

Empezamos con lo que podría considerarse una configuración mínima para hacer shaping:

#!/bin/bash

## Borramos la configuración anterior. 
## Cuando se tenga la configuración por defecto, se lanza un mensaje de error "RTNETLINK answers: No such file or directory"
tc qdisc delete dev ens2 root

## Cambiamos qdisc de fast_fifo a htb. 
## Dentro del esquema de HTB, este es llamado ROOT
tc qdisc add dev ens2 root handle 1:0 htb default 10

## Agregamos la primera clase. 
## Dentro del esquema de HTB, este es llamado INNER. No hay shapping en este momento, pero es necesario configurarle para el funcionamiento de los leaf
tc class add dev ens2 parent 1:0 classid 1:1 htb rate 20480 ceil 20480

## Dentro del esquema de HTB, este es llamado LEAF. Acá ocurre el shapping por primera vez
tc class add dev ens2 parent 1:1 classid 1:10 htb rate 20480 ceil 20480

## Dentro de la última (Y única por ahora) clase LEAF, agregamos una QDISC de tipo SFQ. 
## SFQ intentará repartir el ancho de banda de forma más o menos equitivativa
tc qdisc add dev ens2 parent 1:10 handle 130: sfq perturb 5

Ahora, estamos configurados de la siguiente forma:

tc qdisc show dev ens2
qdisc htb 1: root refcnt 2 r2q 10 default 10 direct_packets_stat 0 direct_qlen 1000

tc class show dev ens2
class htb 1:10 parent 1:1 leaf 130: prio 0 rate 20480bit ceil 20480bit burst 1600b cburst 1600b
class htb 1:1 root rate 20480bit ceil 20480bit burst 1600b cburst 1600b

El resultado es que ahora nos vamos limitar: 20480bit representa un enlace de 2 MB/s. Desde el punto de vista del cliente nos vemos de la siguiente forma: Al iniciar ambas peticiones casi al mismo tiempo, el uso de ancho de banda se reparte casi igual

Conforma pasa el tiempo, el tráfico para FTP-DATA consigue un mejor rendimiento. Luego, también podría ocurrir si se inicia la descarga de FTP primero:

En general, con pfifo_fast ocurrirá que algunas conexiones irán mejor que otras. Posiblemente las más nuevas (Esto es bien común de verificar). Algunos protocolos sbbre otros. Para tener mejor idea, descargo el mismo contenido usando HTTP en ambos clientes

El cliente a la derecha descarga con todo el ancho de banda disponible en ese momento

Cuando empieza la descarga en el cliente a la izquierda, este es claramente beneficiado de un mejor ancho de banda

Una solución a este problema (Que el ancho de banda se reparta mejor entre todas las conexiones), es usar una disciplina de cola en la clase leaf. SFQ es bastante sugerido para esta trabajo en específico. Agremos lo siguiente al final del script anterior

## Dentro de la última (Y única por ahora) clase LEAF, agregamos una QDISC de tipo SFQ.
## SFQ intentará repartir el ancho de banda de forma más o menos equitivativa
tc qdisc add dev ens2 parent 1:10 handle 130: sfq perturb 5

Una vez configurado así, no importa en que momento inicia la descarga el uno o el otro: Ambas conexiones tienen casi el mismo ancho de banda disponible. El "casi" es importante. SFQ "intenta" darles el mismo ancho de banda a ambas conexiones. Con todo lo que lleva en contra, parece que hace un trabajo bastante aceptable

Otro intento para configurar QoS en Linux: Segunda introducción

Sobre como configurar ancho de banda en TC

Sobre este punto, tc puede ser complicado en tanto las nociones sobre unidades de transmisión suelen ser confusas para la mayoría de administradores de sistemas. Aún más, suelen confundirse las notaciones y usarse los términos indistintamente.

Al hablar de ancho de banda, la unidad de medida a usar es bites por segundo, que debería abreviarse como bps. Esta es la unidad de medida que suelen usar los proveedores de internet: Así, al decir megas, se refieren a Megabits por segundo; así por ejemplo, 2 Mbps en su forma abreviada.

Por otra parte, la mayoría de aplicaciones suelen medir la cantidad de bytes (Entendido como unidad de almacenamiento) que recibimos en una unidad de tiempo. Esta es la que se debería escribir como bytes/s

Para entender que estamos midiendo, pues considere dos cosas: Primero, la relación entre bytes/s y bps y  es de 1 a 8: 1 bytes/s = 8bps.  Luego, que como son unidades muy pequeñas, es común que ambas se usen como el prefijo kilos: KB/s y kbps, la relación sigue siendo la misma. 
(El truco más barato para saber que unidad de medida esta usando, es que si es muy grande, posiblemente se refiera a bps)

Luego esta tc. Se supone que tc acepta ambas unidades de medidas al agregar la unidad como sufijo. Hay que prestar atención para entender la confusión:

• kbit se refiere a kilobits por segundo (Para este no hay problema). Esta también puede escribirse como Kbit
• kbps se refiere a kilobytes por segundo (Acá se usa la notación que se espera para la otra unidad de medida)

Si ya domina la confusión sobre unidades de transferencia, puede venir a entender a tc

tc usa bits por segundo como unidad por defecto

Sobre como clasificar tráfico para tc
Nuestra primera opción es la de usar el componente filter de tc. En este caso, se considera que el clasificador u32 es el máximo exponente. Pero dado que puede convertirse en algo complicado, tenemos la opción de seguir usando a filter con algo más sencillo: Buscar "marcas" hechas con iptables mediante MARK target. También es posible usar a TOS target (Nos limitaría un poco) y a DSCP target (Con más opciones) para buscar valores en ambas cabeceras, pero tienen el inconveniente que podría tener efectos inesperados con algunos paquetes que ya tienen marca de acuerdo a sus programas de origen.

Mi mejor apuesta es a usar el CLASSIFY target, que como se verá en las pruebas que realicemos, nos ahorra, al menos a nivel de configuración, al componente filter de tc, casi nada.

Otro intento para configurar QoS en Linux: Introducción

Aunque no tengo algo como esto en producción, quería empezar a registrar algunas ideas al respecto:

Es posible que lo que entiendas por QoS sea una especie de cajón de sastre: 

Como muchos otros conceptos en informática, dicho sea de paso.
En este caso, no ayuda que en realidad haya muchos conceptos involucrados:

• La definición misma del Protocolo de Internet (RFC791) describe en sus cabeceras al campo TOS, que permitiría elegir la calidad de servicio, es decir, los parámetros requeridos a la red por la que el paquete va a atravesar. 
• Para ser más preciso, quizá casi a manera de curiosidad, parece haber un RFC específico para TOS, pero esta marcado como obsoleto debido a RFC2474
• Precisamente, una ampliación de TOS se realiza en Differentiated Services (RFC2474), que básicamente define más técnicas para mejorar la calidad de la red.
• Dentro del campo DS (Differentiated Service), de los 8 bits que lo componen, 6 bits se corresponden con DSCP (Differentiated Service Code Point). Pues sí, DSCP es parte de DiffServ, algo que en la práctica no puede tener mayor repercusión, pero que parece confundir a muchos

En GNU/Linux, la Linux Advanced Routing & Traffic Control debe considerarse La Guía de Referencia sobre QoS en este ambiente. En realidad, trata sobre casi todas las cosas más avanzadas que es posible configurar en la red de un sistema GNU/Linux, así que después después de los primeros capítulos, introductorios, nos interesa Chapter 9. Queueing Disciplines for Bandwidth Management. Es una lectura poco extensa pero que como introducción cumple bastante bien su cometido.
Recomendable leer HTB Linux queuing discipline manual - user guide, manual sobre la disciplina de encolado que vamos a usar, y que representa el núcleo de toda la configuración. De hecho, todo lo demás que puedan ofrecer esta guía proviene de allí, así que igual podría irse a las fuentes originales

Qos no es el mesías hecho software

No va a aumentar el ancho de banda mágicamente. Su función es resolver problemas bien específicos, entre los cuales no está el acelerar la navegación web. Es decir, puede hacerse algo, pero no tanto: Parece que en general, podrían haber cambios de percepción de cara al usuario, pero al final hablamos de un par de milisegundos ganados.

Algunos conceptos a tener en cuenta

A grandes rasgos, tres cosas se realizan dentro de las reglas de QoS: Restringir ancho de banda, modelar colas y clasificar el tráfico para establecer precisamente que tipo de tráfico recibirá que reglas

• Shaping:  Se refiere a la administración del ancho de banda. Dentro de tc, se realiza con las class
• Queueing: Se refiere a la forma en modelamos las colas. De hecho, la mayoría de documentación se vertebran respecto a este aspecto. Dentro de tc, se realiza con qdisc (Disciplina de colas)
• Filter: Clasificar el tráfico es realmente el paso fundamental en QoS. Por diseño, el tráfico en TCP/IP no lo está, clasificarlo es el primer paso de cara a establecer un comportamiento de parte de la red hacia ellos

Pero estos activadades no se corresponden con todos sus componentes. Debería leerse Traditional Elements of Traffic Control, que de todo lo disponible, es la lectura teórica más importante que podría hacer de todo este tema.
Aprovechando, a Components of Linux Traffic Control prácticamente debe memorizarlo

Fuentes y lecturas complementarias

• Implementing Quality of Service Policies with DSCP
• Understanding IP Precedence, TOS & DSCP 
• How do I configure QoS (Quality of Service)/ Traffic Control settings on my router?

Verificando problemas de conexión a servidores de correo externos

Administrar un servidor de correo tiene un poco de arte entre tanta técnica. Descubrir problemas una vez nuestro servidor dice que todo esta bien (Para aprender sobre lo que el servidor dice estar bien, Interpretación de maillog en Postfix es una lectura bastante recomendable) puede ser una tarea casi imposible que involucra otras aspectos de la comunicación entre servidores.

Por otra parte, al tratar con un servidor como Zimbra, los registros pueden ser extensos al punto de causar un poco de confusión. Sin embargo, el flujo de cualquier correo que se dirige a un servidor externo siempre debería terminar con lineas como las siguientes de parte del componente smtp de postfix:

May 30 08:55:54 mail postfix/smtp[51709]: A5E3A49215DB: to=<cuenta@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.21.27]:25, delay=2, delays=0.16/0/0.54/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 1464620154 s81si15913905ybb.199 - gsmtp)

Como puede verse, la línea en sí tiene la siguiente forma:

A5E3A49215DB: to=<cuenta@servicio.com>, relay=servidor_externo[ip_servidor_externo], delay=2, delays=0.16/0/0.54/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK mensaje_opcional)

Tener en cuenta que mensaje opcional es bastante propio de cada servicio de correo, y suelen ser bastante diferentes:

May 30 08:54:19 mail postfix/smtp[51710]: C126C49A603B: to=<cuenta@yahoo.es>, relay=mx-eu.mail.am0.yahoodns.net[188.125.69.79]:25, delay=2.6, delays=0.04/0.01/1.2/1.3, dsn=2.0.0, status=sent (250 ok dirdel)
May 30 08:53:22 mail postfix/smtp[12873]: 692BF4983168: to=<cuenta@hotmail.com>, relay=mx4.hotmail.com[65.55.92.168]:25, delay=5.2, delays=0.11/0.02/1.3/3.7, dsn=2.0.0, status=sent (250  <1740202306.276413.1464619995882.JavaMail.zimbra@dominio_local> Queued mail for delivery)

Pues que la costumbre podría llevarnos a conocer la respuesta específica de cada uno. Lo que cual puede ser importante ya que en cuento recibimos dicha respuesta, estamos complemente seguros de que el servidor externo ha recibido el correo. No queda de otra, que lo envíe a Spam ya es otra cuestión pero al menos sabemos no tenemos problemas de comunicación entre nuestro servidor y el de tal servidor del sistema de correo externo.

Ah, pero es posible que existan un problema si por "casualidad" tu proveedor ha configurado alguna especie de filtro de correo súper avanzado (Pero que irónicamente ya no tiene soporte). Porque en ese caso quién realiza la conexión con el servidor externo será dicho gateway y no tu servidor directamente. Lo cual te deja en la mala posición de no tener un control total sobre la forma en que se filtra tu correo. Con un filtro como este, es bastante difícil darse cuenta del problema ya que el mismo responde al componente smtp de nuestro servidor con un mensaje 250, y sin embargo no garantiza para nada que los correos pasen el filtro y mucho menos nos avisa de ello. Como si no fuera poco, este tipo de filtros de correos incumplen las normativas del protocolo porque no agregan cabeceras de su actividad en el correo, con lo que su detección se hace difícil. 

La forma más sencilla de verificar que la conexión a los servidores de correos externos es totalmente directa, es revisar la forma en que se empieza la negociación TLS con servidores en los que esto es posible (Lo que hoy en día constituyen la inmensa mayoría de servicios serios)

$ dig mx google.com.sv +short
10 google.com.s9a1.psmtp.com.
10 google.com.s9a2.psmtp.com.
10 google.com.s9b2.psmtp.com.
10 google.com.s9b1.psmtp.com.

$ openssl s_client -starttls smtp -crlf -connect google.com.s9a1.psmtp.com:25
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGoTCCBYmgAwIBAgIIbvTocO4F/oMwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbnRl
cm5ldCBBdXRob3JpdHkgRzIwHhcNMTYwNTE4MTEwNzU4WhcNMTYwODEwMTA0NjAw
WjBnMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwN
TW91bnRhaW4gVmlldzETMBEGA1UECgwKR29vZ2xlIEluYzEWMBQGA1UEAwwNbXgu
Z29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJC2mSIn
I9NGj7WxngxCWH24lvQvVgNOA6ZZdkQkpcnD7mmXw78E0irxXnIuNjyu3OEVbkyK
XJdn+nBYRCiB5a7bUcIM2Z0T9uzfvaiJoEAAWnWkBi9o5Yr6At3VCR9JnHaU8RWD
VLo0JpROn+gJqQM64lF2X0PHo8sXFAnow3ySPBcSC3wthUrT0UptBW6EWh8vS4IL
4iWbsbKjpqPCMHaCmOPBz+tFqTeCuOlt5uC0f0PtNTzXG00pUffClrlTrRudRbkb
XVPncWJYoPSVO1HlLcBLHOCaUQS4rJKfrhnqXQTlEQSu0gH+UiiX2leq4kOtzNJv
/B4bBEycTZpAbqcCAwEAAaOCA20wggNpMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjCCAjkGA1UdEQSCAjAwggIsgg1teC5nb29nbGUuY29tghdhbHQxLmFz
cG14LmwuZ29vZ2xlLmNvbYIfYWx0MS5nbWFpbC1zbXRwLWluLmwuZ29vZ2xlLmNv
bYIdYWx0MS5nbXItc210cC1pbi5sLmdvb2dsZS5jb22CF2FsdDIuYXNwbXgubC5n
b29nbGUuY29tgh9hbHQyLmdtYWlsLXNtdHAtaW4ubC5nb29nbGUuY29tgh1hbHQy
Lmdtci1zbXRwLWluLmwuZ29vZ2xlLmNvbYIXYWx0My5hc3BteC5sLmdvb2dsZS5j
b22CH2FsdDMuZ21haWwtc210cC1pbi5sLmdvb2dsZS5jb22CHWFsdDMuZ21yLXNt
dHAtaW4ubC5nb29nbGUuY29tghdhbHQ0LmFzcG14LmwuZ29vZ2xlLmNvbYIfYWx0
NC5nbWFpbC1zbXRwLWluLmwuZ29vZ2xlLmNvbYIdYWx0NC5nbXItc210cC1pbi5s
Lmdvb2dsZS5jb22CEmFzcG14LmwuZ29vZ2xlLmNvbYIVYXNwbXgyLmdvb2dsZW1h
aWwuY29tghVhc3BteDMuZ29vZ2xlbWFpbC5jb22CFWFzcG14NC5nb29nbGVtYWls
LmNvbYIVYXNwbXg1Lmdvb2dsZW1haWwuY29tghpnbWFpbC1zbXRwLWluLmwuZ29v
Z2xlLmNvbYIRZ21yLW14Lmdvb2dsZS5jb22CGGdtci1zbXRwLWluLmwuZ29vZ2xl
LmNvbTBoBggrBgEFBQcBAQRcMFowKwYIKwYBBQUHMAKGH2h0dHA6Ly9wa2kuZ29v
Z2xlLmNvbS9HSUFHMi5jcnQwKwYIKwYBBQUHMAGGH2h0dHA6Ly9jbGllbnRzMS5n
b29nbGUuY29tL29jc3AwHQYDVR0OBBYEFIX2Hm9qeZHky5XG7V5xu7fBEovoMAwG
A1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUSt0GFhu89mi1dvWBtrtiGrpagS8wIQYD
VR0gBBowGDAMBgorBgEEAdZ5AgUBMAgGBmeBDAECAjAwBgNVHR8EKTAnMCWgI6Ah
hh9odHRwOi8vcGtpLmdvb2dsZS5jb20vR0lBRzIuY3JsMA0GCSqGSIb3DQEBCwUA
A4IBAQBBlIRHixSPzCY/GS+PHpc5wDMaquNvCLKFreEnMWkH7tN7lmcyC/f8G6Kq
rtR7TdD143pSGf0nxECNFV6QA6DdAKJZ/NWu5YVK/wL/FUHedNjLfO0jOXz7DoWX
M+T0hQmEwIRPHgjGN/WjDF0YiL73wLn3Ji1fYKcE/OVmSROqc7X2F7C03DxbikW5
fBjXOpRUc+pDVP2BqNRj/opS8VsXDRb7jr1QjEciWyui29tbhoG/byhvKn3SE2/J
ThABmqJo3gW5jwaKew/7R49pm2Vvxk4Nw5wAYLhHVbKHCRjZZtjZeVAU0uUtjk8i
8SvwX5g8pDqEhtsRi1aOWU5+AP56
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 4525 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: D413E1918D87A8E1CDCE37606F539CBF9CD6F79F1BED4F58D0B03E9801738ACF
    Session-ID-ctx: 
    Master-Key: 771FA531A831086DF2311DA9F6807FABAB77022421BEEA247A241766850C53AC85295112AC44250232E21A779A1B2985
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 92 4d 45 c8 99 89 6f 92-27 10 30 69 a5 63 0f cd   .ME...o.'.0i.c..
    0010 - 1d f6 3e 72 43 a5 b3 ae-25 3a c6 94 e5 a2 df e1   ..>rC...%:......
    0020 - 92 76 d4 2d 4d cf 4b b9-f5 4c bd 4b 51 10 c8 48   .v.-M.K..L.KQ..H
    0030 - e5 a5 15 75 15 a1 92 bc-cd cb 64 c0 c9 5e c1 78   ...u......d..^.x
    0040 - 2d 51 13 82 d4 c6 cc 33-84 39 7e 09 85 9c 6b 26   -Q.....3.9~...k&
    0050 - d5 86 5b be 61 4c b0 95-64 07 0a 1d f6 5d 60 de   ..[.aL..d....]`.
    0060 - fe 37 21 58 d6 e9 35 a4-a3 90 76 63 2d e3 d0 ba   .7!X..5...vc-...
    0070 - 80 64 4f 5a 37 08 27 b4-7e 2c e9 eb 53 ab cd cc   .dOZ7.'.~,..S...
    0080 - e3 25 ad db 26 0e c8 27-7b d4 a2 c0 82 60 05 28   .%..&..'{....`.(
    0090 - 8f dd d6 d2 8d bf c0 18-72 c1 1c d0 85 21 72 92   ........r....!r.
    00a0 - 72 92 c1 8a                                       r...

    Start Time: 1464621046
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 SMTPUTF8
quit
221 2.0.0 closing connection w127si10551741ywc.301 - gsmtp
read:errno=0

Configurando TLS para envío a servidores externos en Zimbra

Desde hace un par de meses  para acá, a Google le pareció muy buena idea señalar a aquellos servicios de correos que no iniciaran TLS cuando se comunicarán con sus servidores:

Este infame candado rojo venía a decir que el dominio no era capaz de cifrar la comunicación cuando enviaba correos por el puerto 25 a gmail (Lo que dicho sea de paso es la forma en que esto ha funcionado toda la vida, el eterno chiste sobre la seguridad de nuestros correos electrónicos).

Para solventar este problema en zimbra, dependemos un poco de la versión:

• Zimbra 8.6 (No lo he probé en versiones anteriores):
  Ya esta activado por defecto y todo bien.
• Zimbra 8.0.6 (Cuidado con versiones anteriores, yo supondría que funciona de 8.0.6 en adelante)
  Es necesario correr configurarlo de la siguiente forma:

$ zmlocalconfig -e postfix_smtp_tls_security_level=may
$ zmlocalconfig -s postfix_smtp_tls_security_level
postfix_smtp_tls_security_level = may

Y con eso quedaría configurado. Lo más importante aparte de que ya no sale el candado rojo

 Y claro, las cabeceras han cambiado desde cuando no cifraba

 A algo más bonito e interesante

Por otra parte, el anterior correo es una especie de reenvío que hago de mi cuenta hacia mi cuenta de gmail, pero el correo enviado directamente se ve más bonito para google:

Fuentes:
Zimbra : Outbound smtp TLS encryption
Postconf keys
Using TLS for mail delivery from postfix to another TLS activated mail server
Best-Practice Recommendations for a Secure Zimbra Configuration

Comprobar la delegación de DNS inversa

El nombre más exacto sería Delegación IN-ADDR.ARPA sin clase, pero el que tiene por ahora tiene como más mejor posicionamente en buscadores, y es la forma en que la mayoria del mundo lo conoce.

La idea es que la resolución inversa DNS suele estar fuertemente asociada a los ISP que administran las IP que se han de resolver. Sin embargo, en ocasiones puede ser bastante engorroso tener que consultar con ellos los cambios en nuestras entradas DNS, sobre todo cuando son demasiadas.

Después de las gestiones administrativas necesarias, es posible que nos delegue la resolución inversa para una red sin clase, básicamente, las direcciones IP públicas que nos han sido proporcionadas.

Las comprobaciones pueden ser un poco tediosas, pero son sumamente necesarias para garantizar que todo esté funcionando como es debido. Si bien no hay una especie de fórmula mágica para este caso, es posible establecer una especie de pasos a seguir para comprobar que todo esté funcionando perfectamente

• Puede obtener los servidores DNS de su proveedor, usualmente preguntandole, sino, puede intentar a buscar los servidores dados para su dominio, en ese caso, proveedor.com
  Una comprobación exhaustiva requiere que se revise cada uno de los servidores DNS que aparecen como respuesta. Un DNS de su proveedor que no tenga los registros actualizados hará que los registros que se propagan por internet tengan errores.

dig NS proveedor.com +noall +additional
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> NS proveedor.com +noall +additional
;; global options: +cmd
ns.proveedor.net.         35430    IN    A    200.1.2.3
ns.proveedor9.net.        35027    IN    A    200.1.2.4  

• Luego, hay que comprobar que los servidores DNS del proveedor no pueda resolver la entrada PTR para nuestras IP, como normalmente haría, sino que frente a las consultas DNS devuelva un CNAME que ha de enviar a la autoridad para esas IP, que ya debe estar señalada como nuestros servidores DNS. Usaremos una ip 200.1.2.130, que debe estar dentro del rango de IP públicas de las que el proveedor nos transfiere la autoridad.

dig @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @200.1.2.3 -x 200.1.2.130 +norecurse +noall +answer +authority +comment
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16232
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; ANSWER SECTION:
130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.

;; AUTHORITY SECTION:
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.

Podemos obtener la forma actual del registro PTR viendo el CNAME que el servidor de nuestro proveedor devuelve en la sección ANSWER en la respuesta de la consulta anterior, pero bien puede verlo más claro con el siguiente comando

dig @200.1.2.3 -x 200.1.2.130 +norecurse +short
130.128-254.2.1.200.in-addr.arpa.

Dado que nuestros servidores DNS resuelven la reversa en base a la forma en que el servidor de su proveedor se las tranfiere, (Vea el CNAME que el servidor DNS de su proveedor ha devuelto), tenga en cuenta que su servidor ya no puede resolver ninguna de las siguientes consultas

dig @ns1.institucion.com PTR 130.2.1.200.in-addr.arpa

dig @ns1.institucion.com -x 200.1.2.130

que son con las que normalmente haría una comprobación de este tipo, pero tome en cuenta que cualquier otro servidor debe ser capaz de obtener respuestas de las mismas

dig @8.8.8.8 -x 200.1.2.130 +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.

dig @8.8.8.8 PTR 130.2.1.200.in-addr.arpa +short
130.128-254.2.1.200.in-addr.arpa.
mail.salud.gob.sv.

Para resolver correctamente en sus servidores DNS, debe hacer la consulta PTR igual al CNAME devuelto por los DNS de su proveedor. Lo que significa que usted ha configurado según parámetros del proveedor.

dig @ns1.institucion.com 130.128-254.2.1.200.in-addr.arpa
correo.institucion.com.

• Una de las pruebas más exhaustivas para empezar a revisar el problema desde un principio es hacer un dig +trace, ya que el resultado especifica el final de cada bloque, en la línea que empieza por Received x bytes… el servidor que responde por dicho bloque, así que puede rastrear si algún servidor están enviando resultados erróneos.

dig @8.8.8.8 -x 200.31.169.130 +trace +nodnssec

; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> @8.8.8.8 -x 200.31.169.130 +trace +nodnssec
; (1 server found)
;; global options: +cmd
.            19272    IN    NS    a.root-servers.net.
.            19272    IN    NS    l.root-servers.net.
.            19272    IN    NS    m.root-servers.net.
.            19272    IN    NS    j.root-servers.net.
.            19272    IN    NS    f.root-servers.net.
.            19272    IN    NS    i.root-servers.net.
.            19272    IN    NS    e.root-servers.net.
.            19272    IN    NS    g.root-servers.net.
.            19272    IN    NS    h.root-servers.net.
.            19272    IN    NS    d.root-servers.net.
.            19272    IN    NS    c.root-servers.net.
.            19272    IN    NS    k.root-servers.net.
.            19272    IN    NS    b.root-servers.net.
;; Received 239 bytes from 8.8.8.8#53(8.8.8.8) in 31 ms

in-addr.arpa.        172800    IN    NS    e.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    a.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    c.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    d.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    f.in-addr-servers.arpa.
in-addr.arpa.        172800    IN    NS    b.in-addr-servers.arpa.
;; Received 432 bytes from 192.33.4.12#53(c.root-servers.net) in 63 ms

200.in-addr.arpa.    86400    IN    NS    a.arpa.dns.br.
200.in-addr.arpa.    86400    IN    NS    ns.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns2.lacnic.net.
200.in-addr.arpa.    86400    IN    NS    ns3.afrinic.net.
200.in-addr.arpa.    86400    IN    NS    sec1.authdns.ripe.net.
200.in-addr.arpa.    86400    IN    NS    sec3.apnic.net.
200.in-addr.arpa.    86400    IN    NS    tinnie.arin.net.
200.in-addr.arpa.    86400    IN    NS    ns-lacnic.nic.mx.
;; Received 267 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 174 ms

2.1.200.in-addr.arpa. 86400    IN    NS    NS.PROVEEDOR.NET.
;; Received 83 bytes from 204.61.215.62#53(ns3.afrinic.net) in 120 ms

130.2.1.200.in-addr.arpa. 86400 IN    CNAME    130.128-254.2.1.200.in-addr.arpa.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns1.institucion.com.
128-254.2.1.200.in-addr.arpa. 86400 IN NS    ns2.institucion.com.
;; Received 162 bytes from 200.1.2.3#53(NS.PROVEEDOR.NET) in 2 ms

(1) Fuente
(2) Fuente