iPhone-VPN per domene: avgjør hvor avvisningen skjer
NeverConnect hindrer VPN i å starte; det blokkerer ikke et nettsted. Avgjør om avvisningen hører til tjenestegrensen eller til en administrert policy.
To krav skrives ned som én setning og implementeres deretter på helt forskjellige steder. Dette nettstedet skal bare være tilgjengelig via VPN er en uttalelse om adgang, og dens naturlige hjem er nettverket foran tjenesten. Denne iPhone skal aldri kontakte det domenet direkte er en uttalelse om enheten, og bare en administrert klientpolicy kan uttrykke den. Avgjør hvilken av dem du faktisk har før du åpner en profilredigering.
To krav som høres identiske ut
Ta den illustrerende verten records.corp.example. I adgangstilfellet publiserer du den bare til adresser bak VPN, så et direkte forsøk fra en telefon på mobilnett feiler i nettverket, mens den samme forespørselen gjennom tunnelen lykkes og fortsatt krever en ekte kontopålogging. I enhetstilfellet kan telefonen nå det offentlige internettet, så verten løses opp og svarer alle, og det eneste stedet å stoppe forsøket er på enheten. Tjenesten kan ikke håndheve en regel om en forespørsel som aldri når den.
Feillesing av kravet viser seg som en bestemt utrulling. Oppføringen er fortsatt offentlig, operatøren tror VPN er obligatorisk, og en revisjon av et mobilforsøk viser at forespørselen aldri kom inn i tunnelen. Ingenting i loggene ser ødelagt ut, fordi ingenting ble blokkert.
Les evalueringshandlingene bokstavelig
On-demand-maskineriet har to separate handlingslag, og å blande dem skaper det meste av forvirringen her. Den ytre regelhandlingen avgjør hva som skjer med tunnelen når regelen passer, og tilkoblingsevalueringshandlingen avgjør hva som skjer med en vertsnavnmatch inne i en evalueringsregel. Apples Never Connect-referanse beskriver bare det andre laget.
| Layer | Action | What it controls |
|---|---|---|
| Outer rule | connect | Bring the tunnel up when the rule matches |
| Outer rule | disconnect | Tear the tunnel down when the rule matches |
| Outer rule | evaluateConnection | Run a hostname evaluation instead of acting directly |
| Outer rule | ignore | Leave the current tunnel state alone |
| Connection evaluation | connectIfNeeded | Start the tunnel when the hostname cannot be resolved |
| Connection evaluation | neverConnect | Do not start the tunnel for that match |
neverConnect er verdien som oftest leses feil, fordi navnet antyder en blokkering. Den styrer start av tunnelen for et matchet vertsnavn, ikke telefonens tillatelse til å nå et navn, så en Never Connect-oppføring er ikke en domeneblokkering. Å kalle den det i et designdokument er hvordan en utrulling blir godkjent med en håndhevelsesgrense den ikke har.
Når du eier tjenesten, håndhev ved grensen
Å begrense adgang betyr å publisere navnet bare der VPN-stien kan nå det, og deretter teste at den tiltenkte stien fungerer og en annen sti ikke gjør det. Dekk hver publiserte oppføring, begge adressefamilier hvis du publiserer dem, og ethvert mellom- eller alternativt navn appen bruker. En gammel CNAME som fortsatt peker på en offentlig lastbalanserer holder den direkte stien i live, uansett hvor ryddig hovedoppføringen er.
Dette beskytter tjenesten fremfor enheten. Det hindrer ikke telefonen i å sende en DNS-forespørsel, og det hindrer ikke appen i å prøve. Hvis disse forsøkene er akseptable, er håndhevelse ved grensen det billigere og mer varige valget, fordi det gjelder for hver klient og ikke bare de du konfigurerte. Det overlever også en telefon som aldri ble registrert.
Når telefonen ikke engang skal prøve, trenger du en administrert policy
Å stoppe forsøket krever en støttet håndhevelsespolicy som dekker appen eller destinasjonene før tilkobling, under en tunnelfeil og etter en nettverksendring. Be VPN- eller enhetsadministrasjonsleverandøren navngi den policyen, si om den krever organisatorisk administrasjon, og beskrive hva annet den påvirker. En tunnel per app pluss en on-demand-regel er ikke det samme, og en snarvei på startskjermen til en tilkobling er heller ikke det.
Test feiltilfellet ved å deaktivere tunnelen og se om forespørselen går ut. Hvis den gjør det, er grensen du dokumenterte ikke grensen du rullet ut.
Avgjør med tre spørsmål
For det første, kontrollerer du tjenesten eller bare telefonen? For det andre, kan enheten lovlig bruke det offentlige internettet til alt annet? For det tredje, er telefonen administrert, og av hvem? Å eie tjenesten pluss en administrert flåte betyr at begge lag er tilgjengelige, mens å eie bare telefonen gjør klientpolicyen til det eneste alternativet, og den må være støttet.
Svar på de tre før du rører en profil. Da slutter konfigurasjonen å være en gjetning på hva en avkrysningsboks kalt Never betyr.