Din iPhone-VPN-lås är en policy, inte protokollet

VPN-ikonen visar ansluten, tunneln faller ett ögonblick vid ett nätverksbyte, och trafik som borde ha blockerats går ut över mobilnätet. Inget i gränssnittet aviserade en lucka. Funktionen du förlitade dig på är en policy för klienten och plattformen, och ett protokollnamn i inställningarna beskriver inte vad som händer under den sekunden.

Beskriv låset som ett kontrakt om tillstånd, inte som en egenskap hos IKEv2 eller On Demand.

Symtomet: ikonen säger ansluten

En ikon speglar klientens syn på sitt eget tillstånd, och den synen kan ligga efter verkligheten med längden av en återanslutning. En cachad sida, en snabb återanslutning eller en statusuppdatering döljer alla intervallet. Frågan som är värd att ställa är inte om ikonen var grön, utan vad enheten tillät medan tunneln saknades. Samma fördröjning förklarar varför en skärmbild av appen är så svagt bevis: den registrerar ett tillstånd, inte en övergång.

Den frågan har bara ett svar om policyn definierar den.

Vad protokollet faktiskt upprätthåller

IKEv2 upprätthåller och förnyar en autentiserad IPsec-relation, och mobilitetsfunktioner hjälper till att återställa den efter en adressändring. Det är ett påstående om tunnelns livscykel. Det säger ingenting om iPhonens tillstånd att skicka annan trafik i luckan, för det tillståndet tillhör plattformen och klienten, inte nyckelutbytet. En enhet som återansluter på under en sekund hade ändå ett fönster, och det är i det fönstret det intressanta beteendet bor.

On Demand är på samma sätt en beskrivning av aktiveringsbeteende, inte en universell blockeringsgaranti.

Vad plattformen erbjuder en utvecklare

Apples Network Extension exponerar kontroller för trafikomfattning, och dess routningsguide skiljer beteendet med alla nätverk inkluderade från vanliga inkluderade rutter och listar systemundantagen. Det finns också en övervakad Always On-distributionsmodell, skild från en personlig apps inställning för automatisk anslutning. Om en viss app använder något av detta är en egenskap hos appen, inte hos protokollet den talar.

Namnet på en växel är inte bevis för vilket API appen anropar.

Läs funktionen som ett kontrakt

Be leverantören ange fem tillstånd: inledande aktivering, oväntat tunnelbortfall, avsiktlig frånkoppling, avslut av appen och omstart av enheten. Sätt systemundantagen och all avsiktlig LAN-åtkomst bredvid den listan. Fråga sedan om funktionen är valfri, påtvingad av hantering eller beroende av ett klientläge, för en paus som användaren väljer och ett lås som en organisation tvingar fram är två olika produkter. Skriv de fem svaren i distributionsjournalen, för nästa granskare kommer att ställa exakt de frågorna.

En funktion som blockerar vid oväntat bortfall men inte vid avsiktlig frånkoppling är en sammanhängande design. Det är bara inte den som marknadsföringssidan beskrev.

Så testar du luckorna

Testa en övergång i taget med ofarlig trafik, i den app och adressfamilj du bryr dig om. Bekräfta vad som tilläts i luckan, inte vad ikonen visade efteråt. Anteckna klientversionen och policyn bredvid resultatet, för båda ändras och ingen av dem syns från telefonens inställningsskärm. Det är det enda sättet att skilja en verklig lucka från en långsam ikon.

Om svaret spelar roll för efterlevnad, begär det skriftligt i stället för att härleda det från ett produktnamn.