VPN je připojena, ale IMAP se nesynchronizuje? Zkontrolujte tyto tři vrstvy

Připojte se k firemní VPN, otevřete poštovního klienta a sledujte, jak se doručená pošta odmítá obnovit, zatímco webmail se načítá normálně. Obvyklá diagnóza je, že VPN propouští provoz, ale blokuje poštu, nebo že se změnilo heslo k účtu. Oba odhady přeskakují strukturu toho, co klient IMAP dělá. Dosažení hostitele, dokončení TLS, ověření a výběr poštovní schránky jsou čtyři různé události a VPN vlastní jen první z nich.

Mýtus: jedno připojení znamená jedno přihlášení

Přesvědčení je, že jakmile tunel stojí a poštovní server odpovídá, je schránka prakticky otevřená. Není. VPN poskytuje cestu ke službě; nepřihlašuje vás a nevybírá složku. Klient může stát u čtvrtého z těchto kroků s dokonale funkčním tunelem a platným heslem.

Právě v této mezeře žije většina zpráv „IMAP přes VPN nefunguje“.

Tři stavy IMAP a kde klienti uváznou

IMAP definuje neověřený stav, ověřený stav a vybraný stav a příkazy jsou platné jen ve stavu, který je povoluje. Spojení může také začít už ověřené, když server nabízí předběžné ověření, takže nepřítomnost výzvy k zadání hesla nic nedokazuje. Výběr poštovní schránky přesouvá relaci z ověřeného do vybraného stavu a teprve pak mají příkazy pracující se zprávami cíl.

Klient, který se úspěšně ověří a potom nedokáže vybrat nakonfigurovanou složku, bude vypadat jako selhání synchronizace, zatímco server se chová správně. Přejmenované složky, poskytovatel, který mapuje „doručenou poštu“ jinak, nebo chybějící přístupová práva končí všechny tady. Označená odpověď NO od serveru je důkaz a není to stejná odpověď jako odmítnuté heslo.

TLS přichází před rozhovorem IMAP

U implicitního TLS na portu 993 se TLS handshake dokončí dřív, než je odeslán jakýkoli příkaz IMAP, a proto problém s certifikátem vytváří chybu, která zmiňuje důvěru, nikoli poštu. Název poštovního hostitele se musí ověřit proti certifikátu stejně jako název webového hostitele; tunel, který zachovává provoz, nedělá neplatný certifikát platným.

Text chyby případy odděluje. Časový limit spojení znamená, že SYN nikdy nedokončil. Chyba TLS znamená, že TCP spojení fungovalo a handshake ne. Odpověď IMAP NO nebo BAD znamená, že obojí uspělo a protokolová vrstva něco odmítla. Zapište, kterou z nich jste viděli, než změníte jakékoli nastavení.

Uložená pošta není důkazem ničeho

Poštovní klient zobrazuje dříve stažené zprávy bez ohledu na to, zda se dnes dostane na server, takže zobrazená doručená pošta vám říká jen to, že místní úložiště funguje. Každý skutečný test musí vynutit operaci na serveru: obnovte složku, stáhněte zprávu, která nebyla nikdy stažena, nebo pošlete příkaz, který by klient vydal až po výběru schránky.

Použijte nedestruktivní kontrolu. Obnovení jedné složky a přečtení protokolu chyb účtu je lepší než smazání a opětovné přidání účtu, což většinou dokazuje jen to, že obrazovka nastavení stále funguje.

Odesílání a webmail jsou různé protokoly

Odesílání pošty je podání, ne IMAP. Používá samostatnou službu a obvykle samostatný port s vlastním režimem TLS a vlastním ověřením, takže funkční odchozí schránka nedokazuje, že byla vybrána schránka IMAP, a nefunkční odchozí schránka nevinní IMAP.

Webmail je zase jiný. Může uspět přes stejnou VPN, protože jde o relaci HTTPS proti webovému rozhraní, což nic neříká o hostiteli IMAP, portu ani režimu TLS desktopového klienta.

Pro předání si poznamenejte čtyři výsledky odděleně: cestu VPN, výsledek poštovního koncového bodu a TLS, výsledek ověření účtu a výsledek výběru poštovní schránky. Ponechte přihlašovací údaje a obsah zpráv mimo poznámku. Tento záznam řekne dalšímu člověku, zda oprava patří síti, certifikátu, účtu nebo konfiguraci složek, aniž by oslabil kteroukoli ochrannou vrstvu.