O envío de correo falla cando se conecta a VPN: atope a etapa

O correo que funcionou toda a mañá detense no momento en que sobe o túnel, e o primeiro instinto é volver escribir o contrasinal. Ese instinto salta a pregunta máis útil: chegou o cliente ao servidor e avanzou o suficiente para ofrecer credenciais? Un tempo de espera, un erro de certificado e unha resposta de rexeitamento son tres fallos distintos, e só o terceiro afecta a conta. Percorra as etapas en orde e a VPN convértese nunha variable que pode probar en lugar dun sospeitoso ao que culpar.

Paso 1: clasifique o fallo antes de tocar as credenciais

Lea o erro que a aplicación produciu realmente e colóqueo nun de tres cubos. Un tempo de espera ou un reinicio da conexión significa que a ruta TCP fallou; un erro TLS ou de certificado significa que a ruta funcionou e o aperto de mans non; unha resposta SMTP con código significa que un servidor de correo respondeu e tomou unha decisión. Cada cubo apunta a un responsable distinto.

Paga a pena separar os cubos porque as correccións se contradín. Ampliar un tempo de espera non axuda cando o servidor rexeita o remitente, e cambiar un contrasinal non fai nada cando a ruta está bloqueada. Un código de resposta é a evidencia máis valiosa da lista, porque demostra que toda a cadea de transporte funcionou e que o problema é de política ou de identidade. Garde o texto exacto, incluído calquera código de estado ampliado, antes de volver intentalo.

Détase aquí se non pode reproducir o fallo fóra da VPN. Un problema que aparece nunha aplicación nunha máquina aínda non é un problema de rede.

Paso 2: confirme o punto final e o modo TLS

O envío de mensaxes é un servizo propio, non o mesmo que a retransmisión de servidor a servidor. Confirme o nome de host, o porto e o modo TLS na documentación do provedor para o envío, porque un porto coñecido tomado doutra configuración de correo non é proba. O porto 587 espera un saúdo en texto plano seguido de STARTTLS, mentres que o porto 465 espera TLS desde o primeiro 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 a proba equivocada das dúas é exactamente o erro que comete o cliente cando está configurado para o outro modo. Se a proba de TLS implícito se colga no 587, ou a proba de STARTTLS falla no 465, o porto e o modo non coinciden. Corrixa o modo no cliente en lugar de desactivar a verificación do certificado, que converte un erro de configuración nunha conexión non verificada. A separación é o bastante antiga como para estar estandarizada: o TLS implícito no porto 465 é a disposición descrita en RFC 8314.

Un erro de certificado aquí é información e non un obstáculo. Nomea a identidade que presentou o servidor e a identidade que esperaba o cliente, e ambas se poden corrixir sen debilitar a conexión.

Paso 3: compare camiños sen cambiar a conta

Manteña constantes o punto final, a conta e a configuración do cliente e cambie só o camiño. Envíe unha vez co túnel baixado e outra co túnel subido, e anote a ruta e o enderezo de orixe que vería o servidor. Se o fallo segue o camiño, illouno; se segue a máquina, non.

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 o enderezo de orixe que ve o provedor, e algúns provedores tratan unha fonte descoñecida con máis rigor que un contrasinal descoñecido. É unha decisión de política da súa parte, e pode ser unha lista gris, un límite de velocidade ou un bloqueo. Non xeneralice dun provedor a todos, nin supoña que unha regra NAT ausente explica cada fallo. A transcrición de curl mostra que etapa fallou mesmo cando o rexistro propio da aplicación non o fai.

Se se supón que o túnel transporta tráfico de internet, tanto o seu encamiñamento como a súa política de saída deben permitir este destino. Un túnel que só transporta rutas privadas deixa a conexión de correo na ruta local, o que é unha comparación distinta.

Paso 4: envíe unha mensaxe inofensiva e anote a resposta

Corrixa a etapa que fallou e logo envíe unha mensaxe inofensiva a través da mesma aplicación e non dunha páxina de correo web. O que proba é a ruta de envío propia da aplicación, incluída a súa configuración gardada e o seu modo TLS. Unha sesión de correo web non demostra nada ao respecto.

Anote a resposta, o porto, o modo TLS e a ruta que utilizou, para que a seguinte persoa poida reproducir o resultado. Un navegador que funciona e unha icona verde de VPN son observacións sobre outras cousas. Se a mensaxe chega, o traballo restante é facer que esa configuración sexa a predeterminada para cada máquina que envía a través desta conta.

A lista de comprobación está completa cando pode nomear a etapa que fallou, o porto e o modo TLS que usa o cliente, a ruta que seguiu a mensaxe e a resposta que devolveu o servidor. Eses catro feitos converten un problema vago de caixa de saída nun cambio que alguén pode revisar.