iPhone-VPN pr. domæne: afgør, hvor afvisningen sker
NeverConnect forhindrer VPN i at starte; det blokerer ikke et websted. Afgør, om afvisningen hører til tjenestens grænse eller i en administreret politik.
To krav skrives ned som én sætning og implementeres derefter helt forskellige steder. Dette websted må kun være tilgængeligt via VPN er en udtalelse om adgang, og dens naturlige hjem er netværket foran tjenesten. Denne iPhone må aldrig kontakte det domæne direkte er en udtalelse om enheden, og kun en administreret klientpolitik kan udtrykke den. Afgør, hvilken af dem du faktisk har, før du åbner en profilredigering.
To krav, der lyder ens
Tag den illustrerende vært records.corp.example. I adgangstilfældet udgiver du den kun til adresser bag VPN, så et direkte forsøg fra en telefon på mobilnetværk fejler i netværket, mens den samme anmodning gennem tunnelen lykkes og stadig kræver et rigtigt kontologin. I enhedstilfældet kan telefonen nå det offentlige internet, så værten opløses og svarer alle, og det eneste sted at stoppe forsøget er på enheden. Tjenesten kan ikke håndhæve en regel om en anmodning, der aldrig når den.
Fejllæsning af kravet viser sig som en bestemt udrulning. Posten er stadig offentlig, operatøren tror, at VPN er obligatorisk, og en revision af et mobilforsøg viser, at anmodningen aldrig kom ind i tunnelen. Intet i logfilerne ser ødelagt ud, fordi intet blev blokeret.
Læs evalueringshandlingerne bogstaveligt
On-demand-maskineriet har to forskellige handlingslag, og at blande dem skaber det meste af forvirringen her. Den ydre regelhandling afgør, hvad der sker med tunnelen, når reglen matcher, og forbindelsesevalueringshandlingen afgør, hvad der sker med et værtsnavnematch inde i en evalueringsregel. Apples Never Connect-reference beskriver kun det andet lag.
| 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 den værdi, der oftest læses forkert, fordi navnet antyder en blokering. Den styrer start af tunnelen for et matchet værtsnavn, ikke telefonens tilladelse til at nå et navn, så en Never Connect-post er ikke en domæneblokering. At kalde den det i et designdokument er, hvordan en udrulning bliver godkendt med en håndhævelsesgrænse, den ikke har.
Når du ejer tjenesten, håndhæv ved grænsen
At begrænse adgang betyder at udgive navnet kun der, hvor VPN-stien kan nå det, og derefter teste, at den tilsigtede sti virker, og en anden sti ikke gør. Dæk hver udgivet post, begge adressefamilier, hvis du udgiver dem, og ethvert mellem- eller alternativt navn, som appen bruger. En gammel CNAME, der stadig peger på en offentlig load balancer, holder den direkte sti i live, uanset hvor pæn hovedposten er.
Dette beskytter tjenesten frem for enheden. Det forhindrer ikke telefonen i at sende en DNS-forespørgsel, og det forhindrer ikke appen i at forsøge. Hvis disse forsøg er acceptable, er grænsehåndhævelse det billigere og mere holdbare valg, fordi det gælder for hver klient i stedet for kun dem, du konfigurerede. Det overlever også en telefon, der aldrig blev tilmeldt.
Når telefonen ikke engang må forsøge, har du brug for en administreret politik
At stoppe forsøget kræver en understøttet håndhævelsespolitik, der dækker appen eller destinationerne før forbindelse, under en tunnelfejl og efter en netværksændring. Bed VPN- eller enhedsadministrationsudbyderen om at navngive den politik, sige, om den kræver organisatorisk administration, og beskrive, hvad den ellers påvirker. En tunnel pr. app plus en on-demand-regel er ikke det samme, og det er en genvej på startskærmen til en forbindelse heller ikke.
Test fejltilfældet ved at deaktivere tunnelen og se, om anmodningen går ud. Hvis den gør, er den grænse, du dokumenterede, ikke den grænse, du udrullede.
Afgør med tre spørgsmål
For det første, styrer du tjenesten eller kun telefonen? For det andet, må enheden legitimt bruge det offentlige internet til alt andet? For det tredje, er telefonen administreret, og af hvem? At eje tjenesten plus en administreret flåde betyder, at begge lag er tilgængelige, mens at eje kun telefonen gør klientpolitikken til den eneste mulighed, og den skal være understøttet.
Svar på de tre, før du rører en profil. Så holder konfigurationen op med at være et gæt på, hvad en afkrydsningsboks ved navn Never betyder.