Is die iPhone op 'n VPN? Wat 'n iOS-app werklik kan sien
Daar is geen enkele VPN-vlag in die iOS-SDK nie. 'n App kan sy eie konfigurasie, 'n statuskennisgewing en 'n beperkte proxy-momentopname sien, niks meer nie.
Vra 'n iOS-app of die foon op 'n VPN is, en die eerlike antwoord is dat dit dit nie kan weet op die manier wat jy bedoel nie. Die SDK stel geen vlag beskikbaar vir «toestel is deur 'n tonnel» nie, en die private koppelvlakke wat dit miskien sou benader, is gesluit vir apps wat versend word. Jy kan jou app se eie konfigurasie sien, die toestand wat daaraan gekoppel is, en een of twee indirekte leidrade uit die netwerkstapel. Elkeen antwoord 'n ander vraag, en die meeste stukkende kontroles kom daarvan dat 'n mens een daarvan as die hele antwoord beskou.
Die mite van 'n enkele VPN-vlag
Die oortuiging is dat daar iewers in die SDK 'n eienskap is wat rapporteer of die toestel deur 'n tonnel gaan, soos wat 'n bereikbaarheidsvlag rapporteer of 'n gasheer antwoord. So 'n publieke eienskap bestaan nie. Selfs al het dit bestaan, is «'n tonnel bestaan» en «my verkeer gebruik dit» verskillende bewerings, en net die tweede een maak saak vir die meeste apps.
Daardie gaping is hoekom biblioteke wat adverteer met 'n eenreel-VPN-detektor geneig is om iets broos te lees, soos 'n koppelvlaknaam of 'n proxy-sleutel, en dit as 'n uitspraak voor te hou.
Laai die voorkeure voordat jy 'n nul vertrou
Die gedeelde bestuurder-instansie bestaan sodra jy daarvoor vra, maar sy protokol-eienskap bly nul totdat die laai-terugroep voltooi is. 'n Nul protokol beteken dus «nog nie gelaai nie» minstens so dikwels as wat dit «nie geïnstalleer nie» beteken. Doen die lees binne die voltooiingsblok, en besluit eers dan: 'n protokol-voorwerp wat bestaan, met die geaktiveerde vlag aan, is hoe geïnstalleer lyk.
'n Tweede sein sit op die verbinding-voorwerp: die ongeldige toestand, wat die stelsel rapporteer wanneer hierdie app geen konfigurasie geïnstalleer het nie. Ongeldige status saam met 'n nul protokol ná 'n voltooide laai is 'n werklike afwesigheid, nie 'n wedloop oor tydsberekening nie.
Verbindingsveranderinge kom as kennisgewings
Hanterers wat aan laai en stoor gegee word, rapporteer wat met die konfigurasie gebeur het, nie wat die tonnel doen nie. Om te wag dat een van hulle afvuur tydens die koppeling, is 'n wedloop wat nooit oplos nie. Let eerder op die statusverandering-kennisgewing, en lees die verbinding-voorwerp se huidige waarde wanneer dit opdaag.
Sodra 'n konfigurasie geïnstalleer is, loop die verbindingstoestand deur 'n kort reeks: ontkoppel, koppel tans, gekoppel, herbevestig, ontkoppel tans. Gekoppel beskryf die tonnel en nie die bediener daarachter nie, so dit is nie bewys dat verkeer vloei nie. Op aanvraag kan ook 'n tonnel opbring terwyl die app opgeskort is, en dan land die kennisgewing voordat jy iets het om by te werk.
Die beperkte proxy-momentopname is 'n leidraad, nie 'n uitspraak nie
CFNetwork kan die app die huidige stelsel-proxy-instellings gee, en binne daardie resultaat is 'n beperkte woordeboek wat op koppelvlaknaam gesleutel is. Om 'n naam te sien wat met tun, utun, ppp, ipsec of tap begin, is 'n leidraad dat 'n tonnel teenwoordig is. Dit bly 'n momentopname van wat hierdie app kan sien, nie 'n verklaring oor waar pakkette reis nie.
Verskaffers stem nie saam oor naamgewing nie, so 'n ontbrekende voorvoegsel bewys niks, en 'n teenwoordige koppelvlak kan bestaan terwyl dit geen verkeer dra nie. Bereikbaarheid is nog swakker: 'n suksesvolle versoek na 'n private adres wys dat die pad vir daardie versoek op daardie oomblik gewerk het, nie dat 'n VPN geïnstalleer is nie.
Die simulator leen die Mac, en ander apps bly onsigbaar
Die simulator het geen netwerkstapel van sy eie nie; elke verbinding wat dit maak, is die Mac s'n. 'n VPN wat op die gasheer-Mac loop, is dus reeds in werking vir die gesimuleerde app, en die simulator se eie instellings wys niks. As die tonnel opgekom het nadat die simulator begin het, is dit gewoonlik vinniger om dit te herbegin as om die app te ontfout. 'n Gasheer op 'n nie-standaard poort het daardie poort in die URL nodig, of 'n plaaslike deurvoer soos socat TCP-LISTEN:12345,fork TCP:host:12345.
Publieke API's sal nie VPN-profiele opsom wat aan ander apps of aan konfigurasieprofiele behoort nie. Vir een bekende app is 'n URL-skema-ondersoek deur canOpenURL die oordraagbare truuk, en sedert iOS 9 moet die bevraagde skema in jou Info.plist verklaar word; laat dit uit en die oproep gee onwaar terug. OpenVPN Connect reageer op openvpn://, wat 'n goeie voorbeeld en 'n swak algemene detektor maak.
Kombineer drie waarnemings en sê wat hulle beteken
Stapel drie resultate in die praktyk: 'n konfigurasie wat gelaai en geaktiveer is, 'n verbindingstoestand wat nie ongeldig is nie, en 'n versoek na 'n adres wat net deur die tonnel bereikbaar is. Enige een daarvan mislei alleen; saam sê hulle wat die app kan weet eerder as wat die gebruiker aanneem.
Skryf die resultaat as drie reëls in jou diagnostiek, nie een booleaanse waarde nie. Wanneer 'n gebruiker sê die VPN is af terwyl jou app nie saamstem nie, wys die drie reëls watter waarneming afgewyk het, en dit is die verskil tussen 'n ondersteuningskaartjie waarop jy kan optree en een wat eindig in «dit werk vir my».