Gửi thư thất bại khi VPN kết nối: tìm ra giai đoạn
Hết thời gian chờ, lỗi TLS và phản hồi 5xx thất bại ở các giai đoạn khác nhau. Phân loại lỗi, xác nhận chế độ TLS của cổng, rồi so sánh đường đi, không phải mật khẩu.
Thư đã hoạt động cả buổi sáng dừng lại ngay khi đường hầm được bật lên, và phản xạ đầu tiên là gõ lại mật khẩu. Phản xạ đó bỏ qua câu hỏi hữu ích hơn: máy khách có đến được máy chủ không, và có đi đủ xa để đưa ra thông tin đăng nhập không? Hết thời gian chờ, lỗi chứng chỉ và phản hồi từ chối là ba lỗi khác nhau, và chỉ lỗi thứ ba liên quan đến tài khoản. Đi qua từng giai đoạn theo thứ tự và VPN trở thành một biến có thể kiểm tra thay vì một nghi phạm bị đổ lỗi.
Giai đoạn 1: phân loại lỗi trước khi chạm vào thông tin đăng nhập
Đọc lỗi mà ứng dụng thực sự tạo ra, rồi đặt nó vào một trong ba giỏ. Hết thời gian chờ hoặc đặt lại kết nối nghĩa là đường TCP thất bại; lỗi TLS hoặc chứng chỉ nghĩa là đường đi hoạt động còn bắt tay thì không; phản hồi SMTP có mã nghĩa là máy chủ thư đã trả lời và đưa ra quyết định. Mỗi giỏ chỉ đến một người chịu trách nhiệm khác nhau.
Đáng để tách các giỏ vì các cách sửa mâu thuẫn nhau. Kéo dài thời gian chờ không giúp gì khi máy chủ từ chối người gửi, và đổi mật khẩu không làm gì khi đường đi bị chặn. Mã phản hồi là bằng chứng giá trị nhất trong danh sách, vì nó chứng minh toàn bộ chuỗi vận chuyển đã hoạt động và vấn đề là chính sách hoặc danh tính. Lưu văn bản chính xác, kể cả mã trạng thái mở rộng, trước khi thử lại.
Dừng ở đây nếu bạn không thể tái hiện lỗi bên ngoài VPN. Một vấn đề xuất hiện trong một ứng dụng trên một máy chưa phải là vấn đề mạng.
Giai đoạn 2: xác nhận điểm cuối và chế độ TLS
Gửi thư là dịch vụ riêng, không giống với chuyển tiếp từ máy chủ sang máy chủ. Xác nhận tên máy chủ, cổng và chế độ TLS từ tài liệu của nhà cung cấp cho việc gửi, vì một cổng quen thuộc mượn từ cấu hình thư khác không phải là bằng chứng. Cổng 587 chờ lời chào văn bản thuần rồi đến STARTTLS, trong khi cổng 465 chờ TLS từ byte đầu tiên.
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 587Chạy thử sai trong hai phép thử chính là lỗi mà máy khách mắc phải khi được cấu hình cho chế độ kia. Nếu phép thử TLS ngầm bị treo ở 587, hoặc phép thử STARTTLS thất bại ở 465, thì cổng và chế độ không khớp. Sửa chế độ trong máy khách thay vì tắt xác minh chứng chỉ, điều biến lỗi cấu hình thành kết nối không được xác minh. Sự tách biệt này đủ cũ để được chuẩn hóa: TLS ngầm trên cổng 465 là cách bố trí được mô tả trong RFC 8314.
Lỗi chứng chỉ ở đây là thông tin chứ không phải trở ngại. Nó nêu danh tính mà máy chủ trình bày và danh tính mà máy khách mong đợi, và cả hai đều có thể sửa mà không làm yếu kết nối.
Giai đoạn 3: so sánh đường đi mà không đổi tài khoản
Giữ điểm cuối, tài khoản và cài đặt máy khách không đổi và chỉ thay đường đi. Gửi một lần khi đường hầm xuống và một lần khi đường hầm lên, rồi ghi lại tuyến đường và địa chỉ nguồn mà máy chủ sẽ thấy. Nếu lỗi đi theo đường đi, bạn đã cô lập nó; nếu đi theo máy, bạn chưa.
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Đường hầm đầy đủ thay đổi địa chỉ nguồn mà nhà cung cấp thấy, và một số nhà cung cấp xử lý nguồn lạ nghiêm ngặt hơn mật khẩu lạ. Đó là quyết định chính sách phía họ, và có thể là danh sách xám, giới hạn tốc độ hoặc chặn. Đừng khái quát từ một nhà cung cấp cho tất cả, và đừng cho rằng một quy tắc NAT bị thiếu giải thích mọi lỗi. Bản ghi curl cho thấy giai đoạn nào thất bại ngay cả khi nhật ký của chính ứng dụng không cho thấy.
Nếu đường hầm phải mang lưu lượng internet, cả định tuyến và chính sách ra của nó đều phải cho phép đích này. Một đường hầm chỉ mang tuyến riêng để kết nối thư ở đường cục bộ, đó là một so sánh khác.
Giai đoạn 4: gửi một thư vô hại và ghi lại phản hồi
Sửa giai đoạn đã thất bại, rồi gửi một thư vô hại qua chính ứng dụng đó chứ không qua trang webmail. Thứ bạn kiểm tra là đường gửi riêng của ứng dụng, bao gồm cài đặt đã lưu và chế độ TLS. Một phiên webmail không chứng minh gì về điều đó.
Ghi lại phản hồi, cổng, chế độ TLS và đường bạn đã dùng, để người tiếp theo có thể tái hiện kết quả. Trình duyệt hoạt động và biểu tượng VPN màu xanh là quan sát về những thứ khác. Nếu thư đến, công việc còn lại là biến cấu hình đó thành mặc định cho mọi máy gửi qua tài khoản này.
Danh sách kiểm tra hoàn tất khi bạn có thể nêu giai đoạn đã thất bại, cổng và chế độ TLS mà máy khách dùng, đường mà thư đã đi và phản hồi mà máy chủ trả về. Bốn sự thật đó biến một vấn đề hộp thư đi mơ hồ thành một thay đổi mà ai đó có thể xem xét.