L’envoi de courrier échoue quand le VPN se connecte : trouver l’étape

Le courrier qui fonctionnait toute la matinée s’arrête dès que le tunnel monte, et le premier réflexe est de retaper le mot de passe. Ce réflexe saute la question plus utile : le client a-t-il seulement atteint le serveur, et est-il allé assez loin pour proposer des identifiants ? Un délai d’attente, une erreur de certificat et une réponse de rejet sont trois pannes différentes, et seule la troisième concerne le compte. Parcourez les étapes dans l’ordre et le VPN devient une variable que vous pouvez tester plutôt qu’un suspect que vous blâmez.

Étape 1 : classez la panne avant de toucher aux identifiants

Lisez l’erreur que l’application a réellement produite, puis placez-la dans l’un de trois paniers. Un délai d’attente ou une réinitialisation de connexion signifie que le chemin TCP a échoué ; une erreur TLS ou de certificat signifie que le chemin a fonctionné et la poignée de main non ; une réponse SMTP avec un code signifie qu’un serveur de messagerie a répondu et pris une décision. Chaque panier désigne un responsable différent.

Il vaut la peine de séparer les paniers, car les corrections se contredisent. Allonger un délai d’attente ne sert à rien quand le serveur rejette l’expéditeur, et changer un mot de passe ne fait rien quand la route est bloquée. Un code de réponse est la preuve la plus précieuse de la liste, car il prouve que toute la chaîne de transport a fonctionné et que le problème relève de la politique ou de l’identité. Conservez le texte exact, y compris tout code d’état étendu, avant de réessayer.

Arrêtez-vous ici si vous ne pouvez pas reproduire la panne hors du VPN. Un problème qui apparaît dans une application sur une machine n’est pas encore un problème de réseau.

Étape 2 : confirmez le point de terminaison et le mode TLS

La soumission de messages est un service à part, pas la même chose que le relais de serveur à serveur. Confirmez le nom d’hôte, le port et le mode TLS dans la documentation du fournisseur pour la soumission, car un port familier emprunté à une autre configuration de messagerie n’est pas une preuve. Le port 587 attend une salutation en clair suivie de STARTTLS, tandis que le port 465 attend TLS dès le premier octet.

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

Lancer la mauvaise des deux sondes est exactement l’erreur que commet le client lorsqu’il est configuré pour l’autre mode. Si la sonde TLS implicite se bloque sur 587, ou si la sonde STARTTLS échoue sur 465, le port et le mode ne concordent pas. Corrigez le mode dans le client au lieu de désactiver la vérification du certificat, ce qui transforme une erreur de configuration en connexion non vérifiée. La séparation est assez ancienne pour être normalisée : le TLS implicite sur le port 465 est la disposition décrite dans RFC 8314.

Une erreur de certificat ici est une information et non un obstacle. Elle nomme l’identité que le serveur a présentée et l’identité que le client attendait, et les deux se corrigent sans affaiblir la connexion.

Étape 3 : comparez les chemins sans changer le compte

Gardez constants le point de terminaison, le compte et les réglages du client, et ne changez que le chemin. Envoyez une fois avec le tunnel abaissé et une fois avec le tunnel levé, et notez la route et l’adresse source que le serveur verrait. Si la panne suit le chemin, vous l’avez isolée ; si elle suit la machine, 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 tunnel complet change l’adresse source que voit le fournisseur, et certains fournisseurs traitent une source inconnue plus strictement qu’un mot de passe inconnu. C’est une décision de politique de leur côté, et il peut s’agir d’une liste grise, d’une limite de débit ou d’un blocage. Ne généralisez pas d’un fournisseur à tous, et ne supposez pas qu’une règle NAT manquante explique chaque panne. La transcription de curl montre quelle étape a échoué même quand le journal propre à l’application ne le montre pas.

Si le tunnel est censé transporter le trafic internet, son routage et sa politique de sortie doivent tous deux autoriser cette destination. Un tunnel qui ne transporte que des routes privées laisse la connexion de messagerie sur le chemin local, ce qui est une autre comparaison.

Étape 4 : envoyez un message inoffensif et notez la réponse

Corrigez l’étape qui a échoué, puis soumettez un message inoffensif via la même application et non via une page de courrier web. C’est le chemin d’envoi propre à l’application que vous testez, y compris ses réglages enregistrés et son mode TLS. Une session de courrier web ne prouve rien à ce sujet.

Notez la réponse, le port, le mode TLS et le chemin que vous avez utilisés, afin que la personne suivante puisse reproduire le résultat. Un navigateur qui fonctionne et une icône VPN verte sont des observations sur autre chose. Si le message arrive, le travail restant consiste à faire de cette configuration la valeur par défaut pour chaque machine qui envoie via ce compte.

La liste de contrôle est complète lorsque vous pouvez nommer l’étape qui a échoué, le port et le mode TLS utilisés par le client, le chemin suivi par le message et la réponse renvoyée par le serveur. Ces quatre faits transforment un vague problème de boîte d’envoi en un changement que quelqu’un peut relire.