L’enviament de correu falla quan es connecta la VPN: trobeu l’etapa

El correu que ha funcionat tot el matí s’atura en el moment que puja el túnel, i el primer impuls és reescriure la contrasenya. Aquest impuls salta la pregunta més útil: el client ha arribat al servidor, i ha anat prou lluny per oferir credencials? Un temps d’espera, un error de certificat i una resposta de rebuig són tres fallades diferents, i només la tercera afecta el compte. Recórrer les etapes en ordre fa que la VPN esdevingui una variable que podeu provar i no un sospitós a qui culpar.

Pas 1: classifiqueu la fallada abans de tocar les credencials

Llegiu l’error que l’aplicació ha produït realment i poseu-lo en una de tres caixes. Un temps d’espera o un restabliment de la connexió vol dir que el camí TCP ha fallat; un error TLS o de certificat vol dir que el camí funcionava i l’apretada de mans no; una resposta SMTP amb codi vol dir que un servidor de correu ha respost i ha pres una decisió. Cada caixa assenyala un propietari diferent.

Val la pena separar les caixes perquè les correccions es contradiuen. Allargar un temps d’espera no ajuda quan el servidor rebutja el remitent, i canviar una contrasenya no fa res quan la ruta està bloquejada. Un codi de resposta és l’evidència més valuosa de la llista, perquè demostra que tota la cadena de transport ha funcionat i que el problema és de política o d’identitat. Deseu el text exacte, incloent-hi qualsevol codi d’estat ampliat, abans de tornar-ho a provar.

Atureu-vos aquí si no podeu reproduir la fallada fora de la VPN. Un problema que apareix en una aplicació en una màquina encara no és un problema de xarxa.

Pas 2: confirmeu el punt final i el mode TLS

L’enviament de missatges és un servei propi, no el mateix que la retransmissió de servidor a servidor. Confirmeu el nom d’amfitrió, el port i el mode TLS a la documentació del proveïdor per a l’enviament, perquè un port conegut manllevat d’una altra configuració de correu no és cap prova. El port 587 espera una salutació en text pla seguida de STARTTLS, mentre que el port 465 espera TLS des del 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

Executar la prova equivocada de les dues és exactament l’error que comet el client quan està configurat per a l’altre mode. Si la prova de TLS implícit s’encalla al 587, o la prova de STARTTLS falla al 465, el port i el mode no coincideixen. Corregiu el mode al client en lloc de desactivar la verificació del certificat, cosa que converteix un error de configuració en una connexió no verificada. La separació és prou antiga per estar estandarditzada: el TLS implícit al port 465 és l’arranjament descrit a RFC 8314.

Un error de certificat aquí és informació i no un obstacle. Anomena la identitat que el servidor ha presentat i la identitat que el client esperava, i totes dues es poden corregir sense debilitar la connexió.

Pas 3: compareu camins sense canviar el compte

Mantingueu constants el punt final, el compte i la configuració del client i canvieu només el camí. Envieu una vegada amb el túnel baixat i una altra amb el túnel pujat, i anoteu la ruta i l’adreça d’origen que veuria el servidor. Si la fallada segueix el camí, l’heu aïllada; si segueix 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 complet canvia l’adreça d’origen que veu el proveïdor, i alguns proveïdors tracten una font desconeguda amb més rigor que una contrasenya desconeguda. És una decisió de política seva, i pot ser una llista grisa, un límit de velocitat o un blocatge. No generalitzeu d’un proveïdor a tots, ni suposeu que una regla NAT absent explica cada fallada. La transcripció de curl mostra quina etapa ha fallat fins i tot quan el registre propi de l’aplicació no ho fa.

Si el túnel ha de portar trànsit d’internet, tant l’encaminament com la política de sortida han de permetre aquesta destinació. Un túnel que només porta rutes privades deixa la connexió de correu al camí local, que és una comparació diferent.

Pas 4: envieu un missatge inofensiu i anoteu la resposta

Corregiu l’etapa que ha fallat i després envieu un missatge inofensiu a través de la mateixa aplicació i no d’una pàgina de correu web. El que proveu és el camí d’enviament propi de l’aplicació, incloent-hi la seva configuració desada i el seu mode TLS. Una sessió de correu web no en demostra res.

Anoteu la resposta, el port, el mode TLS i el camí que heu utilitzat, perquè la propera persona pugui reproduir el resultat. Un navegador que funciona i una icona verda de VPN són observacions sobre altres coses. Si el missatge arriba, la feina que queda és fer que aquesta configuració sigui la predeterminada per a cada màquina que envia a través d’aquest compte.

La llista de comprovació és completa quan podeu anomenar l’etapa que ha fallat, el port i el mode TLS que utilitza el client, el camí que ha seguit el missatge i la resposta que ha retornat el servidor. Aquests quatre fets converteixen un problema vague de safata de sortida en un canvi que algú pot revisar.