உங்கள் VPN செயல்முறைக்கு எந்த Linux திறன்கள் தேவை?
இடைமுக அமைப்பு, வழித்தடங்கள், சாதன அணுகல் மற்றும் சாதாரண சாக்கெட்டுகள் தனித்தனி சலுகைகள். CAP_NET_ADMIN வழங்குவதற்கு முன் தோல்வியடைந்த செயல்பாட்டைப் பெயரிடுங்கள்.
VPN டீமனுக்கு சிறப்புரிமை பெற்ற வலைப்பிணைப்பு செயல்பாடுகள் தேவை, இருப்பினும் சாதாரண பயன்பாடுகள் எந்த சிறப்புரிமையும் இல்லாமல் வெளிச்செல்லும் சாக்கெட்டுகளைத் திறக்கின்றன. அந்த இடைவெளியில்தான் பெரும்பாலான திறன் பிழைகள் தொடங்குகின்றன: ஒருவர் அனுமதி பிழையைப் பார்த்து முழுத் தொகுப்பையும் வழங்குகிறார், பின்னர் யாரும் விளக்க முடியாத காரணங்களால் சேவை இயங்குகிறது. கீழே உள்ள பயணம் தோல்வியடைந்த செயல்பாட்டிலிருந்து தொடங்கி, அதை ஒரு அதிகாரத்துடன் இணைத்து, பின்னர் செயல்முறை உண்மையில் இயங்கும் சூழலைச் சரிபார்க்கிறது. வரம்பற்ற root ஆக இயங்குவது சில வரிசைப்படுத்தல்களுக்கு செல்லுபடியாகும் பதில், ஆனால் அது இயல்புநிலை அல்ல, முடிவாக இருக்க வேண்டும்.
தோல்வியடைந்த செயல்பாட்டிலிருந்து தொடங்குங்கள்
பயிற்சியைப் படிக்கும் முன் பிழையைப் படியுங்கள். இடைமுக மாற்றத்தில் «செயல்பாட்டிற்கு அனுமதி இல்லை», சாதன முனையைத் திறக்க மறுப்பு மற்றும் தாழ்ந்த துறையில் bind தோல்வி — இவை வெவ்வேறு மூன்று அனுமதிகளைக் கொண்ட மூன்று வெவ்வேறு சிக்கல்கள். செயல்முறை தொடங்கி முதல் வழித்தட மாற்றத்தில் மட்டும் தோல்வியடைந்தால், இடைமுக உருவாக்கம் ஏற்கனவே வெற்றியடைந்துள்ளது என்றும் அது கூறுகிறது, இது பதிலை மிகவும் குறுக்குகிறது.
சேவை நிறுத்தப்பட்ட நிலையில் தோல்வியை மீண்டும் உருவாக்கி, செயலாக்கம் அனுமதித்தால் அதே பயனரின் கீழ் முன்னணியில் தொடங்குங்கள். நீங்கள் பார்க்கக்கூடிய பிழை ஊகிக்க வேண்டிய பதிவு வரியை விட சிறந்தது, மேலும் திறன் சிக்கலுக்கும் 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, மீண்டும் இணைந்த பிறகு வழித்தட மாற்றங்களுக்குத் தேவை» — அடுத்த நபர் அனுமதியை மீண்டும் விரிவாக்குவதைத் தடுக்க போதுமானது.
பின்னர் ஒவ்வொரு மேம்படுத்தலுக்குப் பிறகும் பயனுள்ள தொகுப்பை மீண்டும் படியுங்கள். விற்பனையாளர்கள் அம்சங்களைச் சேர்க்கின்றனர், படிமங்கள் இயல்புநிலைகளை மாற்றுகின்றன, கடந்த ஆண்டு தேவையற்றதாக இருந்த திறன் யாருக்கும் தெரியாமல் தாங்கியாக மாறலாம்.