VPN je povezan, ali IMAP se ne sinhronizuje? Provjerite ova tri sloja

Povežite se na uredski VPN, otvorite poštanski klijent i gledajte kako prijemno sanduče odbija osvježiti dok se web-pošta učitava normalno. Uobičajena dijagnoza je da VPN propušta saobraćaj ali blokira poštu, ili da je lozinka računa promijenjena. Obje pretpostavke preskaču strukturu onoga što IMAP klijent radi. Dolazak do hosta, završetak TLS-a, autentifikacija i odabir poštanskog sandučeta su četiri različita događaja, a VPN posjeduje samo prvi.

Mit: jedna veza znači jedna prijava

Uvjerenje je da je poštansko sanduče faktički otvoreno čim je tunel podignut i poštanski server odgovori. Nije tako. VPN obezbjeđuje put do usluge; ne prijavljuje vas i ne bira fasciklu. Klijent može stajati na četvrtom od tih koraka sa potpuno ispravnim tunelom i važećom lozinkom.

Upravo u tom jazu živi većina izvještaja „IMAP ne radi preko VPN-a“.

Tri IMAP stanja i gdje klijenti zapinju

IMAP definiše neautentifikovano stanje, autentifikovano stanje i odabrano stanje, a komande su važeće samo u stanju koje ih dozvoljava. Konekcija može početi već autentifikovana kada server nudi prethodnu autentifikaciju, pa odsustvo upita za lozinku ništa ne dokazuje. Odabir poštanskog sandučeta premešta sesiju iz autentifikovanog u odabrano stanje, i tek tada komande koje djeluju na poruke imaju cilj.

Klijent koji se uspješno autentifikuje, a zatim ne uspije odabrati konfigurisanu fasciklu, izgledaće kao neuspjeh sinhronizacije dok se server ponaša ispravno. Preimenovane fascikle, provajder koji drugačije mapira „prijemno“, ili nedostajuća prava pristupa svi završavaju ovdje. Serverov označeni NO odgovor je dokaz, i to nije isti odgovor kao odbijena lozinka.

TLS dolazi prije IMAP razgovora

Uz implicitni TLS na portu 993, TLS rukovanje se završava prije nego što se pošalje bilo koja IMAP komanda, zbog čega problem sa certifikatom daje grešku koja spominje povjerenje, a ne poštu. Ime poštanskog hosta mora se validirati prema certifikatu na isti način kao ime web hosta; tunel koji čuva saobraćaj ne čini nevažeći certifikat važećim.

Tekst greške razdvaja slučajeve. Istek vremena veze znači da SYN nikada nije završen. TLS greška znači da je TCP veza radila, a rukovanje nije. IMAP NO ili BAD odgovor znači da su oba uspjela i da je protokolni sloj nešto odbio. Zapišite koji ste od njih vidjeli prije nego što promijenite bilo koju postavku.

Keširana pošta nije dokaz ničega

Poštanski klijent prikazuje ranije preuzete poruke bez obzira na to može li danas doći do servera, pa prijemno sanduče koje se prikazuje govori vam samo da lokalno skladište radi. Svaki pravi test mora forsirati operaciju na serveru: osvježite fasciklu, preuzmite poruku koja nikada nije preuzeta, ili pošaljite komandu koju bi klijent izdao tek nakon odabira poštanskog sandučeta.

Koristite nedestruktivnu provjeru. Osvježavanje jedne fascikle i čitanje dnevnika grešaka računa bolje je od brisanja i ponovnog dodavanja računa, što uglavnom dokazuje da ekran postavki još radi.

Slanje i web-pošta su različiti protokoli

Slanje pošte je predaja, ne IMAP. Ono koristi odvojenu uslugu i obično odvojen port sa vlastitim TLS režimom i vlastitom autentifikacijom, pa ispravno sanduče za odlaznu poštu ne dokazuje da je IMAP sanduče odabrano, a neispravno sanduče za odlaznu poštu ne tereti IMAP.

Web-pošta je opet drugačija. Ona može uspjeti preko istog VPN-a jer je HTTPS sesija prema web sučelju, što ništa ne govori o IMAP hostu, portu ili TLS režimu desktop klijenta.

Za predaju, zabilježite četiri rezultata odvojeno: putanju VPN-a, rezultat poštanske krajnje tačke i TLS-a, rezultat autentifikacije računa i rezultat odabira poštanskog sandučeta. Držite akreditive i sadržaj poruka izvan bilješke. Taj zapis govori sljedećoj osobi pripada li popravka mreži, certifikatu, računu ili konfiguraciji fascikle, bez slabljenja ijednog zaštitnog sloja.