Poșta ajunge la server fără VPN: unde se aplică regula

Poșta continuă să întrebe, iar VPN-ul este oprit, dar contul se sincronizează în continuare. Aplicația face ceea ce a fost configurată să facă; nimic într-un profil de poștă normal nu spune că serverul este accesibil doar prin tunel. Asta lasă două cerințe diferite, iar confundarea lor este ușoară: serviciul ar trebui să refuze clienții direcți, sau Mac-ul nu ar trebui să încerce deloc.

Alegeți cerința înainte de a alege un produs. O regulă de server și o regulă de client eșuează în locuri diferite, produc dovezi diferite și aparțin unor proprietari diferiți. Aplicarea ambelor este valabilă când ambele afirmații sunt adevărate, dar una nu o înlocuiește pe cealaltă. Ambele cerințe sunt legitime; pur și simplu nu sunt același control.

Simptomul arată ca Mac-ul, dar serverul poate fi scurgerea

Când poșta se sincronizează în afara tunelului, începeți cu ceea ce acceptă serverul. Dacă ascultătorul de poștă răspunde la o conexiune directă din internet, nicio setare de confort din partea clientului nu schimbă acest fapt. Mac-ul se comportă normal față de un serviciu care este încă deschis.

Întrebați administratorul de poștă ce adresă de sursă vede serviciul. Un gateway VPN, un proxy invers sau un echilibrator de încărcare pot traduce adresa clientului, așa că grupul de adrese din configurația VPN poate să nu corespundă cu ceea ce ajunge la procesul de poștă. O regulă scrisă împotriva sursei greșite fie blochează pe toată lumea, fie pe nimeni.

Acest răspuns spune și dacă serviciul poate distinge clienții VPN. Dacă fiecare client ajunge prin aceeași adresă de proxy, admiterea bazată pe sursă nu îi poate separa, iar cerința trebuie mutată la autentificare sau la partea clientului.

Admitere pe server: refuzați sursa, nu aplicația

Un firewall de gazdă sau de rețea poate restricționa ascultătorul de poștă la intervale de sursă aprobate, lăsând autentificarea și TLS neschimbate. O condiție de regulă care potrivește adrese la distanță, subrețele sau intervale este blocul de construcție obișnuit; sintaxa exactă aparține produsului de firewall al serverului, nu aplicației de poștă.

Aceasta este cea mai puternică frontieră când cerința este „serviciul nu trebuie să deservească clienți direcți”. Rezistă chiar dacă utilizatorul instalează alt client de poștă, pentru că refuzul are loc înainte de autentificare. Rezistă și la un Mac care își ignoră politica VPN.

Limita ei este la fel de importantă. O conexiune refuzată dovedește că serviciul a refuzat sesiunea; nu dovedește că Mac-ul nu a încercat. Rezolvarea DNS, un TCP SYN către un echilibrator de încărcare anterior și o reîncercare după eșec se pot întâmpla toate înainte de a se ajunge la regula serverului. Dacă cerința privește divulgarea încercărilor și nu accesul, admiterea pe server este doar jumătate din control.

Aplicare pe client: blocați încercarea, nu doar tunelul

O regulă din partea clientului trebuie să interzică traficul, nu doar să pornească un tunel când se deschide poșta. Un declanșator de activare pentru un domeniu de poștă poate ridica VPN-ul la momentul potrivit, dar nu definește ce se întâmplă cât timp tunelul este oprit sau după ce eșuează.

Folosiți politica de blocare acceptată de produsul de endpoint și delimitați-i domeniul în mod deliberat. O regulă la nivel de aplicație acoperă fiecare cont din acea aplicație de poștă, inclusiv cele personale. O regulă la nivel de destinație trebuie să numească punctele finale IMAP, de trimitere și de autentificare ale contului de muncă, și trebuie să funcționeze în continuare când acele adrese se schimbă.

Acoperiți ambele familii de adrese și sesiunile existente. O politică ce blochează conexiunile IPv4 noi dar lasă IPv6 sau un socket stabilit în pace produce sincronizări intermitente care par aleatorii. Schimbările de rețea și ciclurile de somn fac parte din același test.

Regulile la nivel de aplicație și de destinație au o întindere diferită

O blocare la nivel de aplicație este simplu de gândit: niciun trafic din Poștă nu iese fără tunel. Este și grosieră, pentru că aceeași aplicație poate ține un cont personal care nu are nimic de-a face cu politica. Utilizatorii observă asta primii și o raportează ca pe o aplicație de poștă defectă.

O blocare la nivel de destinație este mai îngustă și mai greu de întreținut. Are nevoie de setul complet de puncte finale folosite de cont, inclusiv serviciile de descoperire și autentificare, și de un proces de actualizare a lor. Lipsește unul și contul funcționează pe jumătate; includeți prea multe și poșta nelegată se oprește.

Alegeți după formularea cerinței. „Acest cont de muncă nu trebuie să se conecteze direct” indică domeniul destinației. „Acest Mac nu trebuie să ruleze poșta în afara VPN” justifică regula mai largă de aplicație, cu condiția ca proprietarul să accepte efectul secundar asupra contului personal.

Testați refuzul și absența separat

Cu un cont de test dedicat, conectați-vă prin VPN și confirmați funcționarea normală. Apoi deconectați-vă și testați de două ori: o dată pentru a vedea dacă serverul refuză autentificarea, și o dată pentru a vedea dacă Mac-ul încearcă vreo conexiune. Sunt observații diferite și aparțin unor jurnale diferite.

Urmăriți dovezile din partea clientului pentru un SYN sau o interogare DNS cât timp sunteți deconectat, și jurnalul serverului pentru o sesiune refuzată sau acceptată. Dacă serverul refuză dar clientul încă încearcă, regula serverului funcționează și regula clientului lipsește. Dacă clientul nu încearcă dar serverul acceptă în continuare alți clienți, frontiera este exact acolo unde ați pus-o.

Notați proprietarul aplicării, adresa de sursă pe care serverul o vede cu adevărat și contul de test folosit. Următoarea schimbare de rețea sau de proxy poate muta acea sursă, iar o notă care numește valoarea observată se verifică mai repede decât încă o rundă de presupuneri.