iPhone-VPN per domän: avgör var avvisandet sker
NeverConnect hindrar VPN att starta; det blockerar inte en webbplats. Avgör om avvisandet hör till tjänstens gräns eller till en hanterad policy.
Två krav skrivs ner som en mening och implementeras sedan på helt olika ställen. Den här webbplatsen ska bara nås via VPN är ett uttalande om tillträde, och dess naturliga hem är nätverket framför tjänsten. Den här iPhonen ska aldrig kontakta den domänen direkt är ett uttalande om enheten, och bara en hanterad klientpolicy kan uttrycka det. Avgör vilket av dem du faktiskt har innan du öppnar en profilredigerare.
Två krav som låter identiska
Ta den illustrativa värden records.corp.example. I tillträdesfallet publicerar du den bara till adresser bakom VPN, så ett direkt försök från en telefon på mobilnät misslyckas i nätverket, medan samma begäran genom tunneln lyckas och fortfarande kräver en riktig kontoinloggning. I enhetsfallet kan telefonen nå det publika internetet, så värden löses upp och svarar alla, och den enda platsen att stoppa försöket är på enheten. Tjänsten kan inte upprätthålla en regel för en begäran som aldrig når den.
Fel läsning av kravet visar sig som en bestämd utrullning. Posten är fortfarande offentlig, operatören tror att VPN är obligatoriskt, och en granskning av ett mobilförsök visar att begäran aldrig kom in i tunneln. Ingenting i loggarna ser trasigt ut, eftersom ingenting blockerades.
Läs utvärderingsåtgärderna bokstavligt
On-demand-maskineriet har två separata åtgärdslager, och att blanda dem skapar det mesta av förvirringen här. Den yttre regelåtgärden avgör vad som händer med tunneln när regeln matchar, och anslutningsutvärderingsåtgärden avgör vad som händer med en värdnamnsmatchning inuti en utvärderingsregel. Apples Never Connect-referens beskriver bara det andra lagret.
| 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 är det värde som oftast läses fel, eftersom namnet antyder en blockering. Det styr starten av tunneln för ett matchat värdnamn, inte telefonens tillstånd att nå ett namn, så en Never Connect-post är inte en domänblockering. Att kalla det så i ett designdokument är hur en utrullning godkänns med en upprätthållandegräns som den inte har.
När du äger tjänsten, upprätthåll vid gränsen
Att begränsa tillträde innebär att publicera namnet bara där VPN-vägen kan nå det, och sedan testa att den avsedda vägen fungerar och en annan väg inte gör det. Täck varje publicerad post, båda adressfamiljerna om du publicerar dem, och alla mellanliggande eller alternativa namn som appen använder. En gammal CNAME som fortfarande pekar på en offentlig lastbalanserare håller den direkta vägen levande, hur städad huvudposten än är.
Detta skyddar tjänsten snarare än enheten. Det hindrar inte telefonen från att skicka en DNS-förfrågan, och det hindrar inte appen från att försöka. Om dessa försök är acceptabla är upprätthållande vid gränsen det billigare och mer hållbara valet, eftersom det gäller för varje klient och inte bara de du konfigurerade. Det överlever också en telefon som aldrig registrerades.
När telefonen inte ens får försöka behöver du en hanterad policy
Att stoppa försöket kräver en stödd upprätthållandepolicy som täcker appen eller destinationerna före anslutning, under ett tunnelfel och efter en nätverksändring. Be VPN- eller enhetshanteringsleverantören att namnge den policyn, säga om den kräver organisatorisk hantering och beskriva vad mer den påverkar. En tunnel per app plus en on-demand-regel är inte samma sak, och en genväg på startskärmen till en anslutning inte heller.
Testa felet genom att inaktivera tunneln och se om begäran går ut. Om den gör det är gränsen du dokumenterade inte gränsen du rullade ut.
Avgör med tre frågor
För det första, kontrollerar du tjänsten eller bara telefonen? För det andra, får enheten lagligt använda det publika internetet till allt annat? För det tredje, är telefonen hanterad, och av vem? Att äga tjänsten plus en hanterad flotta innebär att båda lagren är tillgängliga, medan att bara äga telefonen gör klientpolicyn till det enda alternativet och den måste stödjas.
Svara på dessa tre innan du rör en profil. Då slutar konfigurationen att vara en gissning om vad en kryssruta som heter Never betyder.