VPN połączony, ale IMAP się nie synchronizuje? Sprawdź te trzy warstwy

Połącz się z VPN biura, otwórz klienta poczty i obserwuj, jak skrzynka odbiorcza odmawia odświeżenia, podczas gdy webmail ładuje się normalnie. Zwykła diagnoza mówi, że VPN przepuszcza ruch, ale blokuje pocztę, albo że zmieniono hasło konta. Oba domysły pomijają strukturę tego, co robi klient IMAP. Dotarcie do hosta, ukończenie TLS, uwierzytelnienie i wybór skrzynki to cztery różne zdarzenia, a VPN posiada tylko pierwsze.

Mit: jedno połączenie to jedno logowanie

Przekonanie jest takie, że gdy tunel stoi, a serwer poczty odpowiada, skrzynka jest faktycznie otwarta. Nie jest. VPN dostarcza ścieżkę do usługi; nie loguje cię i nie wybiera folderu. Klient może stać na czwartym z tych kroków z doskonale działającym tunelem i ważnym hasłem.

Właśnie w tej luce żyje w rzeczywistości większość zgłoszeń „IMAP nie działa przez VPN”.

Trzy stany IMAP i miejsca, w których klienci utykają

IMAP definiuje stan nieuwierzytelniony, stan uwierzytelniony i stan wybrany, a polecenia są ważne tylko w stanie, który na nie pozwala. Połączenie może też zacząć się już uwierzytelnione, gdy serwer oferuje wstępne uwierzytelnianie, więc brak prośby o hasło niczego nie dowodzi. Wybór skrzynki przenosi sesję z uwierzytelnionej do wybranej i dopiero wtedy polecenia działające na wiadomościach mają cel.

Klient, który uwierzytelnia się poprawnie, a potem nie potrafi wybrać skonfigurowanego folderu, będzie wyglądał jak błąd synchronizacji, choć serwer zachowuje się prawidłowo. Zmienione nazwy folderów, dostawca inaczej mapujący „skrzynkę odbiorczą” albo brakujące uprawnienia dostępu kończą się właśnie tutaj. Odpowiedź NO oznaczona tagiem serwera jest dowodem i nie jest to ta sama odpowiedź, co odrzucone hasło.

TLS poprzedza rozmowę IMAP

Przy domyślnym TLS na porcie 993 uzgadnianie TLS kończy się przed wysłaniem jakiegokolwiek polecenia IMAP, dlatego problem z certyfikatem daje błąd, który wspomina zaufanie, a nie pocztę. Nazwa hosta poczty musi być zweryfikowana względem certyfikatu tak samo jak nazwa hosta witryny; tunel, który zachowuje ruch, nie czyni nieważnego certyfikatu ważnym.

Tekst błędu rozdziela przypadki. Przekroczenie czasu połączenia oznacza, że SYN nigdy się nie ukończył. Błąd TLS oznacza, że połączenie TCP działało, a uzgadnianie nie. Odpowiedź IMAP NO lub BAD oznacza, że oba się powiodły, a warstwa protokołu coś odrzuciła. Zapisz, którą z nich widziałeś, zanim zmienisz jakiekolwiek ustawienie.

Poczta w pamięci podręcznej niczego nie dowodzi

Klient poczty pokazuje wcześniej pobrane wiadomości niezależnie od tego, czy dziś dotrze do serwera, więc wyświetlana skrzynka odbiorcza mówi tylko, że pamięć lokalna działa. Każdy prawdziwy test musi wymusić operację na serwerze: odśwież folder, pobierz wiadomość, która nigdy nie została pobrana, albo wyślij polecenie, które klient wydałby dopiero po wybraniu skrzynki.

Użyj kontroli nieniszczącej. Odświeżenie jednego folderu i przeczytanie dziennika błędów konta jest lepsze niż usunięcie i ponowne dodanie konta, co przede wszystkim dowodzi, że ekran konfiguracji nadal działa.

Wysyłanie i webmail to różne protokoły

Wysyłanie poczty to nadawanie, nie IMAP. Używa osobnej usługi i zwykle osobnego portu z własnym trybem TLS i własnym uwierzytelnianiem, więc działająca skrzynka nadawcza nie dowodzi, że wybrano skrzynkę IMAP, a zepsuta skrzynka nadawcza nie obciąża IMAP.

Webmail jest znów inny. Może działać przez ten sam VPN, bo jest sesją HTTPS wobec frontendu internetowego, co nic nie mówi o hoście IMAP, porcie ani trybie TLS klienta desktopowego.

Do przekazania zapisz osobno cztery wyniki: ścieżkę VPN, wynik punktu końcowego poczty i TLS, wynik uwierzytelnienia konta i wynik wyboru skrzynki. Trzymaj dane logowania i treść wiadomości poza notatką. Ten zapis mówi następnej osobie, czy poprawka należy do sieci, certyfikatu, konta czy konfiguracji folderów, nie osłabiając żadnej z warstw ochrony.