એક સામાન્ય Linux એપ TUN ને સ્પર્શ કર્યા વિના VPN વાપરે છે

સ્થાપિત Linux VPN વાપરતું બ્રાઉઝર /dev/net/tun ખોલતું નથી. તે સોકેટ ખોલે છે, અને કર્નલ નક્કી કરે છે કે તે સોકેટના પેકેટ કયા ઇન્ટરફેસ દ્વારા નીકળે છે. ટનલ બનાવનારી પ્રક્રિયા એ પ્રક્રિયા કરતાં અલગ કામ કરે છે જેનું ટ્રાફિક તે વહન કરે છે. તે બે ભૂમિકાઓને અલગ રાખવાથી મોટાભાગના પરવાનગી પ્રશ્નો પૂછાય તે પહેલાં જ જવાબ મળી જાય છે.

સોકેટથી ટનલ સુધી એક પેકેટને અનુસરો

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

તે માર્ગમાં કંઈ પણ એપ્લિકેશનને ઉપકરણ વિશે જાણવાની જરૂર રાખતું નથી. ડેમન ફાઇલ ડિસ્ક્રિપ્ટર રાખે છે અને ઇન્ટરફેસ કામગીરી કરે છે, જ્યારે એપ્લિકેશન ફક્ત સામાન્ય નેટવર્ક API જુએ છે.

બે ભાગ એક વાર દોરો, અને પરવાનગીના પ્રશ્નો મૂકવા સરળ બનશે. ઉપરનો ભાગ એપ્લિકેશનની દુનિયા છે, અને નીચેનો ભાગ ડેમનનો છે.

નક્કી કરો કે કોને ઉપકરણની જરૂર છે અને કોને નહીં

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

એક વાર રૂટ અને નીતિ સ્થાપિત થાય, પછી સામાન્ય પ્રક્રિયા પોતાના સામાન્ય સોકેટ કૉલ્સ દ્વારા પરિણામી માર્ગ વાપરે છે. તેને ઉપકરણ નોડની જરૂર નથી, અને root ની જરૂર નથી.

ઉપકરણ પરવાનગીઓ બદલવી એ એપ્લિકેશનને ગંતવ્ય ઍક્સેસ આપવાનો રસ્તો નથી. તે ફક્ત ઉપકરણની સીમા બીજે ક્યાંક ખસેડે છે.

એપ્લિકેશન ખરેખર જે નામસ્પેસમાં ચાલે છે તે તપાસો

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

તપાસો ip netns list અને ip -n NAME route વડે, અથવા પ્રક્રિયાની નામસ્પેસ લિંક તપાસીને. જવાબ સામાન્ય રીતે એક જ આદેશમાં દેખાય છે.

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

ક્ષમતાઓને નેટવર્ક નીતિથી અલગ કરો

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

પોતાની ટનલ લાગુ કરતો પ્રોગ્રામ ત્રીજો કિસ્સો છે. તે ખરેખર TUN ખોલે છે કારણ કે તે ડેમનની ભૂમિકા લે છે, તેથી તેને ડેમનના વિશેષાધિકારોની જરૂર છે.

વિશેષાધિકારનું નામ લેતા પહેલાં કામગીરીનું નામ લો. બંનેને અલગ કરવા સામાન્ય રીતે દેખાય તેનાથી સરળ છે.

બે ખાતાં સાથે વિભાજન ચકાસો

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

પરિણામી ડિઝાઇન સ્પષ્ટ સીમા સાથેનું લઘુત્તમ વિશેષાધિકાર છે: એક ઘટક સેટઅપ અને ટનલ સંસાધનોનો માલિક છે, વર્કલોડ તેમના સામાન્ય ખાતાં જાળવી રાખે છે, અને નેટવર્ક નીતિ નક્કી કરે છે કે શું પસાર થઈ શકે. બધું root તરીકે ચલાવવાથી તે ભૂમિકાઓ કંઈ સમજાવ્યા વિના ભાંગી પડે છે.