VPN કન્ટેનરમાં NET_ADMIN: તે શું અને ક્યાં બદલી શકે

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

ક્ષમતા શું આવરી લે છે

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

તે નામસ્થાનની બહારની ક્રિયાઓ આવરી લેવાતી નથી, અને નજીકના વિશેષાધિકારો અલગ છે. કાચા પેકેટ વાંચવા અને લખવા NET_RAW નો હિસ્સો છે, અને tun ઉપકરણ બનાવવા માટે ક્ષમતા અને ઉપકરણ નોડની ઍક્સેસ બંને જરૂરી છે. ઉપકરણ વગરની પ્રક્રિયાને પરવાનગીની ભૂલ મળે છે જે નેટવર્ક સમસ્યા જેવી લાગે છે અને એ નથી.

નામસ્થાન નુકસાનની ત્રિજ્યા નક્કી કરે છે

પોતાના બ્રિજ નેટવર્ક પરનું કન્ટેનર પોતાના loopback, પોતાના ઇન્ટરફેસ અને પોતાના રૂટિંગ ટેબલ સુધી પહોંચે છે. ત્યાં NET_ADMIN આપવાથી VPN ક્લાયન્ટ હોસ્ટના રૂટિંગ નિર્ણયોને સ્પર્શ કર્યા વિના ટનલ બનાવી શકે છે, જે મોટાભાગની કન્ટેનર ઇમેજ ધારી લે છે તે ગોઠવણ છે.

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

ત્રણ પૂર્વશરતો જે એકમાં ભળી જાય છે

VPN કન્ટેનરમાં સ્ટાર્ટઅપ નિષ્ફળતાઓ સામાન્ય રીતે ત્રણ અલગ વસ્તુઓમાંથી એક સાથે સંબંધિત હોય છે: ક્ષમતા, ટનલ ઉપકરણ અને પ્રોટોકોલ માટે કર્નલ સપોર્ટ. ત્રણેય એકસાથે આપવાથી કામ થાય છે, અને તે આગલી નિષ્ફળતાને આભારી ઠેરવવી પણ અશક્ય બનાવે છે. ન્યૂનતમ compose ટુકડો ક્ષમતા આપે છે અને ઉપકરણ નોડ સ્પષ્ટ રીતે પસાર કરે છે:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

ઇમેજના પોતાના દસ્તાવેજીકરણમાં વાંચો કે તેને કયા sysctl ની જરૂર છે, કારણ કે કન્ટેનરમાંનું sysctl વધારાનો વિશેષાધિકાર કે હોસ્ટ-સ્તરની સેટિંગ માંગી શકે છે. જ્યાં ઇમેજ માત્ર યુઝરસ્પેસ મોડને સપોર્ટ કરે છે ત્યાં ઉપકરણની જરૂર જ નથી અને ક્ષમતાઓની યાદી તે મુજબ ઘટે છે.

મોડ નહીં, સાંકડી ક્રિયા આપો

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

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

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

ફેરફાર ચકાસો અને મંજૂરી કેમ છે તે નોંધો

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

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

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

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

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