VPN er forbundet, men IMAP synkroniserer ikke? Tjek disse tre lag

Opret forbindelse til kontorets VPN, åbn mailklienten og se indbakken nægte at opdatere, mens webmail indlæses normalt. Den sædvanlige diagnose er, at VPN’en sender trafik igennem, men blokerer mail, eller at kontoens adgangskode er ændret. Begge gæt springer strukturen over i det, en IMAP-klient gør. At nå værten, fuldføre TLS, godkende og vælge en postkasse er fire forskellige begivenheder, og VPN’en ejer kun den første.

Myten: én forbindelse betyder ét login

Troen er, at postkassen reelt er åben, så snart tunnelen er oppe, og mailserveren svarer. Det er den ikke. VPN’en leverer en vej til tjenesten; den logger dig ikke ind, og den vælger ikke en mappe. En klient kan stå ved det fjerde af disse trin med en fuldt fungerende tunnel og en gyldig adgangskode.

Det er i dette gab, at de fleste rapporter om “IMAP virker ikke over VPN” faktisk lever.

Tre IMAP-tilstande og hvor klienter går i stå

IMAP definerer en ikke-godkendt tilstand, en godkendt tilstand og en valgt tilstand, og kommandoer er kun gyldige i den tilstand, der tillader dem. En forbindelse kan også starte allerede godkendt, når serveren tilbyder forhåndsgodkendelse, så fraværet af en adgangskodeforespørgsel beviser intet i nogen retning. Valg af en postkasse flytter sessionen fra godkendt til valgt, og først da har kommandoer, der virker på meddelelser, et mål.

En klient, der godkender korrekt og derefter ikke kan vælge den konfigurerede mappe, vil se ud som en synkroniseringsfejl, mens serveren opfører sig korrekt. Omdøbte mapper, en udbyder, der mapper “indbakke” anderledes, eller manglende adgangsrettigheder ender alle her. Serverens taggede NO-svar er beviset, og det er ikke det samme svar som en afvist adgangskode.

TLS kommer før IMAP-samtalen

Med implicit TLS på port 993 fuldføres TLS-håndtrykket, før nogen IMAP-kommando sendes, og derfor giver et certifikatproblem en fejl, der nævner tillid frem for mail. Mail-værtsnavnet skal validere mod certifikatet på samme måde som et web-værtsnavn; en tunnel, der bevarer trafikken, gør ikke et ugyldigt certifikat gyldigt.

Fejlteksten adskiller tilfældene. En forbindelsestimeout betyder, at SYN aldrig blev fuldført. En TLS-fejl betyder, at TCP-forbindelsen virkede, og håndtrykket ikke. Et IMAP NO- eller BAD-svar betyder, at begge lykkedes, og at protokollaget afviste noget. Noter, hvilken du så, før du ændrer nogen indstilling.

Cachet mail er ikke bevis på noget

En mailklient viser tidligere downloadede meddelelser, uanset om den kan nå serveren i dag, så en indbakke, der vises, fortæller dig kun, at det lokale lager virker. Enhver reel test skal tvinge en serverhandling: opdater en mappe, hent en meddelelse, der aldrig blev downloadet, eller send en kommando, som klienten kun ville udstede efter at have valgt postkassen.

Brug en ikke-destruktiv kontrol. At opdatere én mappe og læse kontoens fejllog er bedre end at slette og tilføje kontoen igen, hvilket mest beviser, at konfigurationsskærmen stadig virker.

Afsendelse og webmail er forskellige protokoller

At sende mail er indlevering, ikke IMAP. Det bruger en separat tjeneste og normalt en separat port med sin egen TLS-tilstand og sin egen godkendelse, så en fungerende udbakke beviser ikke, at IMAP-postkassen blev valgt, og en ødelagt udbakke peger ikke på IMAP.

Webmail er noget andet igen. Det kan lykkes over den samme VPN, fordi det er en HTTPS-session mod en web-frontend, hvilket intet siger om skrivebordsklientens IMAP-vært, port eller TLS-tilstand.

Til en overdragelse skal du notere fire resultater hver for sig: VPN-vejen, mailendepunktet og TLS-resultatet, kontoens godkendelsesresultat og resultatet af postkassevalget. Hold legitimationsoplysninger og meddelelsesindhold ude af noten. Den registrering fortæller den næste person, om rettelsen hører til netværket, certifikatet, kontoen eller mappekonfigurationen, uden at svække nogen af beskyttelseslagene.