Wysyłanie poczty zawodzi po połączeniu VPN: znajdź etap

Poczta, która działała przez cały ranek, zatrzymuje się w chwili, gdy tunel się podnosi, a pierwszym odruchem jest ponowne wpisanie hasła. Ten odruch pomija użyteczniejsze pytanie: czy klient w ogóle dotarł do serwera i czy zaszedł wystarczająco daleko, by zaproponować dane logowania? Przekroczenie czasu, błąd certyfikatu i odpowiedź odmowna to trzy różne awarie, a tylko trzecia dotyczy konta. Przejdź etapy po kolei, a VPN stanie się zmienną, którą możesz przetestować, a nie podejrzanym, którego obwiniasz.

Krok 1: sklasyfikuj awarię, zanim dotkniesz danych logowania

Przeczytaj błąd, który aplikacja faktycznie wygenerowała, a następnie umieść go w jednym z trzech koszy. Przekroczenie czasu lub zerwanie połączenia oznacza, że ścieżka TCP zawiodła; błąd TLS lub certyfikatu oznacza, że ścieżka zadziałała, a uścisk dłoni nie; odpowiedź SMTP z kodem oznacza, że serwer poczty odpowiedział i podjął decyzję. Każdy kosz wskazuje innego odpowiedzialnego.

Kosze warto rozdzielić, bo poprawki są sprzeczne. Wydłużenie limitu czasu nic nie pomoże, gdy serwer odrzuca nadawcę, a zmiana hasła nic nie da, gdy ścieżka jest zablokowana. Kod odpowiedzi jest najcenniejszym dowodem na liście, bo dowodzi, że cały łańcuch transportu zadziałał, a problem leży w polityce lub tożsamości. Zapisz dokładny tekst, w tym każdy rozszerzony kod stanu, zanim spróbujesz ponownie.

Zatrzymaj się tutaj, jeśli nie potrafisz odtworzyć awarii poza VPN. Problem, który pojawia się w jednej aplikacji na jednej maszynie, nie jest jeszcze problemem sieci.

Krok 2: potwierdź punkt końcowy i tryb TLS

Wysyłanie wiadomości to odrębna usługa, a nie to samo co przekazywanie z serwera do serwera. Potwierdź nazwę hosta, port i tryb TLS w dokumentacji dostawcy dotyczącej wysyłania, bo znany port zapożyczony z innej konfiguracji poczty nie jest dowodem. Port 587 oczekuje powitania w czystym tekście, po którym następuje STARTTLS, natomiast port 465 oczekuje TLS od pierwszego bajtu.

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

Uruchomienie niewłaściwej z dwóch prób to dokładnie ten błąd, który popełnia klient skonfigurowany dla drugiego trybu. Jeśli próba niejawnego TLS zawiesi się na 587 albo próba STARTTLS zawiedzie na 465, port i tryb się nie zgadzają. Popraw tryb w kliencie zamiast wyłączać weryfikację certyfikatu, co zamienia błąd konfiguracji w niezweryfikowane połączenie. Podział jest dość stary, by został standaryzowany: niejawny TLS na porcie 465 to układ opisany w RFC 8314.

Błąd certyfikatu jest tu informacją, a nie przeszkodą. Nazywa tożsamość przedstawioną przez serwer i tożsamość oczekiwaną przez klienta, a obie można naprawić bez osłabiania połączenia.

Krok 3: porównaj ścieżki bez zmiany konta

Utrzymuj punkt końcowy, konto i ustawienia klienta na stałym poziomie, a zmieniaj tylko ścieżkę. Wyślij raz z opuszczonym tunelem i raz z podniesionym, i zapisz trasę oraz adres źródłowy, który widziałby serwer. Jeśli awaria podąża za ścieżką, wyizolowałeś ją; jeśli za maszyną, nie.

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

Pełny tunel zmienia adres źródłowy widziany przez dostawcę, a niektórzy dostawcy traktują nieznane źródło surowiej niż nieznane hasło. To decyzja polityczna po ich stronie i może to być szara lista, limit szybkości lub blokada. Nie uogólniaj od jednego dostawcy na wszystkich i nie zakładaj, że brakująca reguła NAT wyjaśnia każdą awarię. Zapis curl pokazuje, który etap zawiódł, nawet gdy własny log aplikacji tego nie pokazuje.

Jeśli tunel ma przenosić ruch internetowy, zarówno jego trasowanie, jak i polityka wyjścia muszą zezwalać na ten cel. Tunel przenoszący tylko trasy prywatne pozostawia połączenie poczty na ścieżce lokalnej, co jest innym porównaniem.

Krok 4: wyślij jedną nieszkodliwą wiadomość i zapisz odpowiedź

Napraw etap, który zawiódł, a następnie wyślij jedną nieszkodliwą wiadomość przez tę samą aplikację, a nie przez stronę webmailu. Testujesz własną ścieżkę wysyłania aplikacji, w tym jej zapisane ustawienia i tryb TLS. Sesja webmailu niczego w tej sprawie nie dowodzi.

Zapisz odpowiedź, port, tryb TLS i używaną ścieżkę, aby następna osoba mogła odtworzyć wynik. Działająca przeglądarka i zielona ikona VPN to obserwacje o innych rzeczach. Jeśli wiadomość dotrze, pozostała praca to uczynienie tej konfiguracji domyślną dla każdej maszyny wysyłającej przez to konto.

Lista kontrolna jest pełna, gdy potrafisz nazwać etap, który zawiódł, port i tryb TLS używane przez klienta, ścieżkę wiadomości i odpowiedź zwróconą przez serwer. Te cztery fakty zamieniają mgliste problemy ze skrzynką wychodzącą w zmianę, którą ktoś może przejrzeć.