VPN 接続でメール送信が失敗する：どの段階かを特定する

朝からずっと動いていたメールが、トンネルが上がった瞬間に止まる。最初の反応はパスワードの再入力だ。だがその反応は、より有益な問いを飛ばしている。クライアントはそもそもサーバーに到達したのか、認証情報を提示できるところまで進んだのか。タイムアウト、証明書エラー、拒否応答は三つの異なる障害であり、アカウントに関わるのは三つ目だけだ。段階を順にたどれば、VPN は責める容疑者ではなく、試せる変数になる。

ステップ 1：認証情報に触れる前に障害を分類する

アプリケーションが実際に出力したエラーを読み、三つのバケツのどれかに入れる。タイムアウトや接続リセットなら TCP の経路が失敗している。TLS または証明書のエラーなら経路は通り、ハンドシェイクが通っておらず、コード付きの SMTP 応答ならメールサーバーが応答して判断を下している。バケツごとに責任の所在が違う。

バケツを分ける価値があるのは、修正方法が互いに矛盾するからだ。サーバーが送信者を拒否しているときにタイムアウトを延ばしても無意味であり、経路がブラックホール化しているときにパスワードを変えても何も起きない。応答コードはこの一覧で最も価値のある証拠で、転送経路全体が機能し、問題がポリシーか身元にあることを示す。再試行する前に、拡張ステータスコードを含む正確なテキストを保存しておく。

VPN の外で障害を再現できないなら、ここで止まる。一台のマシン上の一つのアプリで起きる問題は、まだネットワークの問題ではない。

ステップ 2：エンドポイントと TLS モードを確認する

メッセージ送信は独立したサービスであり、サーバー間のリレーとは同じものではない。送信に関するプロバイダーの文書でホスト名、ポート、TLS モードを確認する。別のメール設定から流用した見慣れたポートは証拠にならない。ポート 587 は平文の挨拶の後に STARTTLS を期待し、ポート 465 は最初のバイトから TLS を期待する。

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

その二つのうち誤った方を実行することは、クライアントがもう一方のモードに設定されているときに犯す誤りそのものだ。暗黙的 TLS の検査が 587 で止まる、あるいは STARTTLS の検査が 465 で失敗するなら、ポートとモードが一致していない。証明書の検証を無効にするのではなく、クライアント側でモードを直す。検証を切ると、設定ミスが未検証の接続に変わるだけだ。この分離は標準化されるほど古い。ポート 465 の暗黙的 TLS は RFC 8314 に記述された配置である。

ここでの証明書エラーは障害ではなく情報だ。サーバーが提示した身元と、クライアントが期待した身元を示しており、どちらも接続を弱めずに修正できる。

ステップ 3：アカウントを変えずに経路を比較する

エンドポイント、アカウント、クライアント設定を固定し、経路だけを変える。トンネルを下げた状態と上げた状態で一度ずつ送信し、サーバーから見える経路と送信元アドレスを記録する。障害が経路に従うなら切り分けはできている。マシンに従うならできていない。

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

フルトンネルはプロバイダーが見る送信元アドレスを変える。プロバイダーによっては、見慣れないパスワードより見慣れない送信元を厳しく扱う。それは相手側のポリシー判断であり、グレーリスト、速度制限、ブロックのいずれかかもしれない。一つのプロバイダーからすべてを一般化せず、NAT ルールの欠落がすべての障害を説明すると決めつけない。curl の記録は、アプリ自身のログが示さない場合でも、どの段階で失敗したかを示す。

トンネルがインターネット通信を運ぶべきなら、そのルーティングと出口ポリシーの両方がこの宛先を許可しなければならない。プライベートルートだけを運ぶトンネルでは、メール接続はローカルの経路に残る。これは別の比較だ。

ステップ 4：無害なメッセージを一つ送信し、応答を記録する

失敗した段階を直し、ウェブメールの画面ではなく同じアプリから無害なメッセージを一つ送信する。試しているのはアプリ自身の送信経路であり、保存された設定と TLS モードも含まれる。ウェブメールのセッションはその点を何も証明しない。

応答、ポート、TLS モード、使用した経路を記録し、次の担当者が結果を再現できるようにする。ブラウザーが動くことや VPN アイコンが緑であることは、別の事柄についての観察だ。メッセージが届いたなら、残る作業はその設定を、このアカウント経由で送信するすべてのマシンの既定にすることだ。

チェックリストが完成するのは、失敗した段階、クライアントが使うポートと TLS モード、メッセージがたどった経路、サーバーが返した応答を挙げられるようになったときだ。この四つの事実が、漠然とした送信トレイの問題を、誰かがレビューできる変更に変える。