E-post fungerer uten VPN: går den i hemmelighet gjennom en tunnel?
En Exchange-konto velger ikke en gateway, en protokoll eller en rute. Fastslå utrullingen, den offentlige inngangen, den administrerte VPN-en eller den aktive tunnelen før du antar noe.
E-post fortsetter å komme til en telefon som aldri har vist et VPN-ikon, og den naturlige konklusjonen er at noe usynlig tunellerer den. Vanligvis er det ikke noe usynlig involvert. Å legge til en Exchange-konto velger ikke en gateway, en protokoll, et sertifikat eller en rute, fordi en konto er en tjenesteidentitet og en tunnel er et nettverksoppsett som noen andre har konfigurert. Det nyttige trekket er å fastslå hvilket oppsett du faktisk har, i stedet for å lete etter en tunnel som aldri var der.
Tre oppsett, én identisk skjerm
Alle tre ender med at e-post dukker opp på enheten, og innstillingsskjermen ser lik ut i hvert tilfelle. Det som er forskjellig, er hvem som konfigurerte banen og hvilket bevis som viser at den finnes.
| Arrangement | Who set it up | What proves it |
|---|---|---|
| Approved public mail entry | The service owner, at the publishing layer | A published endpoint reached over TLS with its own authentication |
| Managed app or account VPN | Device management, as explicit policy | A profile binding that traffic to a VPN association |
| Already active tunnel | An always-on service or an earlier manual connect | Tunnel state plus routes and scope that include the mail destination |
Offentlig tilgjengelighet fortjener sin egen setning, fordi den stadig leses feil. En publisert e-posttjeneste er ikke en uautentisert tjeneste, og at e-post er tilgjengelig sier ingenting om hvorvidt resten av bedriftsnettet er det. Dette er separate beslutninger tatt av separate personer.
Hva enhetsadministrasjon faktisk kan binde
Apple-plattformer støtter VPN-regler per app og per e-postdomene, og administrert e-post på iOS eller iPadOS kan bære en kontospesifikk VPN-tilknytning. Den tilknytningen er en klargjøringsinnstilling med en verdi noen har valgt, og det er nettopp derfor den ikke kan utledes ved å skrive inn en e-postadresse og et passord på en telefon.
Android-administrasjon og tredjepartsklienter har sine egne app- og profilkontroller, og ingen av dem er utskiftbare med Apples kontonyttelaster. En policy som finnes på én plattform, må bevisst gjenskapes på en annen. Den reiser ikke med e-postkontoen, og den kommer ikke fordi den samme personen logget på begge. Forventningen om at denne overføringen skjer av seg selv, ligger bak en stor del av plattformovergripende rapporter om at «det virker på telefonen min».
Identitet og transport holdes atskilt
En e-posttjeneste og en VPN kan lovlig dele en katalog eller en identitetsleverandør, og folk leser den felles påloggingen som bevis på en felles sesjon. Det er den ikke. Gjentatt brukernavntekst viser ikke at e-postappen har arvet en VPN-sesjon, og det er ingen grunn til å finne opp urelaterte passord for hver tjeneste.
Begge tjenestene krever sin egen autentisering, på egne vilkår. En vellykket e-postpålogging bør aldri behandles som noe som skal limes inn i en VPN-klient, og en tunnel som kom opp sier ingenting om hvilken konto e-postserveren vil godta. Intune-referansen for e-postprofil er en nyttig illustrasjon her, fordi den behandler VPN-tilknytningen som en egen innstilling og ikke som en egenskap utledet fra kontonavnet.
Fersk synkronisering slår en bufret innboks
En bufret innboks kan se helt sunn ut uten noen gjeldende bane i det hele tatt, og derfor beviser det ingenting å åpne appen og se forrige ukes meldinger. Bruk en godkjent test for fersk synkronisering og les status- eller loggbeviset som følger med.
Kontroller deretter de fire tingene som faktisk avgjør resultatet: tjenestesluttpunktet som er konfigurert, hva oppslageren returnerer, hvilken administrert profil som gjelder, og gjeldende VPN-tilstand. Gjør det i riktig kontekst, fordi en personlig e-postapp med lignende navn ikke styres av arbeidsappens nettverkspolicy og vil oppføre seg annerledes av helt legitime grunner. Å blande disse to kontekstene er hvordan en fungerende konfigurasjon blir rapportert som ødelagt. Det forklarer også de fleste tilfellene der én app adlyder en policy og dens nesten navnebror ignorerer den.
Skriv ned hva du verifiserte
Hvis tilgang skal kreve en tunnel, bør eieren bekrefte både den tillatte private banen og atferden uten den. Hvis tjenesten bevisst er publisert, hold TLS-valideringen, autentiseringen og tilgangskontrollene på plass i stedet for å behandle fraværet av en tunnel som bevis på at e-post er ukryptert.
Støtterekorden bør navngi e-postproduktet, sluttpunktet, kontoens omfang og tilkoblingspolicyen. Identiske passord er ikke bevis for noen av de fire, og det er den vanligste grunnen til at en sak inneholder fire avsnitt og ingen fakta.