Pyetni një aplikacion iOS nëse telefoni është në një VPN, dhe përgjigjja e sinqertë është se ai nuk mund ta dijë atë në kuptimin që keni parasysh. SDK nuk ekspozon asnjë flamur për «pajisja është në një tunel», dhe ndërfaqet private që mund t'i afroheshin kësaj janë të mbyllura për aplikacionet që publikohen. Mund të vëzhgoni konfigurimin e vetë aplikacionit tuaj, gjendjen e lidhur me të, dhe një ose dy tregues indirektë nga stiva e rrjetit. Secili përgjigjet një pyetjeje tjetër, dhe shumica e kontrolleve të prishura vijnë nga marrja e njërit prej tyre si përgjigje e plotë.

Miti i flamurit të vetëm të VPN

Besimi është se diku në SDK ekziston një veti që raporton nëse pajisja është në një tunel, ashtu si një flamur arritshmërie raporton nëse një host përgjigjet. Një veti e tillë publike nuk ekziston. Dhe edhe sikur të ekzistonte, «ekziston një tunel» dhe «trafiku im e përdor atë» janë pohime të ndryshme, dhe për shumicën e aplikacioneve rëndësi ka vetëm i dyti.

Pikërisht ky hendek është arsyeja pse bibliotekat që reklamojnë një zbulues VPN një-rresht lexojnë zakonisht diçka të brishtë, si emri i një ndërfaqeje ose një çelës proxy, dhe e paraqesin atë si verdikt.

Ngarkoni preferencat përpara se t'i besoni një nil

Instanca e përbashkët e menaxherit ekziston sapo ta kërkoni, por vetia e protokollit të saj mbetet nil derisa të përfundojë callback-u i ngarkimit. Pra një protokoll nil nënkupton «ende i pangarkuar» të paktën po aq shpesh sa nënkupton «i pa instaluar». Bëni leximin brenda bllokut të përfundimit, dhe vetëm pastaj vendosni: një objekt protokolli që ekziston, me flamurin e aktivizimit të ndezur, kështu duket «i instaluar».

Një sinjal i dytë qëndron në objektin e lidhjes: gjendja e pavlefshme, të cilën sistemi e raporton kur ky aplikacion nuk ka asnjë konfigurim të instaluar. Një gjendje e pavlefshme së bashku me një protokoll nil pas një ngarkimi të përfunduar është mungesë e vërtetë, jo garë kohore.

Ndryshimet e lidhjes vijnë si njoftime

Trajtuesit e dhënë load dhe save raportojnë çfarë ndodhi me konfigurimin, jo çfarë po bën tuneli. Pritja që njëri prej tyre të aktivizohet në momentin e lidhjes është një garë që nuk zgjidhet kurrë. Në vend të kësaj vëzhgoni njoftimin e ndryshimit të statusit dhe lexoni vlerën aktuale të objektit të lidhjes kur ai arrin.

Pasi një konfigurim është instaluar, gjendja e lidhjes kalon një sekuencë të shkurtër: i shkëputur, po lidhet, i lidhur, po rikonfirmon, po shkëputet. «I lidhur» përshkruan tunelin dhe jo serverin pas tij, pra nuk është provë që trafiku rrjedh. On-demand mund të ngrejë një tunel edhe kur aplikacioni është i pezulluar, dhe atëherë njoftimi arrin përpara se të keni diçka për të përditësuar.

Pamja e kufizuar e proxy-t është një tregues, jo një verdikt

CFNetwork mund t'i japë aplikacionit cilësimet aktuale të proxy-t të sistemit, dhe brenda atij rezultati ka një fjalor të kufizuar me çelës sipas emrit të ndërfaqes. Të shohësh një emër që fillon me tun, utun, ppp, ipsec ose tap është një tregues se ekziston një tunel. Mbetet një pamje e asaj që ky aplikacion mund të shohë, jo një deklaratë për atë se ku udhëtojnë paketat.

Ofruesit nuk bien dakord për emërtimin, kështu që një parashtesë që mungon nuk provon asgjë, dhe një ndërfaqe e pranishme mund të ekzistojë pa mbajtur trafik. Arritshmëria është edhe më e dobët: një kërkesë e suksesshme drejt një adrese private tregon se rruga funksionoi për atë kërkesë në atë moment, jo se është instaluar një VPN.

Simulatori huazon Mac-in, dhe aplikacionet e tjera mbeten të padukshme

Simulatori nuk ka stivë rrjeti të vetën; çdo lidhje që bën është e Mac-ut. Prandaj një VPN që punon në Mac-in pritës është tashmë në fuqi për aplikacionin e simuluar, dhe cilësimet e vetë simulatorit nuk tregojnë asgjë. Nëse tuneli u ngrit pasi simulatori filloi, rinisja e tij zakonisht është më e shpejtë se korrigjimi i aplikacionit. Një pritës në një port jo standard ka nevojë për atë port në URL, ose për një ridrejtim lokal si socat TCP-LISTEN:12345,fork TCP:host:12345.

API-t publike nuk do të listojnë profile VPN që u përkasin aplikacioneve të tjera ose profileve të konfigurimit. Për një aplikacion të njohur, sonda e skemës së URL përmes canOpenURL është truku i transportueshëm, dhe që nga iOS 9 skema e pyetur duhet të deklarohet në Info.plist; nëse e lini jashtë, thirrja kthen false. OpenVPN Connect përgjigjet në openvpn://, gjë që e bën atë një shembull të mirë dhe një zbulues të përgjithshëm të keq.

Kombinoni tre vëzhgime dhe thoni çfarë nënkuptojnë

Në praktikë grumbulloni tre rezultate: një konfigurim që u ngarkua dhe është i aktivizuar, një gjendje lidhjeje që nuk është e pavlefshme, dhe një kërkesë drejt një adrese të arritshme vetëm përmes tunelit. Secili mashtron vetëm; së bashku thonë atë që aplikacioni mund të dijë dhe jo atë që supozon përdoruesi.

Shkruajeni rezultatin si tre rreshta në diagnostifikimin tuaj, jo si një boolean të vetëm. Kur një përdorues thotë se VPN është e fikur ndërsa aplikacioni juaj nuk pajtohet, tre rreshtat tregojnë cili vëzhgim devijoi, dhe kjo është diferenca midis një tikete mbështetjeje mbi të cilin mund të veproni dhe një tjetri që përfundon me «tek unë funksionon».

Artikuj të ngjashëm