L’invio della posta fallisce quando la VPN si connette: trovare la fase

La posta che ha funzionato tutta la mattina si ferma nel momento in cui il tunnel si alza, e il primo istinto è ridigitare la password. Quell’istinto salta la domanda più utile: il client ha raggiunto il server, ed è andato abbastanza lontano da offrire credenziali? Un timeout, un errore di certificato e una risposta di rifiuto sono tre guasti diversi, e solo il terzo riguarda l’account. Percorrete le fasi in ordine e la VPN diventa una variabile che potete testare invece di un sospetto a cui dare la colpa.

Fase 1: classificate il guasto prima di toccare le credenziali

Leggete l’errore che l’applicazione ha realmente prodotto, poi collocatelo in uno di tre contenitori. Un timeout o un ripristino della connessione significa che il percorso TCP è fallito; un errore TLS o di certificato significa che il percorso ha funzionato e la stretta di mano no; una risposta SMTP con un codice significa che un server di posta ha risposto e ha preso una decisione. Ogni contenitore indica un responsabile diverso.

Vale la pena separare i contenitori perché le correzioni si contraddicono. Allungare un timeout non aiuta quando il server rifiuta il mittente, e cambiare una password non fa nulla quando il percorso è bloccato. Un codice di risposta è la prova più preziosa dell’elenco, perché dimostra che l’intera catena di trasporto ha funzionato e che il problema è di politica o di identità. Salvate il testo esatto, incluso qualsiasi codice di stato esteso, prima di riprovare.

Fermatevi qui se non riuscite a riprodurre il guasto fuori dalla VPN. Un problema che compare in un’applicazione su una macchina non è ancora un problema di rete.

Fase 2: confermate l’endpoint e la modalità TLS

L’invio dei messaggi è un servizio a sé, non la stessa cosa del relay da server a server. Confermate il nome host, la porta e la modalità TLS nella documentazione del fornitore per l’invio, perché una porta nota presa in prestito da un’altra configurazione di posta non è una prova. La porta 587 attende un saluto in testo semplice seguito da STARTTLS, mentre la porta 465 attende TLS dal primo 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

Eseguire la sonda sbagliata delle due è esattamente l’errore che commette il client quando è configurato per l’altra modalità. Se la sonda TLS implicita si blocca sulla 587, o la sonda STARTTLS fallisce sulla 465, la porta e la modalità non concordano. Correggete la modalità nel client invece di disattivare la verifica del certificato, che trasforma un errore di configurazione in una connessione non verificata. La separazione è abbastanza antica da essere standardizzata: il TLS implicito sulla porta 465 è la disposizione descritta in RFC 8314.

Un errore di certificato qui è informazione e non un ostacolo. Nomina l’identità che il server ha presentato e l’identità che il client si aspettava, ed entrambe si possono correggere senza indebolire la connessione.

Fase 3: confrontate i percorsi senza cambiare l’account

Mantenete costanti l’endpoint, l’account e le impostazioni del client e cambiate solo il percorso. Inviate una volta con il tunnel abbassato e una volta con il tunnel alzato, e annotate la rotta e l’indirizzo di origine che il server vedrebbe. Se il guasto segue il percorso, l’avete isolato; se segue la macchina, 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 tunnel completo cambia l’indirizzo di origine che vede il fornitore, e alcuni fornitori trattano una fonte sconosciuta con più rigore di una password sconosciuta. È una decisione di politica da parte loro, e può essere una lista grigia, un limite di velocità o un blocco. Non generalizzate da un fornitore a tutti, e non date per scontato che una regola NAT mancante spieghi ogni guasto. La trascrizione di curl mostra quale fase è fallita anche quando il registro proprio dell’applicazione non lo fa.

Se il tunnel deve trasportare traffico internet, sia l’instradamento sia la politica di uscita devono consentire questa destinazione. Un tunnel che trasporta solo rotte private lascia la connessione di posta sul percorso locale, che è un confronto diverso.

Fase 4: inviate un messaggio innocuo e annotate la risposta

Correggete la fase che è fallita, poi inviate un messaggio innocuo tramite la stessa applicazione e non tramite una pagina di posta web. State testando il percorso di invio proprio dell’applicazione, comprese le sue impostazioni salvate e la sua modalità TLS. Una sessione di posta web non dimostra nulla al riguardo.

Annotate la risposta, la porta, la modalità TLS e il percorso che avete usato, così la persona successiva può riprodurre il risultato. Un browser funzionante e un’icona VPN verde sono osservazioni su altre cose. Se il messaggio arriva, il lavoro rimanente è rendere quella configurazione predefinita per ogni macchina che invia attraverso questo account.

La lista di controllo è completa quando sapete nominare la fase fallita, la porta e la modalità TLS usate dal client, il percorso seguito dal messaggio e la risposta restituita dal server. Questi quattro fatti trasformano un vago problema di posta in uscita in una modifica che qualcuno può rivedere.