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 모드, 메시지가 지난 경로, 서버가 돌려준 응답을 말할 수 있을 때 완성됩니다. 그 네 가지 사실이 막연한 보낼 편지함 문제를 누군가 검토할 수 있는 변경으로 바꿉니다.