તમારી VPN પ્રક્રિયાને કઈ Linux ક્ષમતાઓની જરૂર છે?
ઇન્ટરફેસ સેટઅપ, રૂટ, ઉપકરણ ઍક્સેસ અને સામાન્ય સોકેટ અલગ અલગ વિશેષાધિકારો છે. CAP_NET_ADMIN આપતાં પહેલાં નિષ્ફળ ગયેલી ક્રિયાનું નામ આપો.
VPN ડીમોનને વિશેષાધિકાર પ્રાપ્ત નેટવર્ક ક્રિયાઓની જરૂર છે, જ્યારે સામાન્ય એપ્લિકેશનો કોઈ પણ વિશેષાધિકાર વિના બહાર જતાં સોકેટ ખોલે છે. એ જ અંતરમાં મોટાભાગની ક્ષમતા-ભૂલો શરૂ થાય છે: કોઈ પરવાનગી ભૂલ જુએ છે, આખો સમૂહ આપી દે છે, અને સેવા એવા કારણોસર કામ કરે છે જે પછી કોઈ સમજાવી શકતું નથી. નીચેની સમીક્ષા નિષ્ફળ ગયેલી ક્રિયાથી શરૂ થાય છે, તેને એક સત્તા સાથે જોડે છે અને પછી પ્રક્રિયા ખરેખર જે સંદર્ભમાં ચાલે છે તે તપાસે છે. અમર્યાદિત root તરીકે ચલાવવું કેટલાક ડિપ્લોયમેન્ટ માટે માન્ય જવાબ છે, પણ તે નિર્ણય હોવો જોઈએ, ડિફોલ્ટ નહીં.
નિષ્ફળ ગયેલી ક્રિયાથી શરૂ કરો
ટ્યુટોરિયલ વાંચતાં પહેલાં ભૂલ વાંચો. ઇન્ટરફેસ ફેરફાર પર «ક્રિયા પરવાનગી નથી», ઉપકરણ નોડ ખોલવાનો ઇનકાર અને નીચા પોર્ટ પર બાઇન્ડ નિષ્ફળતા — આ ત્રણ અલગ સમસ્યાઓ છે, ત્રણ અલગ પરવાનગીઓ સાથે. જો પ્રક્રિયા શરૂ થાય અને ફક્ત પ્રથમ રૂટ ફેરફાર પર નિષ્ફળ જાય, તો તે એ પણ કહે છે કે ઇન્ટરફેસ બનાવવું પહેલેથી સફળ થયું છે, જે જવાબને ઘણો સાંકડો કરે છે.
સેવા બંધ રાખીને ભૂલ ફરી ઉત્પન્ન કરો, પછી અમલીકરણ પરવાનગી આપે તો તેને એ જ વપરાશકર્તા હેઠળ ફોરગ્રાઉન્ડમાં શરૂ કરો. તમે જોઈ શકો એવી ભૂલ અનુમાન કરવી પડે એવી લોગ લાઇન કરતાં સારી છે, અને તે ક્ષમતા-સમસ્યા તથા SELinux કે AppArmor ઇનકાર વચ્ચેનો ફરક સ્પષ્ટ કરે છે.
દરેક ક્રિયાને એક સત્તા સાથે જોડો
ટેબલ શરૂઆતનો નકશો છે, અમલીકરણના દસ્તાવેજનો વિકલ્પ નહીં:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
એ ટેબલની બે પંક્તિઓ જ લોકો પરસ્પર ગૂંચવે છે. /dev/net/tun ખોલવું એ ફાઇલ-પરવાનગીનો પ્રશ્ન છે; તમે જે ખોલ્યું તેને ગોઠવવા કર્નેલને વિનંતી કરવી એ ક્ષમતાનો પ્રશ્ન છે. CAP_NET_ADMIN આપવાથી તમારો સેવા-વપરાશકર્તા જે ઉપકરણ નોડ વાંચી શકતો નથી તે ઠીક થતો નથી, અને નોડ ઠીક કરવાથી તમને રૂટ સત્તા મળતી નથી. બંનેમાંથી કોઈ પણ બદલતાં પહેલાં બંને તપાસો.
કર્નેલ WireGuard અને યુઝર-સ્પેસ ટનલ પ્રોગ્રામની જરૂરિયાતો પણ સરખી નથી. કર્નેલ મોડ્યુલનો માર્ગ netlink દ્વારા હાલનું ઇન્ટરફેસ ગોઠવે છે, જ્યારે યુઝર-સ્પેસ અમલીકરણને ઉપકરણ પણ જોઈ શકે છે અને કેટલાક ટ્રાન્સપોર્ટ માટે કાચા સોકેટ પણ.
સંદર્ભ વાંચો: સેવા, કન્ટેનર કે શેલ
હોસ્ટના નેટવર્ક નેમસ્પેસમાંની એક ક્ષમતા જાણી જોઈને અલગ પાડેલા સ્ટેકમાંની એ જ ક્રિયા કરતાં ઘણું વધુ અસર કરી શકે છે. કન્ટેનર રનટાઇમ સામાન્ય રીતે ઘટાડેલા બાઉન્ડિંગ સેટ સાથે શરૂ થાય છે; હોસ્ટ નેટવર્ક વહેંચતા કન્ટેનરમાં NET_ADMIN ઉમેરવું તેના પોતાના નેટવર્ક નેમસ્પેસ અને કોઈ હોસ્ટ માઉન્ટ ન હોય તેવા કન્ટેનરમાં ઉમેરવા કરતાં ઘણી મોટી પરવાનગી છે.
systemd યુનિટ માટે યુનિટ ફાઇલ શું કહેતી લાગે છે તે નહીં, ખરેખર શું લાગુ પડે છે તે વાંચો: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities અસરકારક મૂલ્યો જણાવે છે, જે તમે ભૂલી ગયેલા drop-in દ્વારા સેટ થયા હોઈ શકે. અસરકારક મૂલ્ય માંગો, ઇચ્છિત મૂલ્ય ક્યારેય નહીં. Ambient ક્ષમતાઓ મહત્ત્વની છે કારણ કે root ન હોય તેવી સેવા તેમના વિના exec દરમિયાન ક્ષમતાઓ ગુમાવે છે.
પેકેજ કે ઇમેજનું સમર્થિત સેટઅપ આધાર તરીકે લો. બીજા ટ્યુટોરિયલે બીજા સાધન માટે તેની યાદી આપી છે એટલે કાચા સોકેટની પરવાનગી કે વિશેષાધિકાર મોડ ઉમેરશો નહીં; એ તર્ક કંઈ પણ સ્થાનાંતરિત કરતો નથી અને તમે ચૂકવેલું અલગીકરણ ખોઈ નાખે છે. શંકા હોય તો કંઈ ન આપો અને તમને જરૂરી એવી ચોક્કસ ક્રિયા માટે અમલીકરણની નોંધો વાંચો.
વિશેષાધિકારો ઘટ્યા પછી શું થાય છે તે જુઓ
ઘણા ડીમોન વિશેષાધિકાર સાથે શરૂ થાય છે, ઇન્ટરફેસ ગોઠવે છે, પછી બિન-વિશેષાધિકાર વપરાશકર્તા પર જાય છે અને ટનલ રાખે છે. ત્યાર પછી પ્રક્રિયા રૂટ ઉમેરી શકતી નથી, ફાયરવોલ નિયમ ફરી લખી શકતી નથી કે નવું વિશેષાધિકાર ઉપકરણ ખોલી શકતી નથી; જ્યાં સુધી ફરી જોડાણને એની જ જરૂર ન પડે ત્યાં સુધી તે ઠીક છે. પછીની ફાઇલ વાંચન અને હૂક ચલાવવા એ જ કારણસર નિષ્ફળ થઈ શકે છે.
પહેલી સેકન્ડ નહીં, આખું જીવનચક્ર કસો: શરૂઆત, નવીકરણ કે ફરી જોડાણ, અને બંધ કરતી વખતે સફાઈ. ઇન્ટરફેસ પહેલી વાર સફળ બનવાથી સાબિત થતું નથી કે પછીની દરેક વિશેષાધિકાર ક્રિયા હજી કામ કરશે, અને નિષ્ફળતા સામાન્ય રીતે ઉત્પાદનમાં કલાકો પછી દેખાય છે.
વપરાશકર્તા બદલાવ દરમિયાન ટનલ ખુલ્લી રાખતા અમલીકરણ સામાન્ય રીતે ટનલ અને કી ટકાવી રાખવાના વિકલ્પો સાથે તેને જોડે છે. systemd બાજુએ સમાન પ્રશ્ન એ છે કે યુનિટનો ક્ષમતા-સમૂહ તમે ગોઠવેલા વપરાશકર્તા બદલાવને ટકી રહે છે કે નહીં.
પરવાનગી અને તેનું કારણ નોંધો
ચોક્કસ પરવાનગી, તે જે ક્રિયા શક્ય બનાવે છે અને જે ભૂલ સુધારી છે તે લખો. ડિપ્લોયમેન્ટ નોંધમાં એક લીટી — «યુનિટના નેટવર્ક નેમસ્પેસમાં CAP_NET_ADMIN, ફરી જોડાણ પછીના રૂટ ફેરફારો માટે જરૂરી» — પછીની વ્યક્તિને પરવાનગી ફરી પહોળી કરતાં રોકવા માટે પૂરતી છે.
પછી દરેક અપગ્રેડ પછી અસરકારક સમૂહ ફરી વાંચો. વેન્ડર સુવિધાઓ ઉમેરે છે, ઇમેજ ડિફોલ્ટ બદલે છે, અને ગયા વર્ષે બિનજરૂરી હતી એવી ક્ષમતા કોઈને ખબર પડ્યા વિના ભારવાહક બની શકે છે.