બે એપ એક જ ઓફિસ સર્વર સાથે કનેક્શન ખોલે છે, અને તેમાંથી ફક્ત એક જ ટનલનો ઉપયોગ કરવો જોઈએ. રૂટ આ ઈચ્છા વ્યક્ત કરી શકતો નથી, કારણ કે રૂટિંગ કોષ્ટકો ગંતવ્યો પર આધારિત હોય છે અને તેમને કઈ પ્રક્રિયાએ સોકેટ ખોલ્યું તેની કોઈ સમજ નથી. લોકો જે માંગે છે અને જેની તેમને જરૂર હોય છે તે ઘણી વાર અલગ વસ્તુઓ હોય છે. કોઈપણ ગોઠવણી બદલતા પહેલાં બંનેને અલગ કરો.

પસંદગીકાર ગંતવ્ય છે, ક્યારેય પ્રક્રિયા નહીં

દરેક રૂટિંગ નિર્ણય ગંતવ્ય સરનામાથી શરૂ થાય છે અને ઇન્ટરફેસ પર પૂરો થાય છે. કર્નલ ક્યારેય પૂછતું નથી કે પેકેટ કયા પ્રોગ્રામે મોકલ્યું, અને macOS પર pf પણ પ્રક્રિયા પ્રમાણે રૂટ કરતું નથી, તેથી ફાયરવોલ નિયમ એક એપને બીજા માર્ગે મૂકી શકતો નથી. તેથી એ જ સર્વર, બ્રાઉઝર દ્વારા પહોંચીએ કે રિપોર્ટિંગ ટૂલ દ્વારા, બંને માટે એક જ માર્ગ લે છે. તેથી એપ-સ્તરનું અલગીકરણ રૂટ સિવાયની કોઈ વસ્તુમાંથી આવવું જોઈએ: એક VPN પ્લગઇન જે સોકેટનો માલિક હોય, એક પ્રોક્સી જે એપ વતી કનેક્શન લે, અથવા એક અલગ નેટવર્ક સ્ટેક. તેમાંથી કંઈ પણ રૂટિંગ ફેરફાર નથી.

એક જ સરનામા સાથે વાત કરતી બે એપ કોઈ ડિઝાઇનની સૌથી સ્વચ્છ કસોટી છે. જો જવાબ તેમની વચ્ચે અલગ ન હોઈ શકે, તો ડિઝાઇન ગંતવ્ય-આધારિત છે, તેને ભલે ગમે તે નામ આપવામાં આવે.

સામાન્ય split tunnel ખરેખર શું આપે છે

split tunnel ખાનગી પ્રીફિક્સ માટે રૂટ સ્થાપિત કરે છે અને બાકીનું બધું ભૌતિક માર્ગ પર છોડી દે છે. સામાન્ય રીતે વિનંતીનો અર્થ આ જ હોય છે: ટનલ દ્વારા ઓફિસ સર્વર સુધી પહોંચવું, જાહેર બ્રાઉઝિંગ સીધું રાખવું. તે સરળ છે, દરેક સામાન્ય ક્લાયન્ટ તેને સમર્થન આપે છે, અને તે કોઈપણ બીજા રૂટ જેવી જ વ્યવસ્થાથી લાગુ થાય છે. ચોક્કસ ગંતવ્ય route -n get થી તપાસો, ડિફોલ્ટ રૂટ વાંચવાને બદલે, કારણ કે split tunnel ઘણી વાર ડિફોલ્ટ રૂટને અસ્પૃશ્ય રાખે છે.

ડિફોલ્ટ રૂટને હાથથી સંપાદિત કરવું એ કોઈ વસ્તુમાં રૂપાંતર નથી. તે ક્લાયન્ટની પોતાની રૂટ પુનઃસ્થાપન સામે લડે છે અને જે ક્લાયન્ટ સુરક્ષા નીતિ સ્થાપિત કરે છે તેમાં મશીનને એવી સ્થિતિમાં છોડી શકે છે જેની ન તમે અપેક્ષા રાખો છો ન ક્લાયન્ટ. તેના બદલે split tunnel ને ક્લાયન્ટની સમર્થિત સેટિંગ્સમાં ગોઠવો.

macOS પર પ્રતિ-એપ VPN શું માંગે છે

macOS પર સાચું પ્રતિ-એપ VPN એ Network Extension સુવિધા છે જેને ગોઠવણી પ્રોફાઇલ ચલાવે છે. એક સંચાલન પેલોડ પસંદ કરેલી એપને VPN ગોઠવણી સાથે જોડે છે, અને સિસ્ટમ પછી તે એપની ટ્રાફિક તે મુજબ રૂટ કરે છે. આ એક સંચાલિત તૈનાતી છે, એટલે કે MDM, સહી કરેલી પ્રોફાઇલ અને એક એવો સંચાલક જે બંનેનો માલિક હોય.

ક્લાયન્ટને હાથથી સ્થાપિત કરવાથી તે મેપિંગ બનતું નથી, અને સામાન્ય સેટિંગ્સ પેનલ એપને અલગ-અલગ પસંદ કરી શકાય તેવી બનાવતું નથી. કોઈ વેન્ડર પોતાના એપ નિયમો રજૂ કરી શકે છે, અને તે સામાન્ય નિયમને બદલે તેના દસ્તાવેજોને અનુસરે છે.

MDM વિના એપ-સ્તરીય અલગીકરણના ત્રણ માર્ગ

જ્યાં સંચાલન ઉપલબ્ધ નથી, ત્યાં પ્રોક્સી વ્યવહારુ જવાબ છે. એપની પોતાની પ્રોક્સી ગોઠવણી સેટ કરો, અથવા એવી PAC ફાઇલ વાપરો જે ફક્ત તે જ એપ માટે ગંતવ્ય અને પ્રોટોકોલ પ્રમાણે પસંદ કરે.

સ્થાનિક પ્રોક્સી કનેક્શન પૂરું કરે છે અને ટનલ દ્વારા તેને ફરી બનાવે છે, તેથી એપને ક્યારેય રૂટની જરૂર પડતી નથી. બીજો વિકલ્પ અલગ નેટવર્ક સ્ટેક છે: પોતાના ડિફોલ્ટ રૂટ સાથેનું વર્ચ્યુઅલ મશીન અથવા કન્ટેનર, જ્યાં એપ સ્થાનિક સરનામા દ્વારા પહોંચે છે. ત્રીજો એ છે કે ગંતવ્ય-આધારિત રૂટિંગ સ્વીકારવું અને શરત છોડી દેવી, જે ત્યારે પ્રામાણિક છે જ્યારે બંને એપ ટનલ વાપરી શકે. ત્રણેય ચકાસી શકાય છે, અને તેમાંથી કોઈ પણ એવું દેખાડતું નથી કે રૂટ પ્રક્રિયાઓને જાણે છે.

વિનંતી એવી લખો કે જવાબ સ્પષ્ટ હોય

વ્યવસ્થાને બદલે કાર્યપ્રવાહ વર્ણવો: કઈ એપને કઈ સેવા જોઈએ, બીજી એપને એ જ સેવાથી દૂર રાખવી છે કે નહીં, અને ટનલ બંધ હોય ત્યારે શું થવું જોઈએ. આ ત્રણ જવાબ ડિઝાઇન પસંદ કરે છે. તેઓ સંચાલકને એ પણ કહે છે કે વિનંતી રૂટિંગ ફેરફાર છે કે તૈનાતી પ્રોજેક્ટ.

બહિષ્કૃત એપનો કિસ્સો સ્પષ્ટ રીતે સમાવો. જે ક્લાયન્ટ એપને ત્યારે અટકાવે છે જ્યારે તેનો સુરક્ષિત માર્ગ ઉપલબ્ધ ન હોય, તે તે ક્લાયન્ટ કરતાં અલગ વર્તે છે જે તેને ભૌતિક ઇન્ટરફેસ પર પાછી પડવા દે છે, અને વપરાશકર્તાઓ તે ફરક તરત જ ધ્યાનમાં લે છે. ટિકિટમાં અપેક્ષાનું નામ લખો. પછી વાસ્તવિક મશીન પર ચકાસો, કારણ કે એ જ ઉત્પાદન macOS પર Windows કરતાં ઘણી વાર અલગ વર્તે છે, અને તેનું macOS દસ્તાવેજ જ તેની સેટિંગ્સ શું કરે છે તે અંગેનો એકમાત્ર વિશ્વસનીય સ્રોત છે.

સંબંધિત લેખો