VPN is verbind, maar IMAP sinchroniseer nie? Kyk na hierdie drie lae

Maak aan die kantoor-VPN vas, open die poskliënt en kyk hoe die inkassie weier om te verfris terwyl webpos normaal laai. Die gewone diagnose is dat die VPN verkeer deurlaat maar pos blokkeer, of dat die rekening se wagwoord verander het. Beide raaiskote slaan die struktuur van wat 'n IMAP-kliënt doen, oor. Om die gasheer te bereik, TLS te voltooi, te verifieer en 'n posbus te kies, is vier verskillende gebeurtenisse, en die VPN besit net die eerste.

Die mite: een verbinding beteken een aanmelding

Die oortuiging is dat die posbus eintlik oop is sodra die tonnel staan en die posbediener antwoord. Dit is nie. Die VPN verskaf 'n pad na die diens; dit meld jou nie aan nie, en dit kies nie 'n gids nie. 'n Kliënt kan by die vierde van daardie stappe sit met 'n heeltemal werkende tonnel en 'n geldige wagwoord.

Daardie gaping is waar die meeste verslae oor “IMAP werk nie oor VPN nie” werklik leef.

Drie IMAP-toestande, en waar kliënte vashaak

IMAP definieer 'n nie-geverifieerde toestand, 'n geverifieerde toestand en 'n gekose toestand, en opdragte is net geldig in die toestand wat hulle toelaat. 'n Verbinding kan ook al geverifieer begin wanneer die bediener voorafverifikasie bied, so die afwesigheid van 'n wagwoordprompt bewys niks in een of ander rigting nie. Om 'n posbus te kies, skuif die sessie van geverifieer na gekies, en eers dan het opdragte wat op boodskappe werk, 'n teiken.

'n Kliënt wat suksesvol verifieer en dan nie die gekonfigureerde gids kies nie, sal soos 'n sinchroniseringsfout lyk terwyl die bediener korrek werk. Hernoemde gidse, 'n verskaffer wat “inkassie” anders karteer, of ontbrekende toegangsregte beland almal hier. Die bediener se gemerkte NO-antwoord is die bewys, en dit is nie dieselfde antwoord as 'n verwerpte wagwoord nie.

TLS kom voor die IMAP-gesprek

Met impliciete TLS op poort 993 voltooi die TLS-handshake voordat enige IMAP-opdrag gestuur word, en daarom lewer 'n sertifikaatprobleem 'n fout wat vertroue eerder as pos noem. Die pos-gasheernaam moet teen die sertifikaat valideer net soos 'n web-gasheernaam doen; 'n tonnel wat verkeer bewaar, maak nie 'n ongeldige sertifikaat geldig nie.

Die foutteks skei die gevalle. 'n Verbindingstydlimiet beteken die SYN het nooit voltooi nie. 'n TLS-fout beteken die TCP-verbinding het gewerk en die handshake nie. 'n IMAP NO of BAD-antwoord beteken albei daardie dinge het geslaag en die protokol-laag het iets verwerp. Teken aan watter een jy gesien het voordat jy enige instelling verander.

Gekasde pos is nie bewys van enigiets nie

'n Poskliënt wys voorheen afgelaaide boodskappe of dit vandag die bediener kan bereik of nie, so 'n inkassie wat wys, sê jou net dat plaaslike berging werk. Enige werklike toets moet 'n bedienerbewerking forseer: verfris 'n gids, haal 'n boodskap wat nooit afgelaai is nie, of stuur 'n opdrag wat die kliënt net sou uitvoer nadat hy die posbus gekies het.

Gebruik 'n nie-vernietigende toets. Om een gids te verfris en die rekening se foutlog te lees, is beter as om die rekening te skrap en weer by te voeg, wat meestal net bewys dat die konfigurasieskerm nog werk.

Stuur en webpos is verskillende protokolle

Om pos te stuur is indiening, nie IMAP nie. Dit gebruik 'n aparte diens en gewoonlik 'n aparte poort met sy eie TLS-modus en sy eie verifikasie, so 'n werkende uitboks bewys nie dat die IMAP-posbus gekies is nie, en 'n stukkende uitboks impliseer nie IMAP nie.

Webpos is weer anders. Dit kan oor dieselfde VPN slaag omdat dit 'n HTTPS-sessie teen 'n web-frontend is, wat niks sê oor die lessenaarkliënt se IMAP-gasheer, poort of TLS-modus nie.

Vir 'n oorhandiging, teken vier resultate afsonderlik aan: die VPN-pad, die pos-eindpunt en TLS-resultaat, die rekeningverifikasie-resultaat, en die posbuskeuse-resultaat. Hou geloofsbriewe en boodskapinhoud uit die nota. Daardie rekord vertel die volgende persoon of die regstelling aan die netwerk, die sertifikaat, die rekening of die gidskonfigurasie behoort, sonder om enige beskermingslaag te verswak.