E-post når serveren utan VPN: kvar regelen skal handhevast

E-posten held fram med å spørje, og VPN er nede, men kontoen synkroniserer framleis. Appen gjer det han er konfigurert til; ingenting i ein vanleg e-postprofil seier at serveren berre er tilgjengeleg gjennom tunnelen. Det lèt att to ulike krav, og dei er lette å blande saman: tenesta skal avvise direkte klientar, eller Macen skal aldri freiste.

Vel kravet før du vel produkt. Ein serverregel og ein klientregel feilar på ulike stader, gir ulike bevis og høyrer til ulike eigarar. Å bruke begge er gyldig når begge påstandane er sanne, men den eine erstattar ikkje den andre. Begge krava er legitime; dei er berre ikkje den same kontrollen.

Symptomet ser ut som Macen, men serveren kan vere lekkasjen

Når e-post synkroniserer utanfor tunnelen, start med det serveren godtek. Viss e-postlyttaren svarar på ei direkte tilkopling frå internett, endrar inga komfortinnstilling på klientsida det faktumet. Macen oppfører seg normalt mot ei teneste som framleis er open.

Spør e-postadministratoren kva kjeldeadresse tenesta ser. Ein VPN-gateway, omvend proxy eller lastbalansar kan omsetje klientadressa, så adressepoolen i VPN-konfigurasjonen passar kanskje ikkje med det som når e-postprosessen. Ein regel skriven mot feil kjelde blokkerer anten alle eller ingen.

Det svaret fortel òg om tenesta i det heile kan skilje VPN-klientar. Viss kvar klient kjem gjennom same proxyadresse, kan kjeldebasert tilgang ikkje skilje dei, og kravet må flyttast til autentisering eller til klientsida.

Serveradgang: avvis kjelda, ikkje appen

Ein verts- eller nettverksbrannmur kan avgrense e-postlyttaren til godkjende kjeldeområde medan autentisering og TLS er uendra. Eit regelvilkår som matchar fjernadresser, subnett eller område er den vanlege byggeklossen; den nøyaktige syntaksen høyrer til brannmurproduktet til serveren, ikkje e-postappen.

Dette er den sterkaste grensa når kravet er «tenesta skal ikkje betene direkte klientar». Ho held sjølv om brukaren installerer ein annan e-postklient, fordi avvisinga skjer før autentisering. Ho overlever òg ein Mac som ignorerer VPN-policyen sin.

Grensa er like viktig. Ei avvist tilkopling bevisar at tenesta avviste økta; ho bevisar ikkje at Macen ikkje freista. DNS-oppslag, eit TCP SYN til ein tidlegare lastbalansar og eit nytt forsøk etter feil kan alle skje før serverregelen blir nådd. Viss kravet handlar om å avdekkje forsøk og ikkje om tilgang, er serveradgang berre halve kontrollen.

Handheving på klienten: blokker forsøket, ikkje berre tunnelen

Ein regel på klientsida må forby trafikken, ikkje berre starte ein tunnel når e-post blir opna. Ein aktiveringsutløysar for eit e-postdomene kan heve VPN-en i rett augneblink, men han definerer ikkje kva som skjer medan tunnelen er nede eller etter at han feilar.

Bruk den støtta blokkeringspolicyen til endepunktproduktet, og avgrens omfanget med vilje. Ein regel på appnivå dekkjer kvar konto i den e-postappen, òg personlege. Ein regel på målnyå må namngi IMAP-, sende- og autentiseringsendepunkta til arbeidskontoen, og han må halde fram med å verke når desse adressene endrar seg.

Dekk begge adressefamiliane og eksisterande økter. Ein policy som blokkerer nye IPv4-tilkoplingar men lèt IPv6 eller ein etablert socket vere, gir periodiske synkroniseringar som verkar tilfeldige. Nettverksendringar og svevnsyklusar er del av den same testen.

Reglar på app- og målnyå har ulik rekkevidd

Ei blokkering på appnivå er enkel å tenkje gjennom: ingen trafikk frå E-post går ut utan tunnelen. Ho er òg grov, fordi same app kan ha ein personleg konto som ikkje har noko med policyen å gjere. Brukarar merkar det først og rapporterer det som ein øydelagd e-postapp.

Ei blokkering på målnyå er smalare og vanskelegare å vedlikehalde. Ho treng heile settet med endepunkt som kontoen brukar, inkludert oppdagings- og autentiseringstenester, og ein prosess for å oppdatere dei. Eitt manglar, og kontoen verkar halvt; tar du med for mange, stoppar urelatert e-post.

Vel etter formuleringa av kravet. «Denne arbeidskontoen skal ikkje kople til direkte» peikar på målomfang. «Denne Macen skal ikkje køyre e-post utanfor VPN» grunngir den breiare appregelen, føresett at eigaren godtek biverknaden for den personlege kontoen.

Test avvising og fråvær kvar for seg

Med ein dedikert testkonto, kople til gjennom VPN og stadfest normal drift. Kople deretter frå og test to gonger: éin gong for å sjå om serveren avviser pålogginga, og éin gong for å sjå om Macen i det heile freistar ei tilkopling. Det er ulike observasjonar, og dei høyrer i ulike loggar.

Sjå etter bevis på klientsida for eit SYN eller ei DNS-førespurnad medan du er fråkopla, og i serverloggen etter ei avvist eller godteken økt. Viss serveren avviser men klienten framleis freistar, verkar serverregelen og klientregelen manglar. Viss klienten ikkje freistar men serveren framleis godtek andre klientar, er grensa nøyaktig der du plasserte ho.

Noter eigaren av handhevinga, kjeldeadressa serveren faktisk ser, og testkontoen som vart brukt. Den neste nettverks- eller proxyendringa kan flytte den kjelda, og eit notat som namngir den observerte verdien er raskare å sjekke enn endå ein runde med gissing.