iPhonens VPN på forespørsel kobler til kontorets Wi-Fi, ikke mobilnettet
Utestengelsesregelen din finnes og taper likevel. Lister på forespørsel leses ovenfra og ned, så én tidlig regel som fanger alt avgjør morgenen før kontorregelen blir sett.
Klokken ni kobler telefonen seg til kontorets trådløse nett, og tunnelen kommer opp av seg selv og blir der hele dagen. Mobilnettet oppfører seg senere nøyaktig som alle hadde tenkt. Noen la til en utestengelse for bedriftsnettet for uker siden, så profilen ser ren ut ved gjennomgang, og hver morgen gir fortsatt samme resultat. Enheten følger listen den fikk, og listen sier noe annet enn det forfatteren trodde.
Listen leses ovenfra, og det første treffet vinner
Oppføringene vurderes i rekkefølge. Den første der vilkårene gjelder avgjør resultatet for det øyeblikket, og alt under den blir aldri sett på. Rekkefølgen bærer derfor like mye mening som enhver betingelse skrevet inne i en regel. Å lese matrisen ovenfra forklarer en profil som ser ut til å ignorere en utestengelse den tydelig inneholder.
En generell oppføring for trådløs tilkobling plassert over kontorets utestengelse garanterer en tunnel på stedet. Ingenting annet i nyttelasten trenger å flytte seg for at atferden skal snu.
En oppføring for å koble fra gjør to jobber
Når handlingen er Koble fra, lukker oppføringen en økt som allerede kjører og blokkerer en ny så lenge vilkårene holder. Begge halvdelene teller for en utestengelse, og den andre halvdelen blir ofte glemt. Den samme oppføringen i en andre profil forklarer en etasje der VPN nekter å starte mens resten av bygget virker. Ingen rørte tunnelen; listen gjorde det.
Tabellen viser formen, utestengelse først, med navn som må komme fra din egen utrulling. To oppføringer holder vanligvis, og en tredje for mobilnettet gjør resten forutsigbar.
| Order | Action | Conditions |
|---|---|---|
| 1 | Disconnect | Wireless interface plus office network name |
| 2 | Connect | Wireless interface |
| 3 | Connect | Cellular interface |
Behold begge vilkårene på utestengelsen
Par nettverksnavnet med grensesnitttypen. Et navn alene kan utløses på en delt tilkobling med samme etikett, mens en grensesnitttype alene utestenger hvert trådløst nett brukeren besøker den dagen. Begge halvdelene hører til én oppføring, ikke to regler som tilfeldigvis står ved siden av hverandre.
Navnesammenligningen er nøyaktig og skiller mellom store og små bokstaver. Det passer for ett kjent nett og strammer overalt ellers, fordi gjestenett gjenbruker kjente etiketter, steder får nytt navn etter en fusjon, og en kablet pult ikke har noe navn i det hele tatt. Spør nettverksteamet om den nøyaktige etiketten i stedet for å lese den fra et skilt på veggen.
Når en probe slår et navn
En probe-oppføring ber om en URL og leser et vellykket svar som et sant vilkår. Velg en vert som bare svarer innenfra, som en intranettjeneste som ikke kan slås opp offentlig, og regelen slutter å bry seg om hva nettverket kaller seg selv. En probe som svarer fra hvor som helst, tester internett, ikke bygget. Egenskapen som avgjør om dette virker, er at svaret kommer uten omdirigering; en gjestesportal som spretter hver forespørsel gjør proben til støy.
Domenebaserte regler er en egen form: NEEvaluateConnectionRule matcher forespurte domener og kan koble til når et navn slås opp. Jokertegnet godtas bare som den venstreste etiketten, så *.example.com er gyldig mens example.*.com ikke er det. Hvis en profil verken bruker grensesnittvilkår eller tilgjengelighetsprober, sjekk om den i stedet bruker den regeltypen.
Hva regler på forespørsel ikke styrer
Regler velger om en tunnel starter og har ikke noe å si for å holde den i gang. En økt som dukker opp og deretter forsvinner minutter senere, peker på inaktivitetstimere, grensesnittgrenser for økter eller banestørrelsen. Hver av dem etterlater et annet spor, og det er grunnen til å utelukke regellisten før noen av dem endres. Keep-alive-innstillinger forklarer ikke det mønsteret, og å endre dem flytter arbeidet uten å berøre årsaken.
Brukere kan slå av på forespørsel i Innstillinger, og en administrert tildeling kan gjenopprette det ved neste innsjekking. Når bryteren stadig glir tilbake til sin forrige posisjon, er tildelingen den aktive parten. Forskjellen betyr noe, fordi håndhevelse kommer tilbake av seg selv mens et tilbud blir stående av.
Bekreft hvilken profilgruppe som eier enheten og om hensikten er å håndheve tunnelen eller bare tilby den. Det svaret avgjør om brukerens preferanse teller som en feil eller som en funksjon.