ਕਿਵੇਂ ਪਤਾ ਲੱਗੇ ਕਿ ਕਿਹੜੇ systemd ਸੈਂਡਬਾਕਸ ਨੇ ਤੁਹਾਡਾ OpenVPN ਹੁੱਕ ਰੱਦ ਕੀਤਾ

ਹੁੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ 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 ਜੋ ਸਾਰੀ ਸੁਰੱਖਿਆ ਬੰਦ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਠੀਕ ਨਹੀਂ ਹੋਇਆ।