હોટસ્પોટ ક્લાયન્ટ્સ માટે સ્પ્લિટ ટનલિંગ એ એપ દીઠ બહિષ્કાર નથી
એપને VPNમાંથી બહાર કાઢવાથી ફક્ત ફોન બદલાય છે. ટેથર કરેલા લેપટોપને પોતાનો ફોરવર્ડિંગ નિયમ જોઈએ, જે સ્રોત, ગંતવ્ય અને NAT પર મેળવવામાં આવે.
સમાન સંભળાતી બે જરૂરિયાતો સમાન નથી: «આ એપને VPNમાંથી બહાર કાઢો» અને «આ એક ગંતવ્યને મારા હોટસ્પોટ પરના લેપટોપ માટે VPNની બહાર મોકલો». પહેલી બદલે છે કે ફોન પરનું સોકેટ કેવી રીતે નેટવર્ક પસંદ કરે છે. બીજીએ પેકેટ માટે ફોરવર્ડિંગ નિર્ણય બદલવો પડે, જે ફોન પહેલેથી સ્વીકારી લીધા પછી બીજા ઉપકરણથી આવ્યું છે. બંનેને ભેળવવાથી હોટસ્પોટ ક્લાયન્ટ એવી અપવાદ સાથે રહી જાય છે જે હંમેશા ફક્ત ફોનના પોતાના બ્રાઉઝરને જ લાગુ પડતી હતી.
બે પ્રશ્નોના ધારક બે અલગ ઉપપ્રણાલીઓ છે
Android એપ નેટવર્કિંગ અને ટેથરિંગને અલગ રાખે છે. એપના સોકેટને કનેક્ટિવિટી સ્ટેક દ્વારા નેટવર્કને સોંપવામાં આવે છે, અને VPN એપ નક્કી કરે છે કે તેના પોતાના કયા સોકેટ ટનલમાં પ્રવેશે. ટેથર કરેલા ક્લાયન્ટના ફોરવર્ડ કરેલા પેકેટને ટેથરિંગ ઉપપ્રણાલી સંભાળે છે, જે netd પાસેથી રૂટ, નીતિ નિયમો અને ડાઉનસ્ટ્રીમ ઇન્ટરફેસ પર અનુવાદ માંગે છે.
એપ દીઠ બહિષ્કાર ત્યારે આકારવામાં આવે છે જ્યારે એપ સોકેટ ખોલે છે. ફોરવર્ડ કરેલું પેકેટ ક્યારેય તે તપાસ સુધી પહોંચતું નથી, કારણ કે તે આ ઉપકરણ પરના એપ સોકેટમાંથી ઉત્પન્ન થયું નથી. બે સેટિંગ એકબીજાને બદલી ન શકે તેનું આખું કારણ આ જ છે, અને તે બંનેમાંથી કોઈની ખામી નથી.
એપ દીઠ બહિષ્કાર ખરેખર શું બદલે છે
VpnService નો બિલ્ડર addDisallowedApplication સાથે ટનલની બહાર રહેતા પેકેજના નામ આપી શકે છે, અથવા addAllowedApplication સાથે અંદર મંજૂર એકમાત્ર પેકેજના નામ આપી શકે છે. તે એપ પછી અંતર્ગત નેટવર્ક પર સોકેટ ખોલે છે, જ્યારે VPN બાકીના બધા માટે ડિફોલ્ટ રૂટનો માલિક રહે છે.
વ્યાપ્તિ ચોક્કસ છે: પેકેજના પોતાના સોકેટ, આ ઉપકરણ પર, જ્યાં સુધી ટનલ ચાલુ છે. તે ફોરવર્ડ કરેલા ટ્રાફિક વિશે કંઈ કહેતું નથી, બીજા ઉપકરણ વિશે કંઈ નહીં, અને સિસ્ટમ ટેથરિંગ વતી મોકલતી પેકેટ વિશે પણ કંઈ નહીં.
તે ગંતવ્ય નિયંત્રણ પણ નથી. બ્રાઉઝરને બહાર કાઢવાથી તે બ્રાઉઝર જે પણ સરનામે પહોંચે તે બધા બહાર નીકળી જાય છે, જેમાં એ પણ છે જે તમે ટનલની અંદર રાખવા માંગતા હતા. જ્યારે જરૂરિયાત એપને બદલે ગંતવ્યનું નામ લે છે, ત્યારે એપ પસંદ કરનારું સાધન બાંધણીની દૃષ્ટિએ ખોટું છે.
ફોન માટે ટેથર કરેલું પેકેટ કેવું દેખાય છે
ક્લાયન્ટનું પેકેટ હોટસ્પોટ ઇન્ટરફેસ પર ફોન દ્વારા ફાળવેલા ખાનગી સ્રોત સરનામા સાથે, કહો કે 192.168.43.20, અને જાહેર ગંતવ્ય સાથે આવે છે. તેને ફોરવર્ડ કરવા માટે ફોનને ઉપરના લિંક તરફ રૂટ અને અનુવાદનો નિયમ જોઈએ, જેથી જવાબો પાછા જવાનો રસ્તો શોધી શકે, કારણ કે ક્લાયન્ટનું ખાનગી સરનામું સેલ્યુલર નેટવર્ક પર અર્થહીન છે.
Android આને રૂટિંગ કોષ્ટક પસંદ કરતા નીતિ નિયમો દ્વારા વ્યક્ત કરે છે, અને નેટવર્ક તથા VPN બદલાય ત્યારે netd સંબંધિત કોષ્ટકો અને નિયમો ફરી બનાવે છે. ફોરમ પોસ્ટમાંથી કે જૂની આવૃત્તિના એ જ મોડેલમાંથી નકલ કરેલો કોષ્ટક ક્રમાંક, નિયમની પ્રાથમિકતા કે ઇન્ટરફેસનું નામ ટકાઉ માલિકી સ્થાપિત કરતું નથી. આ ફરી બનાવવું એ પણ કારણ છે કે હાથે લખેલો નિયમ એક કલાક કામ કરીને આગલા ફરી જોડાણ પછી અટકી શકે છે.
હોટસ્પોટ અપવાદને ખરેખર કઈ નીતિ જોઈએ
કોઈ નિયમને અડકતા પહેલાં નિર્ણયને સ્રોત, ગંતવ્ય અને ઇચ્છિત માર્ગ તરીકે લખો. એક મંજૂર ગંતવ્ય માટે ન્યૂનતમ સ્વરૂપ આવું દેખાય છે:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
બંને દિશાઓ પૂર્ણ હોવી જોઈએ. સીધી શાખાને હાલમાં ચાલુ સેલ્યુલર ઉપરની લિંક દ્વારા વપરાયોગ્ય રૂટની જરૂર છે; VPN શાખાને ટનલ રૂટ અને ફોરવર્ડ કરવાની પરવાનગીની જરૂર છે. કોઈપણ સ્રોત અનુવાદ તમે પસંદ કરેલા આઉટગોઇંગ સાથે મેળ ખાવો જોઈએ, કારણ કે ટનલ ઇન્ટરફેસ પર લાગુ NAT ટનલનું સરનામું દર્શાવે છે, સેલ્યુલરનું નહીં, અને ત્યારે પરત માર્ગ જવાના માર્ગ સાથે મેળ ખાતો નથી.
જવાબો ટ્રેક કરેલી સ્થિતિ કે સ્પષ્ટ રૂટ દ્વારા એ જ ડાઉનસ્ટ્રીમ ક્લાયન્ટ સુધી પહોંચવા જોઈએ, અને આઉટબાઉન્ડ પેકેટ કાઉન્ટર તેમાંથી કંઈ પણ સાબિત કરતું નથી. VPNના પોતાના બાહ્ય પરિવહનને પણ અપવાદના વ્યાપની બહાર રાખો, નહીં તો ટનલના વાહક પેકેટ ક્લાયન્ટની વેબ વિનંતી માટે લખાયેલી નીતિ વારસામાં મેળવે છે.
પકડાયેલું એક સરનામું ગંતવ્ય નથી
બ્રાઉઝરમાંથી વાંચેલું એક જ IPv4 સરનામું એક ક્ષણચિત્ર છે. મોટી સેવાઓ anycastમાંથી કે ફરતા ધાર સરનામાંઓના સમૂહમાંથી જવાબ આપે છે, ઘણી ડ્યુઅલ-સ્ટેક છે, અને લોગિન પ્રવાહ એવા પ્રમાણીકરણ અને ટેલિમેટ્રી હોસ્ટને અડકી શકે છે જે પૃષ્ઠ ક્યારેય દર્શાવતું નથી. તમે સંજોગવશાત્ જોયેલા સરનામા ફરતે બાંધેલો અપવાદ આગલી વખતે સેવા લોડ સંતુલિત કરે ત્યારે તૂટી જાય છે.
સેવાના માલિકના દસ્તાવેજીકૃત સરનામાંઓનો, અથવા તે પ્રકાશિત કરે તેવી શ્રેણીનો ઉપયોગ કરો, અને બંને સરનામા કુટુંબોને ધ્યાનમાં લો. જો જરૂરિયાત સ્થિર સમૂહ તરીકે વ્યક્ત કરી શકાતી ન હોય, તો તે ફોન પરની રૂટિંગ યુક્તિ નહીં પણ સેવા માટેનો નીતિ પ્રશ્ન હોવાની શક્યતા છે.
ડાઉનસ્ટ્રીમ બાજુથી ચકાસો
ત્રણ તપાસ, આ ક્રમમાં: લેપટોપથી પસંદ કરેલી સેવા, એક સામાન્ય ગંતવ્ય જે VPNની અંદર રહેવું જોઈએ, અને એક ફોન એપ જે અસ્પૃષ્ટ રહેવી જોઈએ. પછી ફરી જોડાણ પછી અને ઉપરની લિંક બદલાયા પછી પુનરાવર્તન કરો, કારણ કે ત્યારે જ નીતિ કોષ્ટકો ફરી બનાવાય છે.
જો ફોનનું શેરિંગ અમલીકરણ ફરી જોડાણ દરમિયાન એ કરાર રાખી શકતું ન હોય, તો હેન્ડસેટ પર root નિયમો એકઠા કરવાને બદલે પસંદગીની નીતિને સમર્થિત ડાઉનસ્ટ્રીમ રાઉટર પર ખસેડો. રાઉટર સ્થિર માલિક સાથે સ્રોત અને ગંતવ્ય મેળવણી વ્યક્ત કરી શકે છે, અને ટેથરિંગ મોડ્યુલનું દસ્તાવેજીકરણ એ ફોન ખરેખર શું કરે છે તેનો યોગ્ય સંદર્ભ છે.