El envío de correo falla cuando se conecta la VPN: encuentre la etapa

El correo que funcionó toda la mañana se detiene en el momento en que sube el túnel, y el primer instinto es volver a escribir la contraseña. Ese instinto se salta la pregunta más útil: ¿llegó el cliente al servidor y avanzó lo suficiente para ofrecer credenciales? Un tiempo de espera, un error de certificado y una respuesta de rechazo son tres fallos distintos, y solo el tercero afecta a la cuenta. Recorra las etapas en orden y la VPN se convierte en una variable que puede probar en lugar de un sospechoso al que culpar.

Paso 1: clasifique el fallo antes de tocar las credenciales

Lea el error que la aplicación produjo realmente y colóquelo en uno de tres cubos. Un tiempo de espera o un reinicio de la conexión significa que la ruta TCP falló; un error TLS o de certificado significa que la ruta funcionó y el apretón de manos no; una respuesta SMTP con código significa que un servidor de correo respondió y tomó una decisión. Cada cubo apunta a un responsable distinto.

Vale la pena separar los cubos porque las correcciones se contradicen. Ampliar un tiempo de espera no ayuda cuando el servidor rechaza al remitente, y cambiar una contraseña no hace nada cuando la ruta está bloqueada. Un código de respuesta es la evidencia más valiosa de la lista, porque demuestra que toda la cadena de transporte funcionó y que el problema es de política o de identidad. Guarde el texto exacto, incluido cualquier código de estado ampliado, antes de volver a intentarlo.

Deténgase aquí si no puede reproducir el fallo fuera de la VPN. Un problema que aparece en una aplicación en una máquina todavía no es un problema de red.

Paso 2: confirme el punto final y el modo TLS

El envío de mensajes es un servicio propio, no lo mismo que la retransmisión de servidor a servidor. Confirme el nombre de host, el puerto y el modo TLS en la documentación del proveedor para el envío, porque un puerto conocido tomado de otra configuración de correo no es prueba. El puerto 587 espera un saludo en texto plano seguido de STARTTLS, mientras que el puerto 465 espera TLS desde el primer byte.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Ejecutar la prueba equivocada de las dos es exactamente el error que comete el cliente cuando está configurado para el otro modo. Si la prueba de TLS implícito se cuelga en el 587, o la prueba de STARTTLS falla en el 465, el puerto y el modo no coinciden. Corrija el modo en el cliente en lugar de desactivar la verificación del certificado, que convierte un error de configuración en una conexión no verificada. La separación es lo bastante antigua como para estar estandarizada: el TLS implícito en el puerto 465 es la disposición descrita en RFC 8314.

Un error de certificado aquí es información y no un obstáculo. Nombra la identidad que presentó el servidor y la identidad que esperaba el cliente, y ambas se pueden corregir sin debilitar la conexión.

Paso 3: compare rutas sin cambiar la cuenta

Mantenga constantes el punto final, la cuenta y la configuración del cliente y cambie solo la ruta. Envíe una vez con el túnel bajado y otra con el túnel subido, y anote la ruta y la dirección de origen que vería el servidor. Si el fallo sigue la ruta, lo ha aislado; si sigue a la máquina, no.

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

Un túnel completo cambia la dirección de origen que ve el proveedor, y algunos proveedores tratan una fuente desconocida con más rigor que una contraseña desconocida. Es una decisión de política suya, y puede ser una lista gris, un límite de velocidad o un bloqueo. No generalice de un proveedor a todos, ni suponga que una regla NAT ausente explica cada fallo. La transcripción de curl muestra qué etapa falló incluso cuando el registro propio de la aplicación no lo hace.

Si se supone que el túnel transporta tráfico de internet, tanto su enrutamiento como su política de salida deben permitir este destino. Un túnel que solo transporta rutas privadas deja la conexión de correo en la ruta local, que es una comparación distinta.

Paso 4: envíe un mensaje inofensivo y anote la respuesta

Corrija la etapa que falló y luego envíe un mensaje inofensivo a través de la misma aplicación y no de una página de correo web. Lo que prueba es la ruta de envío propia de la aplicación, incluida su configuración guardada y su modo TLS. Una sesión de correo web no demuestra nada al respecto.

Anote la respuesta, el puerto, el modo TLS y la ruta que utilizó, para que la siguiente persona pueda reproducir el resultado. Un navegador que funciona y un icono verde de VPN son observaciones sobre otras cosas. Si el mensaje llega, el trabajo restante es hacer que esa configuración sea la predeterminada para cada máquina que envía a través de esta cuenta.

La lista de comprobación está completa cuando puede nombrar la etapa que falló, el puerto y el modo TLS que usa el cliente, la ruta que siguió el mensaje y la respuesta que devolvió el servidor. Esos cuatro hechos convierten un problema vago de bandeja de salida en un cambio que alguien puede revisar.