VPN ir savienots, bet IMAP nesinhronizējas? Pārbaudiet šos trīs slāņus

Pieslēdzieties biroja VPN, atveriet pasta klientu un vērojiet, kā iesūtnē atsakās atsvaidzināties, kamēr tīmekļa pasts ielādējas normāli. Ierastā diagnoze ir tāda, ka VPN laiž cauri satiksmi, bet bloķē pastu, vai arī ir mainījusies konta parole. Abi pieņēmumi izlaiž tā struktūru, ko dara IMAP klients. Sasniegt resursdatoru, pabeigt TLS, autentificēties un atlasīt pastkasti ir četri dažādi notikumi, un VPN pieder tikai pirmais.

Mīts: viens savienojums nozīmē vienu pieteikšanos

Uzskats ir tāds, ka pastkaste faktiski ir atvērta, tiklīdz tunelis stāv un pasta serveris atbild. Tā nav. VPN nodrošina ceļu uz pakalpojumu; tas jūs nepieraksta un neizvēlas mapi. Klients var stāvēt šī ceturtā soļa vietā ar pilnībā funkcionējošu tuneli un derīgu paroli.

Tieši šajā plaisā patiesībā dzīvo lielākā daļa ziņojumu «IMAP nedarbojas caur VPN».

Trīs IMAP stāvokļi un kur klienti iestrēgst

IMAP definē neautentificētu stāvokli, autentificētu stāvokli un atlasītu stāvokli, un komandas ir derīgas tikai tajā stāvoklī, kas tās atļauj. Savienojums var arī sākties jau autentificēts, kad serveris piedāvā iepriekšēju autentifikāciju, tāpēc paroles pieprasījuma neesamība neko nepierāda. Pastkastes atlase pārvieto sesiju no autentificētas uz atlasītu, un tikai tad komandām, kas darbojas ar ziņojumiem, ir mērķis.

Klients, kas veiksmīgi autentificējas un pēc tam nespēj atlasīt konfigurēto mapi, izskatīsies kā sinhronizācijas kļūda, kamēr serveris uzvedas pareizi. Pārdēvētas mapes, pakalpojumu sniedzējs, kas «iesūtni» kartē citādi, vai trūkstošas piekļuves tiesības visas nonāk šeit. Servera atzīmētā NO atbilde ir pierādījums, un tā nav tā pati atbilde kā noraidīta parole.

TLS nāk pirms IMAP sarunas

Ar implicītu TLS uz porta 993 TLS rokasspiediens tiek pabeigts pirms jebkuras IMAP komandas nosūtīšanas, tāpēc sertifikāta problēma rada kļūdu, kas piemin uzticēšanos, nevis pastu. Pasta resursdatora nosaukumam ir jāvalidējas pret sertifikātu tāpat kā tīmekļa resursdatora nosaukumam; tunelis, kas saglabā satiksmi, nepadara nederīgu sertifikātu derīgu.

Kļūdas teksts atdala gadījumus. Savienojuma taimauts nozīmē, ka SYN nekad netika pabeigts. TLS kļūda nozīmē, ka TCP savienojums strādāja, bet rokasspiediens ne. IMAP NO vai BAD atbilde nozīmē, ka abi izdevās un protokola slānis kaut ko noraidīja. Pierakstiet, kuru redzējāt, pirms maināt jebkuru iestatījumu.

Kešotais pasts nav nekāds pierādījums

Pasta klients rāda iepriekš lejupielādētos ziņojumus neatkarīgi no tā, vai šodien var sasniegt serveri, tāpēc redzamā iesūtne tikai pasaka, ka vietējā krātuve darbojas. Jebkuram reālam testam ir jāpiespiež servera darbība: atsvaidziniet mapi, iegūstiet ziņojumu, kas nekad nav lejupielādēts, vai nosūtiet komandu, ko klients izdotu tikai pēc pastkastes atlases.

Izmantojiet neiznīcinošu pārbaudi. Vienas mapes atsvaidzināšana un konta kļūdu žurnāla lasīšana ir labāka par konta dzēšanu un atkārtotu pievienošanu, kas galvenokārt pierāda, ka konfigurācijas ekrāns joprojām darbojas.

Sūtīšana un tīmekļa pasts ir dažādi protokoli

Pasta sūtīšana ir iesniegšana, nevis IMAP. Tā izmanto atsevišķu pakalpojumu un parasti atsevišķu portu ar savu TLS režīmu un savu autentifikāciju, tāpēc strādājoša izejošā pastkaste nepierāda, ka IMAP pastkaste ir atlasīta, un bojāta izejošā pastkaste neapsūdz IMAP.

Tīmekļa pasts atkal ir citāds. Tas var izdoties caur to pašu VPN, jo tas ir HTTPS sesija pret tīmekļa priekšgalu, kas neko nepasaka par darbvirsmas klienta IMAP resursdatoru, portu vai TLS režīmu.

Nodošanai pierakstiet četrus rezultātus atsevišķi: VPN ceļu, pasta galapunkta un TLS rezultātu, konta autentifikācijas rezultātu un pastkastes atlases rezultātu. Turiet akreditācijas datus un ziņojumu saturu ārpus piezīmes. Šis ieraksts pasaka nākamajai personai, vai labojums pieder tīklam, sertifikātam, kontam vai mapju konfigurācijai, nevājinot nevienu aizsardzības slāni.