ਤੁਹਾਡੇ 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, ਮੁੜ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਰੂਟ ਬਦਲਾਵਾਂ ਲਈ ਲੋੜੀਂਦਾ» — ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇਜਾਜ਼ਤ ਦੁਬਾਰਾ ਚੌੜੀ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਕਾਫ਼ੀ ਹੈ।
ਫਿਰ ਹਰ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਪ੍ਰਭਾਵੀ ਸੈੱਟ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਵਿਕਰੇਤਾ ਸੁਵਿਧਾਵਾਂ ਜੋੜਦੇ ਹਨ, ਇਮੇਜ ਡਿਫ਼ਾਲਟ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਪਿਛਲੇ ਸਾਲ ਗ਼ੈਰ-ਜ਼ਰੂਰੀ ਰਹੀ ਸਮਰੱਥਾ ਕਿਸੇ ਨੂੰ ਪਤਾ ਲੱਗੇ ਬਿਨਾਂ ਭਾਰ-ਵਾਹਕ ਬਣ ਸਕਦੀ ਹੈ।