To krav blir skrivne ned som éin setning og deretter implementerte på heilt ulike stader. Dette nettstaden skal berre vere tilgjengeleg via VPN er ei utsegn om tilgang, og den naturlege heimen er nettet framfor tenesta. Denne iPhone skal aldri kontakte det domenet direkte er ei utsegn om eininga, og berre ein styrt klientpolicy kan uttrykke henne. Avgjer kva for ein du faktisk har før du opnar ein profilredigerar.

To krav som høyrest like ut

Ta den illustrerande verten records.corp.example. I tilgangstilfellet publiserer du han berre til adresser bak VPN, så eit direkte forsøk frå ein telefon på mobilnett feilar i nettet, medan den same førespurnaden gjennom tunnelen lukkast og framleis krev ei ekte kontopålogging. I einingstilfellet kan telefonen nå det opne internettet, så verten blir løyst opp og svarar alle, og den einaste staden å stoppe forsøket er på eininga. Tenesta kan ikkje handheve ei regel om ein førespurnad som aldri når henne.

Feillesing av kravet viser seg som ei bestemd utrulling. Oppføringa er framleis open, operatøren trur VPN er obligatorisk, og ein revisjon av eit mobilforsøk viser at førespurnaden aldri kom inn i tunnelen. Ingenting i loggane ser øydelagt ut, fordi ingenting vart blokkert.

Les evalueringshandlingane bokstaveleg

On-demand-maskineriet har to separate handlingslag, og å blande dei skaper det meste av forvirringa her. Den ytre regelhandlinga avgjer kva som skjer med tunnelen når regelen passar, og tilkoblingsevalueringshandlinga avgjer kva som skjer med ein vertsnamnmatch inne i ein evalueringsregel. Apples Never Connect-referanse skildrar berre det andre laget.

LayerActionWhat it controls
Outer ruleconnectBring the tunnel up when the rule matches
Outer ruledisconnectTear the tunnel down when the rule matches
Outer ruleevaluateConnectionRun a hostname evaluation instead of acting directly
Outer ruleignoreLeave the current tunnel state alone
Connection evaluationconnectIfNeededStart the tunnel when the hostname cannot be resolved
Connection evaluationneverConnectDo not start the tunnel for that match

neverConnect er verdien som oftast blir lesen feil, fordi namnet antydar ei blokkering. Han styrer start av tunnelen for eit matcha vertsnamn, ikkje løyvet til telefonen til å nå eit namn, så ei Never Connect-oppføring er ikkje ei domeneblokkering. Å kalle henne det i eit designdokument er korleis ei utrulling blir godkjend med ei handhevingsgrense ho ikkje har.

Når du eig tenesta, handhev ved grensa

Å avgrense tilgang betyr å publisere namnet berre der VPN-stien kan nå det, og deretter teste at den tiltenkte stien fungerer og ein annan sti ikkje gjer det. Dekk kvar publiserte oppføring, begge adressefamiliane om du publiserer dei, og eitkvart mellom- eller alternativt namn appen brukar. Ein gammal CNAME som framleis peikar på ein open lastbalansar held den direkte stien i live, uansett kor ryddig hovudoppføringa er.

Dette vernar tenesta framfor eininga. Det hindrar ikkje telefonen i å sende ein DNS-førespurnad, og det hindrar ikkje appen i å prøve. Om desse forsøka er akseptable, er handheving ved grensa det billigare og meir varige valet, fordi det gjeld for kvar klient og ikkje berre dei du konfigurerte. Det overlever òg ein telefon som aldri vart registrert.

Når telefonen ikkje eingong skal prøve, treng du ein styrt policy

Å stoppe forsøket krev ein støtta handhevingspolicy som dekkjer appen eller destinasjonane før tilkobling, under ein tunnelfeil og etter ei nettverksendring. Be VPN- eller einingadministrasjonsleverandøren namngje den policyen, seie om han krev organisatorisk administrasjon, og skildre kva anna han påverkar. Ein tunnel per app pluss ein on-demand-regel er ikkje det same, og ein snarveg på startskjermen til ei tilkobling er heller ikkje det.

Test feiltilfellet ved å deaktivere tunnelen og sjå om førespurnaden går ut. Om han gjer det, er grensa du dokumenterte ikkje grensa du rulla ut.

Avgjer med tre spørsmål

For det første, kontrollerer du tenesta eller berre telefonen? For det andre, kan eininga lovleg bruke det opne internettet til alt anna? For det tredje, er telefonen styrt, og av kven? Å eige tenesta pluss ein styrt flåte betyr at begge lag er tilgjengelege, medan å eige berre telefonen gjer klientpolicyen til det einaste alternativet, og han må vere støtta.

Svar på dei tre før du rører ein profil. Då sluttar konfigurasjonen å vere ei gjetting på kva ein avkryssingsboks kalla Never tyder.

Relaterte artiklar