વિભાજિત ટનલ: તમે સેટ કરેલા VPN ની બહાર લિંક કેમ ખૂલે છે
રૂટિંગ સોકેટ ખોલતી પ્રક્રિયાને અનુસરે છે, તમને લિંક દેખાડનારી એપને નહીં. તમારા બાકાત વિસ્તારતા પહેલાં સાબિત કરો કે કયો પ્રોગ્રામ જોડાય છે.
એપને ટનલમાંથી પસાર કરવાથી તેનું રૂટિંગ એ એપ શરૂ કરે તે બધા સુધી પહોંચતું નથી, જોકે ઇન્ટરફેસ ઊલટું સૂચવે છે. લિંક વિનંતી બીજા પ્રોગ્રામને સોંપે છે, તે પ્રોગ્રામ પોતાનું સોકેટ ખોલે છે, અને પ્લેટફોર્મ નિયમો નવી પ્રક્રિયા પર લાગુ કરે છે, જેણે ટેક્સ્ટ દેખાડ્યું તેના પર નહીં. એ બીજી પ્રક્રિયા જ ટનલ નીતિ ખરેખર જુએ છે, અને તે તમે સેટ કરેલી નથી.
તેથી સમાવિષ્ટ એપ ટનલની બહાર રહેલું બ્રાઉઝર ખોલી શકે છે. બાકાત કરેલું બ્રાઉઝર કામ પાછું અંદર રહેલી એપને આપી શકે છે. એ આશ્ચર્યની બંને દિશાઓ સામાન્ય વર્તન છે.
કાર્યપ્રવાહનો એ ભાગ જે કોઈએ સેટ કર્યો નથી
દરેક એપની નીતિ એક્ઝિક્યુટેબલ કે પેકેજની ઓળખ સામે લખાય છે, અને દરેક જોડાણ બનતી ક્ષણે જ મૂલવાય છે. બ્રાઉઝર, દસ્તાવેજ વ્યૂઅર, મીડિયા પ્લેયર અને સિસ્ટમની શેર શીટ—દરેક પોતાની ઓળખ ધરાવે છે, અને દરેકને પોતાનો ચુકાદો મળે છે. ઊંડી લિંક ડેટા લઈ જાય છે, નીતિ નહીં.
એટલે જ અવલોકન મનસ્વી લાગે છે: એક જ ક્લિક બે રીતે રૂટ થાય છે, જે હેન્ડલર જવાબ આપે તેના પર આધાર રાખીને. ટનલમાંનું મેલ ક્લાયન્ટ ટનલની બહાર રહેતા બ્રાઉઝરમાં લિંક ખોલે છે, અને પાનું તમારા ઘરના સરનામેથી લોડ થાય છે. ટનલની બહારનું બ્રાઉઝર અંદર રહેતા વ્યૂઅરમાં દસ્તાવેજ ખોલે છે, અને ફાઇલ એક્ઝિટમાંથી આવે છે. બંનેમાંથી કોઈ પરિણામ ક્લાયન્ટની ખામી નથી.
પહેલેથી ચાલતું હેન્ડલર વધુ ખરાબ કરે છે. જો બ્રાઉઝર પહેલેથી ખુલ્લું હોય, તો લિંક હાલની પ્રક્રિયા માટે સંદેશ બની જાય છે, અને તે પ્રક્રિયા શરૂ થયા વખતે જે રૂટિંગ હતું તે જ રાખે છે. હેન્ડલર બંધ કરીને ફરી ખોલવાથી પરિણામ બદલાય છે, અને એટલે જ સમસ્યા ક્યારેય માંગ પર પુનરાવર્તિત થતી નથી.
| Platform | Policy object | What it is evaluated against |
|---|---|---|
| Android | Per-app VPN allowlist | Package name of the process opening the socket |
| Windows | Application traffic filters | Application path in the filter rule |
| Linux | UID or cgroup routing rules | Owner of the socket, which can be a different program |
જોડાણ ખરેખર કઈ પ્રક્રિયાએ બનાવ્યું
અનુમાન કરવાને બદલે સ્વીકારતી બાજુ માપો. ટનલ ચાલુ રાખો, નિરુપદ્રવી લિંક પર ક્લિક કરો, અને નવો પ્રોગ્રામ જે સોકેટ ધરાવે છે તે જુઓ.
ss -tnp state established '( dport = :443 )' Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess
પ્રથમ આદેશ Linux પર દરેક સ્થાપિત સોકેટ પાછળની પ્રક્રિયાનું નામ આપે છે, અને બીજો Windows પર માલિક પ્રક્રિયાની ઓળખ ઉકેલીને એ જ કરે છે. પ્રક્રિયાનું નામ તમારી નીતિના નામો સાથે સરખાવો. જો નામ બ્રાઉઝર હોય અને બ્રાઉઝર બાકાત હોય, તો ક્લિક ખામીને કારણે નહીં, ડિઝાઇન પ્રમાણે ટનલની બહાર ગયું છે. નીતિના નિયમને જીવંત સોકેટ સાથે મેળવવો એ જ આખી પદ્ધતિ છે.
હેન્ડલર પહેલેથી ચાલુ હોય તેમ, પછી બંધ હોય તેમ તપાસનું પુનરાવર્તન કરો. બંને પરિણામ અલગ હોઈ શકે છે, અને એ ફરક જ ટનલમાંથી નીકળી જતી લિંક્સ વિશેના મોટા ભાગના વચ્ચે-વચ્ચેના અહેવાલો સમજાવે છે.
કવરેજ કાર્યપ્રવાહનું લક્ષણ છે
જો કોઈ કાર્ય શરૂઆતથી અંત સુધી ટનલમાં જ રહેવું હોય, તો તે જે પણ ઘટક સુધી પહોંચી શકે તે બધું નીતિમાં હોવું જોઈએ: લોન્ચર, હેન્ડલર, વ્યૂઅર, અને પ્લેટફોર્મ તેમની વચ્ચે મૂકે તે કોઈપણ મધ્યસ્થ. પહોળું કવરેજ ઘણી વાર પ્રામાણિક જવાબ હોય છે, અને દરેક શેર લક્ષ્યની ઓડિટ કરવા કરતાં તે સસ્તું પડે છે.
એક એપ સુધારવા માટે સિસ્ટમ મધ્યસ્થને બાકાત કરવો સામાન્ય ભૂલ છે. મધ્યસ્થ વહેંચાય છે, તેથી બાકાત એ જ માર્ગ વાપરતી દરેક બીજી એપ સાથે જાય છે, સામાન્ય રીતે અઠવાડિયાં પછી અહેવાલ ન આવે ત્યાં સુધી કોઈને ધ્યાન પણ નથી પડતું. ઘટકને બાકાત કરતા પહેલાં બીજું શું તેના પર આધારિત છે તે વાંચો.
ઓળખને રૂટિંગથી અલગ પણ રાખો. લિંક સત્ર ટોકન કે ખાતાની ઓળખ લઈ જઈ શકે છે, વિનંતી કઈ એક્ઝિટ મેળવે તે ધ્યાનમાં લીધા વિના. યોગ્ય રીતે રૂટ થયેલી ક્લિક પણ ગંતવ્યને ચોક્કસ કહી શકે છે કે કોણે તેને અનુસર્યું.
કાર્યપ્રવાહનું દસ્તાવેજીકરણ કરો, પહેલું ચેકબોક્સ નહીં. જ્યારે કાર્ય ચાર પ્રોગ્રામ સુધી ફેલાય, ત્યારે ચાર પ્રોગ્રામવાળું આકૃતિ જ ટ્રાફિક ક્યાં જશે તે અનુમાનિત કરે છે, અને એક-એપ સેટિંગ તેની ફક્ત એક પંક્તિ છે.