કયું macOS સાધન એક એપને ફક્ત VPN દ્વારા જ જવા માટે મજબૂર કરી શકે છે?
ફક્ત-VPN સીમા માટે માર્ગ અને નકાર બંને જરૂરી છે. પ્રતિ-એપ પ્રોફાઇલ, પ્રોક્સી, ફિલ્ટર અને PF સરખાવો, પછી તમને મહત્વની એ એક એપની કસોટી કરો.
આવશ્યકતા-દસ્તાવેજમાંની એક લાઇન — “આ એપ VPN વાપરી શકે, અને બીજું કંઈ નહીં” — શાંતિથી એવી બે પદ્ધતિઓ માંગે છે જે કોઈ એક સ્વિચ આપતું નથી. ટ્રાફિકને ઇચ્છિત ટનલમાંથી પસાર થવાનો માર્ગ જોઈએ, અને જે ટ્રાફિક સીધો જ બહાર જાય તેનો નકાર થવો જોઈએ. જે સાધનો એક કામ સારું કરે અને બીજું બિલકુલ ન કરે તે સામાન્ય છે, તેથી ફક્ત “કંઈ બ્લોક કરી શકે?” એવું પૂછતી સરખામણી આત્મવિશ્વાસથી પ્રશ્નના અડધા ભાગનો જવાબ આપે છે. પહેલાં સીમા લખો, પછી તેના બંને ભાગને આવરી લેતા ઘટકો પસંદ કરો.
એક વાક્યમાં છુપાયેલી બે આવશ્યકતાઓ
માર્ગદર્શન એ ભાગ છે જે જોડાણને ટનલ કે પ્રોક્સીમાં મૂકે છે. નકાર એ ભાગ છે જે એ જ જોડાણને બીજા કોઈ પણ માર્ગે નીકળતું અટકાવે છે. જુદા જુદા ઘટકો તેમને અમલમાં મૂકે છે, તેઓ જુદી રીતે નિષ્ફળ જાય છે, અને એક ઉત્પાદન એકમાં ઉત્તમ હોઈ શકે અને બીજા વિશે કંઈ ન કહે:
| Approach | Steers traffic | Refuses direct egress | Knows the app identity |
|---|---|---|---|
| Per-app VPN profile | Yes, for the apps it names | Only if a filter or firewall also blocks | Yes, within its own rules |
| Application proxy setting | Partly, for requests that honour it | No | No |
| Content filter | No | Yes | Yes, if the filter is written that way |
| Local PF ruleset | No | Yes, by address and port | Not reliably |
કોષ્ટકને ક્રમાંકન નહીં, ચેકલિસ્ટ તરીકે વાંચો. કોઈ પણ પંક્તિ બંને મધ્ય કોલમ ભરતી નથી, અને જે પંક્તિઓ તેમને આવરે છે તે બે સહયોગી ઘટકો છે: એક માર્ગનો માલિક છે, બીજો નકારનો. ઓળખ કોલમ બીજા કારણસર મહત્ત્વની છે, કારણ કે જે નિયમ એપનું નામ ન આપી શકે તે એ એપ વિશેનો નિયમ લાગુ ન કરી શકે. તમે જે પણ લાગુ કરો, તેણે ત્રણેયનો જવાબ આપવો પડે, નહીં તો આવશ્યકતા-દસ્તાવેજની સીમા મશીન પરની સીમા નથી.
એકલું માર્ગદર્શન બહાર જવાનો રસ્તો છોડે છે
એપ્લિકેશન પ્રોક્સી સેટિંગ એ નકાર વિનાના માર્ગદર્શનનું સૌથી સ્પષ્ટ ઉદાહરણ છે. તે સિસ્ટમ પ્રોક્સીનું પાલન કરતી એપની વિનંતીઓનું માર્ગદર્શન કરી શકે છે, અને બીજું કંઈ આવરતું નથી: સહાયક પ્રક્રિયા, અપડેટર, પૃષ્ઠભૂમિ સેવા કે જુદો પ્રોટોકોલ એ ગોઠવણી કદી વાંચ્યા વિના પોતાનો માર્ગ લઈ શકે છે. તેથી એક પેનલમાં SOCKS અંતિમ બિંદુ પસંદ કરવાથી એપ્લિકેશન માટે સીધા નિકાસની મનાઈની નીતિ બનતી નથી. જો આવશ્યકતા સમગ્ર એપ વિશે હોય, તો પૂછો કે નિયમ ખરેખર કયા ઘટકોને ઓળખે છે.
પ્રતિ-એપ VPN પ્રોફાઇલ પ્રોક્સી કરતાં સારું માર્ગદર્શન કરે છે, કારણ કે પ્લેટફોર્મ નક્કી કરે છે કે કઈ એપ ટનલમાં પ્રવેશે દરેક એપ પોતે નક્કી કરે તેના બદલે. તેમ છતાં તે કંઈનો નકાર કરતું નથી: પ્રોફાઇલ માર્ગ આપે છે, અને જે ટ્રાફિક તેની સાથે મેળ ખાતું નથી તે સામાન્ય માર્ગ લે છે. એ જ અંતર એ સ્થળ છે જ્યાં બીજું ઘટક પોતાનું સ્થાન કમાય છે, અને તેથી એક સ્વિચ જેવા દેખાતા ઉત્પાદનો સામાન્ય રીતે બે હોય છે.
એકલો નકાર એપને તોડી નાખે છે
Apple નું દસ્તાવેજીકરણ સામગ્રી-ફિલ્ટર વિશે નેટવર્ક સ્ટેકમાંથી પસાર થતા ટ્રાફિક પર મંજૂર-કે-બ્લોક ચુકાદાનું વર્ણન કરે છે. એ ચુકાદો ટનલ નથી કે પ્રોક્સી જોડાણ નથી, કારણ કે તે નક્કી કરે છે કે કંઈ આગળ વધી શકે કે નહીં, ક્યાં જાય છે તે નહીં. એકલું ફિલ્ટર નકારને સંપૂર્ણપણે લાગુ કરે છે અને એપ્લિકેશનને નકામું બનાવી દે છે, સ્વચ્છ લોગ સાથે અને કોઈ સમજૂતી વિના. ફિલ્ટરનો ચુકાદો જોડાણ રોકી શકે છે પણ કદી ટનલ આપતો નથી, તેથી તેને માર્ગદર્શન સાથે જોડવું એ રચનાનો નિર્ણય છે, વૈકલ્પિક વધારો નહીં.
સ્થાનિક રીતે સંચાલિત PF નિયમસમૂહ એ સ્પેક્ટ્રમના બીજા છેડે બેસે છે. તે એવા મશીન પર વૈધ સહાય-નિર્ણય છે જેનો માલિક વ્યવસ્થાપક છે, અને તે આપોઆપ વિતરણયોગ્ય ઉત્પાદનનો પાયો નથી, કારણ કે જે નિયમસમૂહનો માલિક છે તે અન્ય ફાયરવોલ વપરાશકર્તાઓ સાથેની તેની આંતરક્રિયાઓ, તેનો અપગ્રેડ માર્ગ અને નિયમ ખોટો હોય ત્યારે તેની પુનઃપ્રાપ્તિનો પણ માલિક છે. ઉત્પાદનમાં PF ઉમેરવાથી એ માલિકીનો પ્રશ્ન દૂર થતો નથી; તે તેને વ્યાખ્યાયિત કરે છે.
તૈનાતી નક્કી કરે છે કે નિયમ કાલે પણ રહેશે કે નહીં
Apple પ્લેટફોર્મ પર Network Extension કેવી રીતે તૈનાત થાય તે તમારી સામેની પ્રદાતા-પ્રકાર, પેકેજિંગ અને OS આવૃત્તિ પર આધાર રાખે છે. macOS પર એપ એક્સ્ટેન્શન વપરાશકર્તા સંદર્ભમાં ચાલે છે અને એ વપરાશકર્તા લોગ આઉટ થાય ત્યારે સમાપ્ત થાય છે, જ્યારે સિસ્ટમ એક્સ્ટેન્શનનો સંદર્ભ વૈશ્વિક હોય છે જે સત્ર પર આધારિત નથી. જો સુરક્ષાને લોગ આઉટ ટકીવું હોય, તો એ ભેદ આખું રચના છે, પાદટીપ નહીં. વર્તનનું વચન આપતાં પહેલાં તૈનાતીનો માર્ગ ખાતરી કરો, કારણ કે એ જ કોડ કયા એક્સ્ટેન્શન પ્રકાર મોકલાય છે તેના આધારે જુદી રીતે ઉતરે છે.
સ્રોતની ઉપલબ્ધતા અમલથી અલગ બાબત છે. રિપોઝિટરી વાંચવાથી ખબર પડે છે કે કંઈક કેવી રીતે અમલમાં મૂકાયું છે, પણ ઇન્સ્ટોલ થયેલ બાઇનરી આ મશીન પર શું કરી શકે તે નહીં. સહી, ઇન્સ્ટોલેશન અને અધિકૃતિ હજી લાગુ પડે છે, અને જૂનાં કર્નલ એક્સ્ટેન્શન કે લાઇબ્રેરી-ઇન્જેક્શન યુક્તિ આસપાસ બનેલી સૂચનાઓ જુદું પ્લેટફોર્મ અને જુદું જોખમ-વલણ વર્ણવે છે, એક સમયે કેટલાં સારાં કામ કર્યાં હોય તે ગમે તેટલું.
એપનું નામ લેતો સ્વીકૃતિ-કિસ્સો
એપ પોતાની રીતે કરે એવી એક ક્રિયા પસંદ કરો, તે જે સરનામે પહોંચવું જોઈએ અને એ સરનામું IPv4 છે કે IPv6 તે નોંધો, પછી મંજૂર ટનલ-રહિત સ્થિતિમાં એ જ ક્રિયા ફરી કરો. બીજા ચલાવણીએ જાહેર કરેલ નકાર આપવો જોઈએ, શાંત સીધો ફરી પ્રયાસ નહીં. એ જ અડધો ભાગ છે જે લોકો અનિર્દિષ્ટ રાખે છે, અને એકમાત્ર અડધો ભાગ જે સાબિત કરે છે કે નકાર છે જ. પહેલાં ટનલ ઉપલબ્ધ હોય ત્યારે ચલાવો, જેથી બે પરિણામો વચ્ચેનો ભેદ ફક્ત ગેરહાજર ટનલથી આવી શકે.
પછી આવશ્યકતામાં દર્શાવેલા સંક્રમણોમાંથી પસાર થાઓ: એપ ફરી શરૂ કરવી, સહાયક પ્રક્રિયા સક્રિય થવી, ટનલ ફરી જોડાવું, મશીન નેટવર્ક બદલવું, અને લાગુ પડે ત્યાં લોગ આઉટ કે રીબૂટ. બ્રાઉઝરનું જાહેર-IP પૃષ્ઠ બીજી એપ્લિકેશનના સોકેટની કસોટી નથી, તેથી તે આનું સ્થાન લઈ શકતું નથી. જ્યાં કોઈ સમર્થિત તૈનાતી એપના વાસ્તવિક વર્તનને આવરતી નથી, ત્યાં સ્પષ્ટ ગેટવે અને વૈકલ્પિક નિકાસ વિનાનું અધિકૃત અલગ કરેલું પર્યાવરણ પોતાના સંચાલન-ખર્ચ સાથેનો સમાવેશ-નિર્ણય છે, ચેકબોક્સનો વિકલ્પ નહીં.
ચાર એન્ટ્રી લખીને પૂર્ણ કરો: એપ કયા ઘટકોથી બનેલી છે, માર્ગદર્શનનો માલિક કોણ છે, નકારનો માલિક કોણ છે, અને નિયમ હજી પણ લાગુ રહેવો જોઈએ એવી સ્થિતિઓ. જાહેર રિપોઝિટરી પસંદગીનો એક માપદંડ હોઈ શકે, પણ તે ચારમાંનો એક નથી, અને એ જ એન્ટ્રીઓ નક્કી કરે છે કે આપેલ સાધન નેટવર્કિંગ આવશ્યકતા પૂરી કરે છે કે નહીં.