ඔබේ OpenVPN හුක් එක ප්‍රතික්ෂේප කළේ කුමන systemd සෑන්ඩ්බොක්ස් එකදැයි සොයා ගන්නේ කෙසේද

ඔබ එය root ලෙස අතින් ධාවනය කරන විට හුක් එක ක්‍රියා කරන අතර ආපසු දෙයි Operation not permitted සේවාව එය ආරම්භ කරන මොහොතේ. එම ධාවන දෙක අතර ගොනුව වෙනස් නොවීය; පරිසරය වෙනස් විය. systemd ක්‍රියාවලියට කුඩා ලෝකයක් දෙයි: අඩු හැකියාවන්, වෙනත් /dev, කියවීමට පමණක් වන ගොනු පද්ධති මාර්ග සහ කාර්යයන් සඳහා උඩු සීමාවක්. අසාර්ථකත්වය එක් නිශ්චිත ක්‍රියාවක් ප්‍රතික්ෂේප කළ සීමාවක් ලෙස කියවන්න, කැඩුණු ස්ක්‍රිප්ටයක් ලෙස නොව.

ප්‍රතික්ෂේප වූ ක්‍රියාවෙන් ආරම්භ කරන්න

unit එක අසාර්ථක විය යනුවෙන් කියන ලොග් පේළිය ඔබට පාහේ කිසිවක් නොකියයි. ප්‍රයෝජනවත් පේළිය ප්‍රතික්ෂේප වූ ඇමතුම නම් කරයි: විවෘත කළ නොහැකි උපාංග නෝඩය, ලිවිය නොහැකි නාමාවලිය, සෑදිය නොහැකි namespace. එක් නියෝගයක් පවා ස්පර්ශ කිරීමට පෙර එම ඇමතුම සොයන්න, මන්ද එක් එක් එක වෙනස් සීමාවකට අනුරූප වේ. පසුව පැකේජය එවූ ගොනුව වෙනුවට සැබවින්ම ධාවනය වූ unit එක කියවන්න, drop-in ඇතුළුව.

පහත විමසුම කොටසෙහි මාර්ගය, drop-in නාමාවලි සහ උපාංගයක් හෝ ගොනු පද්ධතියක් ප්‍රතික්ෂේප කිරීමට වැදගත් ගුණාංග මුද්‍රණය කරයි. කුමන සීමාව අදාළද යන්න තීරණය කිරීමට පෙර සියල්ල කියවන්න:

systemctl show "[email protected]" -p FragmentPath -p DropInPaths -p PrivateDevices -p DevicePolicy -p DeviceAllow -p ProtectHome -p ProtectSystem -p TasksMax
journalctl -u "[email protected]" -b --no-pager | grep -iE 'operation not permitted|permission denied|cannot open|failed'

එම කොටසෙහි කිසිවක් ලියන්නේ නැත. ප්‍රතික්ෂේප වූ ඇමතුම ජර්නලයේ නොමැති නම්, නියෝග අනුමාන කිරීම වෙනුවට එක් ධාවනයක් සඳහා සේවාලාභියාගේ විස්තර මට්ටම වැඩි කරන්න. ධාවනය වන ක්‍රියාවලියක් සාක්ෂි දෙන්නේ unit එක ආරම්භ වූ බවයි, හුක් එක අවශ්‍ය වරප්‍රසාද සමඟ ධාවනය වූ බව නොවේ.

namespace එකට TUN උපාංගයක් කිසිදා භාවිත නොකරන mount අයිතිවාසිකම් අවශ්‍යයි

එකම හුක් එකක් තුළ සමාන ලෙස පෙනෙන ක්‍රියා දෙකකට වෙනස් අවසර පැතිකඩ ඇත. /dev/net/tun විවෘත කිරීම සහ අතුරුමුහුණත සෑදීම සඳහා ජාල පරිපාලනය සහ එම නෝඩයට ප්‍රවේශය අවශ්‍යයි. නම් කළ ජාල namespace එකක් සෑදීමටද mount කාර්යය අවශ්‍යයි, මන්ද namespace මෙවලම නව /sys දසුනක් mount කර තත්ත්ව නාමාවලිය එහි තැනට බඳියි. ඉහළ ප්‍රවාහ සේවාලාභී unit mount පරිපාලනය හිතාමතාම එහි සීමා කුලකයෙන් පිටත තබයි, එබැවින් namespace පියවර ප්‍රතික්ෂේප වේ, නමුත් උමගම එහිම ක්‍රියා කරන්නට තිබුණි.

එබැවින් උපාංග නෝඩය දීම ස්ක්‍රිප්ටය ගලවා නොගනී. උපාංග අවසරය එක් ප්‍රශ්නයකට පිළිතුරු දෙයි, මෙම ක්‍රියාවලියට මෙම නෝඩය විවෘත කළ හැකිද, සහ namespace ප්‍රශ්නය වෙනත් එකකි. කිසිවක් පුළුල් කිරීමට පෙර අසාර්ථක ඇමතුම එහි හැකියාව සමඟ ගළපන්න.

ඔබේ shell හි කරන පරීක්ෂණයක් අසීමිත root සතු සෑම හැකියාවක්ම උරුම කර ගනී, සහ unit එක එහි සීමා කුලකය රඳවා ගත් දේ උරුම කර ගනී. එම ධාවන දෙක වෙනස් පරීක්ෂණ වේ ද්විමය ගොනුව සමාන වුවද.

උපාංග, ආරක්ෂිත මාර්ග සහ කාර්ය සීමා

ප්‍රතික්ෂේප වූ ක්‍රියාව දැනගත් පසු, නියෝග කණ්ඩායම් තුනක් බොහෝ අසාර්ථකත්ව පැහැදිලි කරයි. උපාංග වලට ප්‍රවේශය පාලනය කරන්නේ PrivateDevices, එය /dev අවම ව්‍යාජ උපාංග කුලකයකින් ප්‍රතිස්ථාපනය කරයි, සහ DevicePolicy සමඟ DeviceAllow, ඒවා cgroup අවසර දෙන දේ තීරණය කරයි. /dev/net/tun එම අවම කුලකයේ කොටසක් නොවේ, එබැවින් PrivateDevices=yes සහිත unit එකකට උපාංග ප්‍රතිපත්තිය කුමක් කීවද එය විවෘත කළ නොහැක.

ගොනු පද්ධති ආරක්ෂණය දෙවන ප්‍රශ්නයට පිළිතුරු දෙයි. ProtectHome=yes සාදයි /home, /root සහ /run/user ප්‍රවේශ විය නොහැකි ලෙස, සහ ProtectSystem=full සාදයි /usr, /boot සහ /etc කියවීමට පමණක් ලෙස. එබැවින් තමන්ගේම වින්‍යාස ගොනුව අසල ලියන හුක් එක ඔබේ shell හි ක්‍රියා කර unit යටතේ අසාර්ථක වේ, නැති වූ හැකියාවක් මෙන් එකම අවසර හැඩය සමඟ. ලිවිය හැකි ආදානය ප්‍රතිපත්තිය අවසර දෙන මාර්ගයකට ගෙන යන්න, හෝ පටු ReadWritePaths= සටහනක් එක් කරන්න.

සම්පත් සීමා තුන්වන කණ්ඩායම වන අතර අඩුම පැහැදිලි. TasksMax= unit එකට සෑදිය හැකි කාර්ය කීයක්ද යන්න සීමා කරයි, සහ ගොනු විස්තරකාරක සීමාව socket සහ හසුරු සඳහා එලෙසම හැසිරේ. සීමාව ඉක්මවා වර්ධනය වූ යෙදවුම අවසර දෝෂයක් වෙනුවට සම්පත් දෝෂයකින් අසාර්ථක වේ, එබැවින් නිවැරදි පණිවිඩය තවමත් වැදගත් වේ.

namespace පියවර හුක් එකෙන් ඉවත් කරන්න

සේවාලාභියා නොතිබිය යුතු වරප්‍රසාදයක් අවශ්‍ය සූදානම එහිම unit එකට අයත් වේ. සේවාලාභියාට පෙර ධාවනය වන, එහි ප්‍රතිඵලය රඳවා ගන්නා සහ සම්බන්ධතාවට පෙර අනුපිළිවෙලට ඇති oneshot එක namespace පියවරට අවශ්‍ය දේ දෙයි, එම අයිතිවාසිකම් උමග ක්‍රියාවලියට නොදී. පසුව සේවාලාභියා තම up හුක් එකෙන් ස්ක්‍රිප්ටය ඇමතීම වෙනුවට එම unit එකට යොමු වේ.

පහත අච්චුව ආරම්භක හැඩයකි, නොකියවා යෙදිය යුතු දෙයක් නොවේ. එය සූදානම වරප්‍රසාදය ජීවත් වන තැනම තබා උමග unit එක ස්පර්ශ නොකර තබයි:

# /etc/systemd/system/[email protected]
[Unit]
Description=Namespace preparation for %i
Before=openvpn-client@%i.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/netns-up.sh %i
CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target

පැකේජ කළ unit එක සංස්කරණය කිරීම වෙනුවට drop-in එකකින් අනුපිළිවෙල එක් කරන්න, එවිට උත්ශ්‍රේණිගත කිරීමකට ඔබේ වෙනස නිශ්ශබ්දව ඉවත් කළ නොහැක. නාමාවලිය අවස්ථා නාමයට බැඳී ඇත, එබැවින් දෙවන පැතිකඩට එහිම ගොනුවක් අවශ්‍යයි:

sudo mkdir -p /etc/systemd/system/[email protected]
sudo tee /etc/systemd/system/[email protected]/10-namespace.conf >/dev/null <<'CONF'
[Unit]
[email protected]
[email protected]
CONF
sudo systemctl daemon-reload

වෙනසෙන් පසු එම ඇමතුමම නැවත කරන්න

එම ඇමතුමම වෙනස් ප්‍රතිඵලයක් ලබා දුන් විට පමණක් අලුත්වැඩියාව තහවුරු වේ. unit දෙකම නැවත අරඹන්න, අසාර්ථක වූ ක්‍රියාව ධාවනය කරන්න, සහ එහි ප්‍රතිඵලය වෙනසට පෙර සුරකින ලද ජර්නල් පේළිය සමඟ සසඳන්න. හුක් එක නැවත කිසිදා ධාවනය නොවන අතර unit එක ආරම්භ වීම අලුත්වැඩියාවක් නොවේ.

පහත අනුපිළිවෙල සංසන්දනය අවංකව තබයි, මන්ද එය unit එකේ වර්ණය නොව ප්‍රතික්ෂේප වූ ඇමතුම පරීක්ෂා කරයි. එහි ප්‍රතිදානය වෙනසට පෙර ග්‍රහණය කළ ජර්නල් පේළිය අසල සුරකින්න:

sudo systemctl restart "[email protected]" "[email protected]"
systemctl status "[email protected]" --no-pager
journalctl -u "[email protected]" -b --no-pager | grep -c 'Operation not permitted'
ip -brief addr show tun0

අවසන් පේළිය කියවීම වෙනුවට ප්‍රතික්ෂේප ගණන් කරන්න, මන්ද හුක් එකක් අසාර්ථක වී, නැවත උත්සාහ කර සාර්ථක විය හැක, සහ සීමාව සෙලවුණේද යන්න ගණනින් පමණක් පෙනේ. drop-in එකේ ඔබ ලිහිල් කළ නියෝගය සහ හේතුව නම් කරන අදහසක් තබන්න, මන්ද ඊළඟ උත්ශ්‍රේණිගත කිරීම ඔබේ වින්‍යාසය පැකේජයේ පෙරනිමිය සමඟ සසඳයි. සියලු ආරක්ෂණ ක්‍රියා විරහිත කිරීමෙන් පසුව පමණක් ආරම්භ වන unit එක අලුත්වැඩියා කර නැත.