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 கோப்பில் நிரந்தரத் தேவையாக விவரிக்கக்கூடாது.

ஒவ்வொரு திறனுக்கும் அருகில் காரணத்தை எழுதுங்கள்: எந்த செயல்பாட்டிற்கு அது தேவைப்பட்டது, அது இல்லாமல் என்ன தோல்வியடைகிறது. அந்தக் குறிப்பு பிம்ப புதுப்பிப்புகளுக்குப் பிறகும் நிலைத்திருக்கும், மேலும் மதிப்பாய்வு செய்யப்பட்ட சலுகைப் பட்டியலுக்கும் நகலெடுத்து ஒட்டி வளர்ந்த பட்டியலுக்கும் உள்ள வேறுபாடு அதுவே.