સેન્ડબોક્સ્ડ Mac એપમાં સક્રિય VPN શોધવું
આ પ્રશ્ન માટે કોઈ જાહેર API નથી, અને ઇન્ટરફેસ-નામની યુક્તિ ફક્ત એક હ્યુરિસ્ટિક છે. તમારી એપ ખરેખર શેના પર નિર્ભર હોવી જોઈએ તે નક્કી કરવા છ ચકાસણીઓ.
તમને એક સ્ક્રીનની જરૂર છે જે ટનલ ચાલુ હોય ત્યારે અલગ રીતે વર્તે, અને તમને એ કહેતો કોઈ કૉલ નથી. આ જ શિપિંગ મર્યાદા છે: macOS પર કોઈ જાહેર ફ્રેમવર્ક જણાવતું નથી કે કોઈ મનસ્વી VPN જોડાયેલ છે કે નહીં, અને iOS પર સ્થિતિ એ એપની છે જેણે કન્ફિગરેશન ઇન્સ્ટોલ કર્યું. નીચેની ચકાસણીઓ આ મર્યાદાથી શિપ કરી શકાય તેવી વસ્તુ સુધી લઈ જાય છે, અને તેમાંથી કોઈપણ શોધને વહેલી પૂરી કરી શકે છે.
ચકાસણી 1: શું આ પ્રશ્નનો જવાબ આપી શકાય જ?
સેન્ડબોક્સ કોઈપણ API પહેલાં પ્રશ્નનો નિર્ણય કરે છે. તૃતીય-પક્ષની પ્રક્રિયા બીજા વેન્ડરનું એક્સ્ટેન્શન ગણી શકતી નથી, અને તે એક્સ્ટેન્શનનું કન્ફિગરેશન પણ વાંચી શકતી નથી, તેથી પૂછવા માટે કોઈ સપોર્ટેડ ઑબ્જેક્ટ નથી.
દરેક બાયપાસ સમાન દીવાલ સાથે અથડાય છે. ઇન્ટરફેસ યાદીઓ, scutil --nc list અને સીધા સિસ્ટમ-કન્ફિગરેશન વાંચન કાં તો સેન્ડબોક્સ રોકી રાખે તેવા એન્ટાઇટલમેન્ટની જરૂર પાડે છે અથવા એવા વર્તન પર આધાર રાખે છે જે Appleએ ક્યારેય વચન આપ્યું નથી. જો યોજનાને આમાંથી એકની જરૂર હોય, તો સમસ્યા યોજનામાં જ છે. અપ્રમાણિત વિગત પર બનેલી સુવિધા ડિલિવરી તારીખ સાથેની સપોર્ટ ટિકિટ છે.
ચકાસણી 2: શું તમારી એપ પોતે ટનલનું સંચાલન કરે છે?
જો કરે, તો તમારી પોતાની કન્ફિગરેશન માટે તમારી પાસે સપોર્ટેડ જવાબ છે. પસંદગીઓ લોડ કરો, ભૂલ સંભાળો, પછી સ્થિતિ વાંચો અને પોલિંગ કરવાને બદલે ફેરફારોની સભ્યપદ લો:
vpnManager.loadFromPreferences { error in
// handle a load failure before reading status
}
NotificationCenter.default.addObserver(
forName: .NEVPNStatusDidChange,
object: nil,
queue: nil
) { note in
let status = (note.object as? NEVPNConnection)?.status
}આ શું પરત આપે છે તે અંગે સચોટ રહો: તમે ઇન્સ્ટોલ કરેલી ટનલની સ્થિતિ. બીજું ક્લાયન્ટ ચલાવતો વપરાશકર્તા ડિસ્કનેક્ટેડ દેખાશે, અને તે તમારા કોડમાં બગ નથી. જવાબ પર નિર્માણ કરતા પહેલાં નક્કી કરો કે તમારી સુવિધા આ બેમાંથી કયો પ્રશ્ન ખરેખર પૂછે છે.
ચકાસણી 3: હ્યુરિસ્ટિક ખરેખર તમને શું કહેશે?
વ્યાપકપણે નકલ કરાયેલો અભિગમ સિસ્ટમ પ્રોક્સી શબ્દકોશને તેની સ્કોપ્ડ એન્ટ્રીઓ માટે પૂછે છે અને કી વાંચે છે, જે સંજોગવશાત ઇન્ટરફેસ નામો છે:
let settings = CFNetworkCopySystemProxySettings()?.takeRetainedValue() as NSDictionary?
let scoped = settings?["__SCOPED__"] as? [String: Any]
let names = scoped?.keys ?? []જે કી tap, tun, ppp, ipsec અથવા utun થી શરૂ થાય છે તે સૂચવે છે કે ટનલ-સ્કોપ્ડ ઇન્ટરફેસ હાજર છે. આખું નામ મેળવવું તરત જ નિષ્ફળ જાય છે, કારણ કે iOS 12 utun1 અને utun2 સાથે આવ્યું અને કેટલાક પ્રોફાઇલ ipsec4, ppp0 અથવા utun0 તરીકે દેખાય છે. તેના બદલે પ્રીફિક્સની તુલના કરો.
તેમ છતાં, નામ કોઈ માલિકને ઓળખતું નથી. સિસ્ટમ સુવિધાઓ અને અન્ય વેન્ડરોના એક્સ્ટેન્શન પણ utun ઇન્ટરફેસ બનાવે છે, અને તમારા ટ્રાફિકનું કંઈ પણ વહન ન કરતું એક અસ્તિત્વમાં હોઈ શકે. તેને નજીકમાં ટનલ-આકારનું કંઈક છે તેવા સંકેત તરીકે વાંચો, તેનાથી વધુ નહીં. અહીં ખોટો પોઝિટિવ સસ્તો છે જો તમે ફક્ત એક સુવિધા ગેટ કરો, અને ખર્ચાળ છે જો લોગિન સ્ક્રીન ગેટ કરો.
ચકાસણી 4: શું તમે તેના બદલે ગંતવ્યની પરીક્ષા કરી શકો?
જો એપને ફક્ત એ જાણવાની જરૂર હોય કે આંતરિક સેવા પહોંચી શકાય તેવી છે કે નહીં, તો તે સેવાની પરીક્ષા કરો. ટાઇમઆઉટ સાથેની ટૂંકી પ્રોબ તે પ્રશ્નનો જવાબ આપે છે જેના પર સુવિધા ખરેખર નિર્ભર છે, અને વપરાશકર્તા ક્લાયન્ટ બદલે અથવા ટનલ આકાર બદલે ત્યારે પણ કામ કરે છે.
પહોંચવાપણું તમારા માર્ગ વિશેનું અવલોકન છે. ઇન્ટરફેસનું નામ તમારા માર્ગને અડીને રહેલી કોઈ વસ્તુ વિશેનું અનુમાન છે, તેથી હ્યુરિસ્ટિક બગ રિપોર્ટમાં દલીલો ઉત્પન્ન કરે છે અને પ્રોબ પુરાવા. જો વપરાશકર્તા એમ કહેતો હોય કે VPN ચાલુ છે ત્યારે પ્રોબ નિષ્ફળ જાય, તો હવે ડિબગ કરવા માટે તમારી પાસે ચોક્કસ માર્ગ છે: નામ-નિરાકરણ, રૂટ અથવા સેવા પરવાનગી.
ચકાસણી 5: શું પ્લેટફોર્મ તમને જે જોઈએ છે તે લાગુ કરી શકે?
જ્યારે જરૂરિયાત એ બાંયધરી હોય કે ટનલમાંથી કંઈ પણ છટકતું નથી, ત્યારે પ્રોફાઇલ તેનું સ્થાન છે, ડિટેક્ટર નહીં. includeAllNetworks ને iOS 14 અથવા પછીના સંસ્કરણમાં ફુલ-ટનલ કન્ફિગરેશનમાં ચાલુ કરવાથી તમારી એપને અનુમાન કરવાનું કહેવાને બદલે પ્લેટફોર્મનું વર્તન બદલાય છે. આ ફ્લેગ NEVPNProtocol સંદર્ભમાં દસ્તાવેજ કરાયેલ છે.
આ એક અલગ પ્રકારનો જવાબ છે: અવલોકનને બદલે અમલ. તે પણ ફક્ત તમે નિયંત્રિત કરો તેવા પ્રોફાઇલને જ લાગુ પડે છે, તેથી બીજાની ટનલ પર નજર રાખતી ગ્રાહક એપને તે મદદ કરતું નથી.
ચકાસણી 6: નિષ્ફળતાને સુરક્ષિત અને અવલોકનયોગ્ય બનાવો
ફક્ત એ ક્ષમતા બંધ કરો જેને ટનલની જરૂર છે અને એપનો બાકીનો ભાગ વાપરી શકાય તેમ રાખો. જે ડિટેક્ટર ખાતરી ન હોય ત્યારે આખું ઇન્ટરફેસ છુપાવે છે તે એવા દરેક માટે આઉટેજ બનાવે છે જેની ટનલ તમે ક્યારેય ધાર્યું ન હોય તેવું નામ વાપરે છે. તેના બદલે રૂઢિચુસ્ત વર્તન પર પાછા ફરો: સ્થાનિક સુવિધાઓ કામ કરતી રહે છે અને ફક્ત તે રિમોટ કૉલ નિષ્ક્રિય થાય છે જેને ખરેખર ટનલની જરૂર છે. તે પસંદગી ઉત્પાદન-નિર્ણય છે, અને તે હ્યુરિસ્ટિકની બાજુમાં લખાવાને લાયક છે.
તમે શું અવલોકન કર્યું તે લોગ કરો: ઇન્ટરફેસ નામો, પ્લેટફોર્મ સંસ્કરણ અને એક પ્રોબનું પરિણામ. તે આગલા રિપોર્ટને દલીલમાંથી ચકાસણીમાં ફેરવે છે. પછી જ્યાં સપોર્ટેડ ઘોષણા હોય ત્યાં તેને પ્રાધાન્ય આપો, કારણ કે સંચાલિત કન્ફિગરેશન ઇરાદો સ્પષ્ટ રીતે ધરી શકે છે અને નામોની તપાસ કરવાનું મોટાભાગનું કારણ દૂર કરી શકે છે.
જો 1 થી 5 સુધીની ચકાસણીઓએ તમને સપોર્ટેડ જવાબ વિના છોડી દીધા, તો પ્રોબ શિપ કરો અને પરિણામને પ્રામાણિકપણે લેબલ કરો. પ્રમાણિત શ્રેષ્ઠ-પ્રયાસ સંકેત આગલી રિલીઝમાં તૂટી જતા ખાનગી API કરતાં વધુ સારો ઉત્પાદન-નિર્ણય છે.