iPhone-VPN-låsen din er en policy, ikke protokollen

VPN-ikonet viser tilkoblet, tunnelen faller et øyeblikk under et nettverksbytte, og trafikk som skulle vært blokkert går ut over mobilnettet. Ingenting i grensesnittet varslet et hull. Funksjonen du regnet med, er en klient- og plattformpolicy, og et protokollnavn i innstillingene beskriver ikke hva som skjer i det sekundet.

Beskriv låsen som en kontrakt om tilstander, ikke som en egenskap ved IKEv2 eller On Demand.

Symptomet: ikonet sier tilkoblet

Et ikon gjenspeiler klientens syn på sin egen tilstand, og det synet kan henge etter virkeligheten med lengden av en gjenoppkobling. En bufret side, en rask gjenoppkobling eller en statusoppdatering skjuler alle intervallet. Spørsmålet som er verdt å stille, er ikke om ikonet var grønt, men hva enheten tillot mens tunnelen var borte. Den samme forsinkelsen forklarer hvorfor et skjermbilde av appen er så svakt bevis: det registrerer en tilstand, ikke en overgang.

Det spørsmålet har bare et svar hvis policyen definerer det.

Hva protokollen faktisk vedlikeholder

IKEv2 vedlikeholder og fornyer et autentisert IPsec-forhold, og mobilitetsfunksjoner hjelper med å gjenopprette det etter en adresseendring. Det er en uttalelse om tunnelens livssyklus. Den sier ingenting om iPhonens tillatelse til å sende annen trafikk i hullet, for den tillatelsen tilhører plattformen og klienten, ikke nøkkelutvekslingen. En enhet som kobler til igjen på under et sekund, hadde likevel et vindu, og det er i det vinduet den interessante atferden bor.

On Demand er på samme måte en beskrivelse av aktiveringsatferd, ikke en universell blokkeringsgaranti.

Hva plattformen tilbyr en utvikler

Apples Network Extension eksponerer kontroller for trafikkomfang, og dens rutingveiledning skiller atferd med alle nettverk inkludert fra vanlige inkluderte ruter og lister systemunntakene. Det finnes også en overvåket Always On-distribusjonsmodell, atskilt fra en personlig apps innstilling for automatisk tilkobling. Om en gitt app bruker noe av dette, er en egenskap ved appen, ikke ved protokollen den snakker.

Navnet på en bryter er ikke bevis for hvilken API appen kaller.

Les funksjonen som en kontrakt

Be leverandøren angi fem tilstander: innledende aktivering, uventet tap av tunnelen, bevisst frakobling, avslutning av appen og omstart av enheten. Sett systemunntakene og enhver tilsiktet LAN-tilgang ved siden av den listen. Spør deretter om funksjonen er valgfri, håndhevet av administrasjon eller betinget av en klientmodus, for en pause valgt av brukeren og en lås en organisasjon tvinger frem, er to forskjellige produkter. Skriv de fem svarene i distribusjonsjournalen, for neste gjennomgang vil stille nøyaktig de spørsmålene.

En funksjon som blokkerer ved uventet tap, men ikke ved bevisst frakobling, er et sammenhengende design. Det er bare ikke det markedsføringssiden beskrev.

Slik tester du hullene

Test én overgang om gangen med ufarlig trafikk, i appen og adressefamilien du bryr deg om. Bekreft hva som ble tillatt i hullet, ikke hva ikonet viste etterpå. Noter klientversjonen og policyen ved siden av resultatet, for begge endres, og ingen av dem er synlige fra telefonens innstillingsskjerm. Det er den eneste måten å skille et reelt hull fra et tregt ikon.

Hvis svaret betyr noe for etterlevelse, be om det skriftlig i stedet for å utlede det fra et produktnavn.