VPN ਨੂੰ ਇਸ ਦੇ ਆਪਣੇ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਸ਼ੁਰੂ ਕਰੋ, ਉੱਥੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਓ, ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਫਿਰ ਵੀ ਹੋਸਟ ਰੂਟ ਰਾਹੀਂ ਹੀ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ: ਨੇਮਸਪੇਸ ਸਿਰਫ਼ ਉਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਲੀਕ ਉਸ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਆਈ ਜੋ ਕਦੇ ਦਾਖਲ ਨਹੀਂ ਹੋਈ। ਇੰਟਰਫ਼ੇਸ, ਪਤੇ, ਰੂਟ, ਫ਼ਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ਸਾਕਟ ਹੀ ਨੇਮਸਪੇਸ ਦੀ ਮਲਕੀਅਤ ਹਨ। ਫ਼ਾਈਲਾਂ, ਖਾਤੇ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੀਆਂ ਸੇਵਾਵਾਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਹੈਰਾਨੀਆਂ ਇੱਥੋਂ ਹੀ ਆਉਂਦੀਆਂ ਹਨ।

ਨੇਮਸਪੇਸ ਕਿਸ ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਸਾਕਟ ਕਿੱਥੇ ਜਨਮ ਲੈਂਦਾ ਹੈ

ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਨੇਮਸਪੇਸ ਵਿੱਚ ਲੈ ਜਾਓ ਅਤੇ ਹੋਸਟ ਇਸਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ; ਅੰਦਰ ਸੁਰੰਗ ਬਣਾਓ ਅਤੇ ਹੋਸਟ ਇਸਨੂੰ ਵੇਖ ਨਹੀਂ ਸਕਦਾ। ਇਹੀ ਨੇਮਸਪੇਸ-ਸੀਮਿਤ VPN ਦਾ ਤੰਤਰ ਹੈ: ਡਿਵਾਈਸ ਅਤੇ ਇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਰੂਟ ਅਜਿਹੇ ਸੰਦਰਭ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ ਜਿੱਥੇ ਸਿਰਫ਼ ਚੁਣੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹੀ ਪਹੁੰਚ ਸਕਦੀਆਂ ਹਨ। ਹੋਸਟ ਆਪਣਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਬਾਹਰ ਦਾ ਸਭ ਕੁਝ ਅਛੋਹ ਰਹਿੰਦਾ ਹੈ।

WireGuard ਲਈ ਬਣਾਉਣ ਦਾ ਸੰਦਰਭ ਮੌਜੂਦਾ ਟਿਕਾਣੇ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: UDP ਸਾਕਟ ਉਸੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਬੱਝਦਾ ਹੈ ਜਿੱਥੇ ਇੰਟਰਫ਼ੇਸ ਬਣਾਇਆ ਗਿਆ ਸੀ, ਭਾਵੇਂ ਡਿਵਾਈਸ ਕਿਤੇ ਹੋਰ ਚਲਾ ਜਾਵੇ। ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕਟ ਕਿਹੜੀ ਰਾਊਟਿੰਗ ਟੇਬਲ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ, ਇਹ ਉਸੇ ਜਨਮ-ਥਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਸਾਕਟ ਸਾਥੀ ਵੱਲ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਸੰਦਰਭ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇੰਟਰਫ਼ੇਸ ਖੋਜਦਾ ਹੈ ਅਤੇ ਹੱਥ ਮਿਲਾਉਣਾ ਕਦੇ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦਾ। ਪਹਿਲਾਂ ਇਸਦਾ ਜਨਮ-ਥਾਂ, ਫਿਰ ਮੌਜੂਦਾ ਟਿਕਾਣਾ ਜਾਂਚੋ।

ਨੇਮਸਪੇਸ ਕੀ ਵੱਖ ਨਹੀਂ ਕਰਦਾ

ਇੱਥੇ ਕੁਝ ਵੀ ਫ਼ਾਈਲ ਸਿਸਟਮ, ਖਾਤੇ ਜਾਂ ਭੇਤ ਵੱਖ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੀਮਾ ਇਸ ਲਈ ਨਹੀਂ ਦਿਸਦੀ ਕਿ ਤੁਸੀਂ ਨੇਮਸਪੇਸ ਬਣਾਇਆ। ਰਿਜ਼ਾਲਵਰ ਸੰਰਚਨਾ ਇੱਕ ਫ਼ਾਈਲ ਹੈ, ਇਸ ਲਈ ਅੰਦਰ ਦੀ ਪ੍ਰਕਿਰਿਆ ਅਜੇ ਵੀ ਹੋਸਟ ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੀ ਸੈਟਿੰਗ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਅਤੇ ਆਪਣੀ ਕਵੈਰੀ ਉਸ ਰੂਟ ਰਾਹੀਂ ਬਾਹਰ ਭੇਜ ਸਕਦੀ ਹੈ ਜੋ ਇਹ ਸੰਕੇਤ ਕਰਦਾ ਹੈ। ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਚੱਲ ਰਹੇ ਬ੍ਰੋਕਰ ਜਾਂ ਸਿਸਟਮ ਸੇਵਾ ਨੂੰ ਸੌਂਪਦੀ ਹੈ, ਉਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਸੰਦਰਭ ਦੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਸੀਮਾ ਕਦੇ ਨਹੀਂ ਬਣੀ ਸੀ।

ਹੱਲ /etc/netns/<name>/resolv.conf 'ਤੇ ਪ੍ਰਤੀ-ਨੇਮਸਪੇਸ ਫ਼ਾਈਲ ਹੈ, ਜਾਂ ਤਿਆਰ ਕੀਤੀ ਫ਼ਾਈਲ ਦਾ bind mount, ਜੋ ਅੰਦਰੋਂ ਪਹੁੰਚਯੋਗ ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਹੋਸਟ 'ਤੇ /etc/resolv.conf ਸੋਧਣ ਨਾਲ ਨੇਮਸਪੇਸ ਜੋ ਵੇਖਦਾ ਹੈ ਉਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਨਿਯੁਕਤੀ ਹੀ ਨਿਯੰਤਰਣ ਹੈ

ਤੁਹਾਨੂੰ ਜੋ ਵੱਖਰਾਪਣ ਮਿਲਦਾ ਹੈ ਉਹ ਬਿਲਕੁਲ ਅੰਦਰ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਵੱਖਰਾਪਣ ਹੈ। ਨੇਮਸਪੇਸ ਦੇ exec ਸਹਾਇਕ ਰਾਹੀਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸ਼ੈੱਲ, ਅਤੇ ਇਹ ਜੋ ਵੀ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅੰਦਰ ਹੀ ਰਹਿੰਦਾ ਹੈ; ਹੋਸਟ ਸੈਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤੀ ਡੈਸਕਟਾਪ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ। ਸੰਦਰਭ ਬਣਾਓ, ਡਿਵਾਈਸ ਹਿਲਾਓ, ਫਿਰ ਦੋਵੇਂ ਪਾਸੇ ਸਾਬਤ ਕਰੋ:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰੋਂ ਪਹਿਲਾ wg show ਅਤੇ ਹੋਸਟ ਤੋਂ ਦੂਜਾ ਪੜ੍ਹੋ, ਅਤੇ ਉਮੀਦ ਰੱਖੋ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਸਾਥੀ ਦੀ ਸੂਚੀ ਦੇਵੇਗਾ। ਜੇ ਦੋਵੇਂ ਦੇਣ, ਤਾਂ ਡਿਵਾਈਸ ਕਦੇ ਹਿਲਿਆ ਹੀ ਨਹੀਂ; ਜੇ ਕੋਈ ਨਾ ਦੇਵੇ, ਤਾਂ ਇਹ ਕਿਤੇ ਹੋਰ ਗਿਆ ਹੈ। ਜਦੋਂ ਲਾਂਚਰ ਸੇਵਾ ਪ੍ਰਬੰਧਕ ਹੋਵੇ, ਤਾਂ unit ਫ਼ਾਈਲ ਸੋਧਣੀ ਹੁੰਦੀ ਹੈ, ਡੈਸਕਟਾਪ ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ। ਨੇਮਸਪੇਸ ਸੈਟਿੰਗ ਤੋਂ ਬਿਨਾਂ unit ਡੈਮਨ ਨੂੰ ਹੋਸਟ ਸੰਦਰਭ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚੁੱਪਚਾਪ ਰੱਦ ਕਰਦਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਸੰਦਰਭ ਤੋਂ ਪਰਖੋ

ਐਪਲੀਕੇਸ਼ਨ ਜੋ ਬਾਈਨਰੀ ਅਤੇ ਜੋ ਵਰਤੋਂਕਾਰ ਵਰਤਦੀ ਹੈ, ਉਹਨਾਂ ਨਾਲ ਹੀ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰ ਜਾਂਚ ਚਲਾਓ। DNS ਅਤੇ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਜਿਸ IPv6 ਰੂਟ ਬਾਰੇ ਤੁਸੀਂ ਕਦੇ ਨਹੀਂ ਸੋਚਿਆ, ਉਹ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਆਮ ਰਾਹ ਹੈ। ਤੁਹਾਡੇ ਆਪਣੇ ਸ਼ੈੱਲ ਤੋਂ ਕੀਤੀ ਜਾਂਚ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡਾ ਸ਼ੈੱਲ ਵੱਖ ਹੈ।

ਫਿਰ ਹੋਸਟ 'ਤੇ ਉਹੀ ਜਾਂਚ ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਵੱਖਰੇ ਹਨ: ਅੰਦਰ ਸੁਰੰਗ ਦਾ ਪਤਾ ਅਤੇ ਲੋੜੀਂਦਾ ਨਿਕਾਸ, ਬਾਹਰ ਹੋਸਟ ਰੂਟ ਅਤੇ ਦਫ਼ਤਰ ਨਿਕਾਸ, ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਨਾਮ ਨਾਲ। ਨੇਮਸਪੇਸਾਂ ਨੂੰ ਪ੍ਰੋਟੋਕਾਲ ਦੀ ਥਾਂ ਤੈਨਾਤੀ ਅਨੁਸਾਰ ਨਾਮ ਦਿਓ, ਤਾਂ ਜੋ ਸਫ਼ਾਈ ਸਕ੍ਰਿਪਟ ਦੋ ਨੂੰ ਗਲਤ ਨਾ ਸਮਝੇ।

ਫ਼ਾਰਵਰਡਿੰਗ, ਅਸਫ਼ਲਤਾ ਨੀਤੀ ਅਤੇ ਸਫ਼ਾਈ

ਗੇਟਵੇ ਲਈ ਫ਼ਾਰਵਰਡਿੰਗ ਜਾਣ-ਬੁੱਝ ਕੇ ਚਾਲੂ ਕਰੋ ਅਤੇ ਤੈਅ ਕਰੋ ਕਿ ਸੁਰੰਗ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਨੇਮਸਪੇਸ ਅੰਦਰ ਲਗਾਏ ਰੂਟ ਨੂੰ ਰੋਕਦਾ ਨਹੀਂ, ਇਸ ਲਈ ਹੋਸਟ ਵੱਲ ਬਦਲਵਾਂ ਰੂਟ ਬਣਾਉਣ 'ਤੇ ਉਹੀ ਵਰਤਿਆ ਜਾਵੇਗਾ। ਇਹ ਨੀਤੀ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਇਸਨੂੰ ਪਰਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਲਿਖ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ।

ਨੇਮਸਪੇਸਾਂ ਦੇ ਨਾਮ, ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਸੰਰਚਨਾ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਦਰਜ ਕਰੋ, ਤਾਂ ਜੋ ਸਫ਼ਾਈ ਸਿਰਫ਼ ਉਹੀ ਹਟਾਏ ਜੋ ਤੈਨਾਤੀ ਨੇ ਬਣਾਇਆ। ਰੋਲਬੈਕ ਦੌਰਾਨ ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਰੀਸੈਟ ਕਰਨਾ ਸਫ਼ਾਈ ਨੂੰ ਰੁਕਾਵਟ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਪੰਨਾ network_namespaces(7) ਛੋਟਾ ਹੈ ਅਤੇ ਉਸ ਰਾਹ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹਨ ਯੋਗ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ