એપ ઇન્ટરફેસ સાથે બંધાયેલી? તેનો VPN માર્ગ ડિફૉલ્ટ નથી

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

ત્રણ જુદાં બંધન, ત્રણ જુદી અસરો

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

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

એપ ખરેખર શું સેટ કરે છે તે નક્કી કરો

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

Linux પર SO_BINDTODEVICE જેવા સૉકેટ વિકલ્પોનો દસ્તાવેજીકૃત વ્યાપ અને પરવાનગીની જરૂરિયાતો છે, અને બિન-વિશેષાધિકૃત પ્રોસેસ તેમને બિલકુલ સેટ કરી શકે નહીં. આ મર્યાદા ઉપયોગી સંકેત છે: જો વિકલ્પ લાગુ કરી શકાતો ન હોય, તો એપ્લિકેશન સંભવતઃ તફાવતનો સ્રોત નથી.

નીતિ રૂટિંગ સ્રોત વાંચે છે

જ્યારે નીતિ રૂટિંગ ગોઠવાયેલું હોય, ત્યારે નિયમ પેકેટના સ્રોતના આધારે ટેબલ પસંદ કરી શકે છે. તેથી સ્રોત સરનામું બાંધતું સૉકેટ એવા નિયમને અનુસરી શકે છે જેને ડિફૉલ્ટ માર્ગ કદી સ્પર્શતો નથી, ભલે કોઈ ઇન્ટરફેસ સ્પષ્ટ રીતે નામ ન આપવામાં આવ્યું હોય.

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

સ્પ્લિટ ટનલિંગ અને સહાયક પ્રોસેસ

દરેક એપ માટે સ્પ્લિટ ટનલિંગ વધુ એક સ્તર ઉમેરે છે. ક્લાયન્ટ એપ્લિકેશનનું પેકેજ કે પ્રોસેસ મેળવી શકે છે, અને પોતાનું સૉકેટ ખોલતો સહાયક અલગ વિષય છે. લૉન્ચર અને તેની બૅકગ્રાઉન્ડ સેવા એક જ દૃશ્યમાન નામ હેઠળ જુદાં કનેક્શન બનાવી શકે છે.

સ્પ્લિટ-ટનલ નિયમ ખરેખર કનેક્ટ થતી પ્રોસેસને આવરી લે છે કે નહીં તે તપાસો. જો એપ ચોક્કસ ઇન્ટરફેસ સાથે બંધાય અને VPN ક્લાયન્ટ પેકેજ પ્રમાણે મેળ કરે, તો બંને નિર્ણય કોઈ પણ ખોટો ન હોવા છતાં અસહમત થઈ શકે છે.

એપનો પોતાનો માર્ગ ચકાસો

દરેક ફેરફાર પછી એપ્લિકેશનમાંથી નવી વિનંતી ચલાવો. તમે ઇચ્છતા હતા તે એગ્ઝિટ બતાવતું બ્રાઉઝર બીજી ઇન્ટરફેસ સાથે બંધાયેલા બીજા પ્રોગ્રામ માટે સમાન પુરાવો નથી, અને કૅશ કરેલાં કનેક્શન સેટિંગ બદલાયાના ઘણા સમય પછી પણ જૂનો માર્ગ વાપરી શકે છે. નવો નિયમ નક્કી કરતાં પહેલાં જૂનું સત્ર બંધ કરો. નહીં તો કસોટી ભૂતકાળ માપે છે.

Linux સૉકેટ સંદર્ભ SO_BINDTODEVICE અને તેની જરૂરિયાતોનું દસ્તાવેજીકરણ કરે છે. પહેલાં એપ્લિકેશનની પોતાની ગોઠવણી વાંચો, એ જ સંદર્ભમાં શોધ ફરી ચલાવો અને તે પછી જ નક્કી કરો કે રૂટ કે બંધન બદલવાની જરૂર છે.