E-post når serveren uten VPN: hvor regelen skal håndheves

E-posten fortsetter å spørre, og VPN er nede, men kontoen synkroniseres fortsatt. Appen gjør det den er konfigurert til; ingenting i en vanlig e-postprofil sier at serveren bare er tilgjengelig gjennom tunnelen. Det etterlater to forskjellige krav, og de er lette å blande sammen: tjenesten skal avvise direkte klienter, eller Macen skal aldri forsøke.

Velg kravet før du velger produkt. En serverregel og en klientregel feiler på forskjellige steder, gir forskjellige bevis og tilhører forskjellige eiere. Å bruke begge er gyldig når begge påstandene er sanne, men det ene erstatter ikke det andre. Begge kravene er legitime; de er bare ikke den samme kontrollen.

Symptomet ser ut som Macen, men serveren kan være lekkasjen

Når e-post synkroniseres utenfor tunnelen, start med det serveren godtar. Hvis e-postlytteren svarer på en direkte tilkobling fra internett, endrer ingen bekvemmelighetsinnstilling på klientsiden det faktumet. Macen oppfører seg normalt mot en tjeneste som fortsatt er åpen.

Spør e-postadministratoren hvilken kildeadresse tjenesten ser. En VPN-gateway, omvendt proxy eller lastbalanserer kan oversette klientadressen, så adressepoolen i VPN-konfigurasjonen passer kanskje ikke med det som når e-postprosessen. En regel skrevet mot feil kilde blokkerer enten alle eller ingen.

Det svaret forteller også om tjenesten i det hele tatt kan skille VPN-klienter. Hvis hver klient kommer gjennom samme proxyadresse, kan kildebasert adgang ikke skille dem, og kravet må flyttes til autentisering eller til klientsiden.

Serveradgang: avvis kilden, ikke appen

En verts- eller nettverksbrannmur kan begrense e-postlytteren til godkjente kildeområder mens autentisering og TLS forblir uendret. En regelbetingelse som matcher fjernadresser, subnett eller områder er den vanlige byggeklossen; den nøyaktige syntaksen tilhører serverens brannmurprodukt, ikke e-postappen.

Dette er den sterkeste grensen når kravet er «tjenesten skal ikke betjene direkte klienter». Den holder selv om brukeren installerer en annen e-postklient, fordi avvisningen skjer før autentisering. Den overlever også en Mac som ignorerer VPN-policyen sin.

Grensen er like viktig. En avvist tilkobling beviser at tjenesten avviste økten; den beviser ikke at Macen ikke forsøkte. DNS-oppslag, et TCP SYN til en tidligere lastbalanserer og et nytt forsøk etter feil kan alle skje før serverregelen nås. Hvis kravet handler om å avdekke forsøk og ikke om tilgang, er serveradgang bare halve kontrollen.

Håndheving på klienten: blokker forsøket, ikke bare tunnelen

En regel på klientsiden må forby trafikken, ikke bare starte en tunnel når e-post åpnes. En aktiveringsutløser for et e-postdomene kan heve VPN-en i rett øyeblikk, men den definerer ikke hva som skjer mens tunnelen er nede eller etter at den feiler.

Bruk endpoint-produktets støttede blokkeringspolicy, og avgrens omfanget bevisst. En regel på appnivå dekker hver konto i den e-postappen, også personlige. En regel på destinasjonsnivå må navngi IMAP-, sende- og autentiseringsendepunktene til arbeidskontoen, og den må fortsette å virke når disse adressene endres.

Dekk begge adressefamilier og eksisterende økter. En policy som blokkerer nye IPv4-tilkoblinger men lar IPv6 eller en etablert socket være, gir periodiske synkroniseringer som virker tilfeldige. Nettverksendringer og søvnssykluser er en del av samme test.

Regler på app- og destinasjonsnivå har ulik rekkevidde

En blokkering på appnivå er enkel å tenke gjennom: ingen trafikk fra E-post går ut uten tunnelen. Den er også grov, fordi samme app kan ha en personlig konto som ikke har noe med policyen å gjøre. Brukere merker det først og rapporterer det som en ødelagt e-postapp.

En blokkering på destinasjonsnivå er smalere og vanskeligere å vedlikeholde. Den trenger hele settet med endepunkter kontoen bruker, inkludert oppdagingstjenester og autentisering, og en prosess for å oppdatere dem. Ett mangler, og kontoen virker halvt; tar du med for mange, stopper urelatert e-post.

Velg etter kravers formulering. «Denne arbeidskontoen skal ikke koble til direkte» peker på destinasjonsomfang. «Denne Macen skal ikke kjøre e-post utenfor VPN» begrunner den bredere appregelen, forutsatt at eieren godtar bivirkningen for den personlige kontoen.

Test avvisning og fravær hver for seg

Med en dedikert testkonto, koble til gjennom VPN og bekreft normal drift. Koble deretter fra og test to ganger: én gang for å se om serveren avviser påloggingen, og én gang for å se om Macen i det hele tatt forsøker en tilkobling. Det er forskjellige observasjoner, og de hører i forskjellige logger.

Se etter bevis på klientsiden for et SYN eller en DNS-spørring mens du er frakoblet, og i serverloggen etter en avvist eller godtatt økt. Hvis serveren avviser men klienten fortsatt forsøker, virker serverregelen og klientregelen mangler. Hvis klienten ikke forsøker men serveren fortsatt godtar andre klienter, er grensen nøyaktig der du plasserte den.

Noter eieren av håndhevingen, kildeadressen serveren faktisk ser, og testkontoen som ble brukt. Den neste nettverks- eller proxyendringen kan flytte den kilden, og et notat som navngir den observerte verdien er raskere å sjekke enn enda en runde med gjetting.