WireGuard ਸੁਰੰਗ ਤੋਂ ਬਾਹਰ ਇੱਕ Linux ਪ੍ਰਕਿਰਿਆ ਕਿਵੇਂ ਚਲਾਈਏ

ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਉਸਦਾ ਆਪਣਾ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਦਿਓ ਤਾਂ ਜੋ ਉਹ ਪੂਰੀ ਸੁਰੰਗ ਵਾਲੇ WireGuard ਹੋਸਟ ਤੋਂ ਬਾਹਰ ਨਿਕਲੇ, ਫਿਰ ਉਸਨੂੰ ਰੋਕਣ ਵਾਲੇ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਮਾਰਕਿੰਗ ਨਿਯਮ ਠੀਕ ਕਰੋ।

ਰੂਟ ਸੋਧ ਕੇ ਤੁਸੀਂ ਕਿਸੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਪੂਰੀ ਸੁਰੰਗ ਵਾਲੇ WireGuard ਹੋਸਟ ਤੋਂ ਛੋਟ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਰੂਟ ਮੰਜ਼ਿਲ ਦੇ ਅਨੁਸਾਰ ਰਾਹ ਚੁਣਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਜਿਸ ਨੂੰ ਛੋਟ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ, ਇਸ ਲਈ ਕਰਨਲ ਕੋਲ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ। ਕੰਮ ਕਰਨ ਵਾਲਾ ਤਰੀਕਾ ਹੈ ਉਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਸਦਾ ਆਪਣਾ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਦੇਣਾ: ਆਪਣਾ ਇੰਟਰਫੇਸ, ਪਤੇ ਅਤੇ ਡਿਫਾਲਟ ਰੂਟ ਵਾਲਾ ਨੇਮਸਪੇਸ, ਜੋ veth ਜੋੜੀ ਨਾਲ ਹੋਸਟ ਨਾਲ ਜੁੜਿਆ ਹੈ। ਮੈਂ ਇਹ Ubuntu 24.04 ਉੱਤੇ wireguard-tools 1.0.20210914 ਨਾਲ ਚਲਾਇਆ, ਅਤੇ ਨੇਮਸਪੇਸ ਕਦੇ ਵੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ — ਹੋਸਟ ਦੀ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ ਅਤੇ ਸੁਰੰਗ ਦੇ ਮਾਰਕਿੰਗ ਨਿਯਮ ਸਮੱਸਿਆ ਸਨ।

ਪਹਿਲਾਂ ਉਹ ਕਿਸਮ ਦਾ ਸੰਦਰਭ ਚੁਣੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ

ਅਮਲ ਵਿੱਚ ਦੋ ਰੂਪ ਦਿਸਦੇ ਹਨ। ਜੇ ਹੋਸਟ ਪੂਰੀ ਸੁਰੰਗ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੇ ISP ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਣਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੂਜਾ ਨੇਮਸਪੇਸ ਬਣਾਉਂਦੇ ਹੋ, ਉਸਨੂੰ ਹੋਸਟ ਨਾਲ ਜੋੜਦੇ ਹੋ ਅਤੇ ਹੋਸਟ ਨੂੰ ਉਸ ਲਈ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਅਤੇ ਅਨੁਵਾਦ ਕਰਨ ਦਿੰਦੇ ਹੋ। ਜੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ VPN ਇੰਟਰਫੇਸ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਸਿਰਫ ਅੰਦਰ ਚੱਲਣ ਵਾਲਾ ਆਦੇਸ਼ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਮ ip netns exec ਕੇਸ ਹੈ ਅਤੇ ਰੂਟਿੰਗ ਦਾ ਬਹੁਤਾ ਕੰਮ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਾ ਹੈ।

ਕੋਈ ਵੀ ਰੂਪ ਤੁਹਾਨੂੰ ਇੱਕੋ ਪ੍ਰਕਿਰਿਆ ਆਈਡੀ ਤੱਕ ਸੀਮਿਤ ਨਿਯਮ ਨਹੀਂ ਦਿੰਦਾ। Netfilter ਪਤੇ, ਪੋਰਟ, ਮਾਰਕ ਅਤੇ ਇੰਟਰਫੇਸ ਮਿਲਾਉਂਦਾ ਹੈ; ਹਰ ਪ੍ਰਕਿਰਿਆ ਲਈ ਰੂਟਿੰਗ ਟੇਬਲ ਨਹੀਂ ਹੈ। ਮਾਰਕਿੰਗ ਟ੍ਰੈਫਿਕ ਨੂੰ ਦਿਸ਼ਾ ਦੇ ਸਕਦੀ ਹੈ, ਪਰ ਮਾਰਕ ਉਹਨਾਂ ਪੈਕਟਾਂ ਉੱਤੇ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣ ਲਿਆ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਪਰਤ ਹੇਠਾਂ ਦੀ ਉਹੀ ਸਮੱਸਿਆ ਹੈ। ਨੇਮਸਪੇਸ ਉਸ ਪ੍ਰਕਿਰਿਆ ਦਰੱਖਤ ਲਈ ਪੂਰਾ ਸਟੈਕ ਵੱਖ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹੀ ਆਮ ਜਵਾਬ ਹੈ।

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

ਦੂਜਾ ਸੰਦਰਭ ਬਣਾਓ ਅਤੇ ਉਸਨੂੰ ਹੋਸਟ ਨਾਲ ਜੋੜੋ

ਇੱਕ ਉਦਾਹਰਨੀ ਬਣਤਰ: ਹੋਸਟ ਵਿੱਚ ਡਿਫਾਲਟ ਰੂਟ ਢੋਣ ਵਾਲਾ WireGuard ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇclearnet ਨਾਮ ਦਾ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਹੈ, ਜੋ veth ਜੋੜੀ ਨਾਲ ਹੋਸਟ ਨਾਲ ਜੁੜਿਆ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਪਤੇ ਉਦਾਹਰਨਾਂ ਹਨ।

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

ਇਹ ਨੇਮਸਪੇਸ ਹੁਣ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ। ਹੋਸਟ ਨੂੰ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਨਾ ਅਤੇ ਸਰੋਤ ਪਤਾ ਮੁੜ ਲਿਖਣਾ ਪੈਂਦਾ ਹੈ, ਕਿਉਂਕਿ 192.168.100.0/24 ਨਿੱਜੀ ਹੈ ਅਤੇ ਉੱਪਰਲੇ ਰਾਊਟਰ ਕੋਲ ਇਸ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਦਾ ਕੋਈ ਰੂਟ ਨਹੀਂ ਹੈ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਨੇਮਸਪੇਸ ਦਾ ਪਾਸਾ ਪੁਸ਼ਟੀ ਕਰੋ।ip netns exec clearnet ip route ਨੂੰ veth ਰੂਟ ਅਤੇ 192.168.100.1 ਰਾਹੀਂ ਡਿਫਾਲਟ ਰੂਟ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸ ਪਤੇ ਉੱਤੇ ping ਦਾ ਜਵਾਬ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਹੋਸਟ ਦੇ ਪਤੇ ਉੱਤੇ ping ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਪਤੇ ਜਾਂ ਲਿੰਕ ਦੀ ਸਥਿਤੀ ਗਲਤ ਹੈ ਅਤੇ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।

ਜਦੋਂ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ ਪਰ ਕੁਝ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ FORWARD ਪੜ੍ਹੋ

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

ਕੁਝ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਚੇਨ ਪੜ੍ਹੋ:

iptables -S FORWARD
nft list chain inet filter forward

ਫਿਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਆਗਿਆ ਦਿਓ, ਕਾਊਂਟਰਾਂ ਨਾਲ, ਤਾਂ ਜੋ ਪਤਾ ਲੱਗੇ ਕਿ ਨਿਯਮ ਕਦੇ ਮਿਲਿਆ ਹੈ ਜਾਂ ਨਹੀਂ:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

ਸਿਫ਼ਰ ਪੈਕਟ ਕਾਊਂਟਰ ਵਾਲਾ ਨਿਯਮ ਰਾਹ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਜਾਂ ਤਾਂ ਇੰਟਰਫੇਸ ਦੇ ਨਾਮ ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਤੋਂ ਵੱਖ ਹਨ, ਜਾਂ ਚੇਨ ਦੇ ਪਿਛਲੇ ਨਿਯਮ ਨੇ ਪੈਕਟ ਨੂੰ ਪਹਿਲਾਂ ਸਵੀਕਾਰ, ਰੱਦ ਜਾਂ ਵਾਪਸ ਕੀਤਾ ਹੈ। ਕ੍ਰਮ ਠੀਕ ਕਰੋ, ਨਿਯਮ ਦਾ ਪਾਠ ਨਹੀਂ।

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

ਸੁਰੰਗ ਦੇ ਮਾਰਕਿੰਗ ਨਿਯਮਾਂ ਨੂੰ ਨਵੇਂ ਰਾਹ ਤੋਂ ਦੂਰ ਰੱਖੋ

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

ਦੋ ਜੋੜ ਰਾਹ ਵੱਖ ਕਰਦੇ ਹਨ। ਨੇਮਸਪੇਸ ਸਬਨੈੱਟ ਲਈ mangle ਚੇਨ ਵਿੱਚ ਜਲਦੀ ਵਾਪਸ ਜਾਓ, ਅਤੇ ਇੱਕ ਸਰੋਤ-ਅਧਾਰਿਤ ਨਿਯਮ ਜੋੜੋ ਜੋ ਉਸ ਸਬਨੈੱਟ ਨੂੰ ਮੁੱਖ ਟੇਬਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

ਮੇਰੇ ਹੋਸਟ ਉੱਤੇ ਤਰਜੀਹ 100 ਸੁਰੰਗ ਦੇ ਨਿਯਮਾਂ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਉਸ ਸਰੋਤ ਲਈ ਆਮ ਟੇਬਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਸੰਖਿਆ ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਕਾਪੀ ਨਾ ਕਰੋ: ਜਿਹੜੀਆਂ ਤਰਜੀਹਾਂwg-quick ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਉਹ ਵਰਜਨਾਂ ਅਤੇ IPv4 ਤੇ IPv6 ਸੈੱਟਅਪਾਂ ਵਿੱਚ ਵੱਖਰੀਆਂ ਹਨ, ਇਸ ਲਈ ਚਲਾਓ ip rule show ਅਤੇ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਉੱਤੇ ਸੁਰੰਗ ਦੇ ਨਿਯਮਾਂ ਤੋਂ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲੀ ਤਰਜੀਹ ਚੁਣੋ।

ਨਿਯਮ ਸੂਚੀ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਸਰੋਤ-ਖਾਸ ਖੋਜ ਨਾਲ ਜਾਂਚੋ:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

ਜੇ ਪਹਿਲਾ ਆਦੇਸ਼ WireGuard ਇੰਟਰਫੇਸ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਨਵਾਂ ਨਿਯਮ ਅਜੇ ਸੁਰੰਗ ਨੀਤੀ ਤੋਂ ਪਹਿਲਾਂ ਨਹੀਂ ਹੈ। ਜੇ ਇਹ WAN ਇੰਟਰਫੇਸ ਦੱਸਦਾ ਹੈ ਜਦੋਂ ਕਿ ਦੂਜਾ ਅਜੇ ਵੀ veth ਡਿਫਾਲਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਹੋਸਟ ਅਤੇ ਨੇਮਸਪੇਸ ਸਹਿਮਤ ਨਹੀਂ ਹਨ ਅਤੇ ਤੁਹਾਨੂੰ ਦੋਵੇਂ ਰੂਟਿੰਗ ਟੇਬਲ ਦੁਬਾਰਾ ਪੜ੍ਹਨੇ ਚਾਹੀਦੇ ਹਨ।

ਉਹ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ

ਆਦੇਸ਼ ਸ਼ੁਰੂ ਕਰਨਾ ਇੱਕ ਲਾਈਨ ਹੈ, ਪਰ ਉਹ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸੱਚਮੁੱਚ ਸਾਕਟ ਬਣਾਉਂਦੀ ਹੈ।ip netns exec clearnet curl -s https://ifconfig.me ਸਭ ਤੋਂ ਛੋਟਾ ਇਮਾਨਦਾਰ ਟੈਸਟ ਹੈ: ਇਹ ਉਹ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਨੇਮਸਪੇਸ ਦੁਨੀਆ ਨੂੰ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਜੋ ਹੋਸਟ ਵਰਤਦਾ।

ਸੇਵਾ ਲਈ, ਨੇਮਸਪੇਸ ਨੂੰ ਪਾਥ ਨਾਲ ਜੋੜੋ ਤਾਂ ਜੋ ਪ੍ਰਕਿਰਿਆ ਆਪਣੀ ਸਾਰੀ ਉਮਰ ਇਸ ਵਿੱਚ ਰਹੇ:

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

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

ਨਾਮ ਹੱਲ ਕਰਨ ਲਈ ਆਪਣਾ ਫੈਸਲਾ ਚਾਹੀਦਾ ਹੈ। ਨੇਮਸਪੇਸ ਬਣਾਉਣ ਨਾਲ ਇਸਨੂੰ ਰਿਜ਼ੌਲਵਰ ਸੰਰਚਨਾ ਨਹੀਂ ਮਿਲਦੀ; ਹਰ ਨੇਮਸਪੇਸ ਲਈ ਫਾਈਲਾਂ ਇਸ ਰਾਹੀਂ ਸਮਰਥਿਤ ਹਨ /etc/netns/<name>/resolv.conf, ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਗਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੋਣ ਵਾਲਾ ਵਿਵਹਾਰ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ। IPv6 ਨੂੰ ਵੀ ਉਹੀ ਵਿਵਹਾਰ ਚਾਹੀਦਾ ਹੈ: ਜੇ ਨੇਮਸਪੇਸ ਵਿੱਚ v6 ਡਿਫਾਲਟ ਰੂਟ ਨਹੀਂ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ v6 ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਬੇਨਤੀਆਂ ਪਿੱਛੇ ਹਟਣ ਤੋਂ ਪਹਿਲਾਂ ਅਟਕ ਸਕਦੀਆਂ ਹਨ, ਜੋ ਟੁੱਟੀ ਸੁਰੰਗ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।

ਫਰੇਮਿੰਗ ਜਾਂਚੋ, ਸਿਰਫ ਬਾਹਰ ਨਿਕਲਣ ਵਾਲਾ ਪਤਾ ਨਹੀਂ

ਕੰਮ ਕਰਦਾ ਜਨਤਕ ਪਤਾ ਰੂਟ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਪੂਰੀ ਲੋੜ ਨਹੀਂ। ਬਾਕੀ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ:

  • ip netns exec clearnet ip route get 1.1.1.1 veth ਡਿਫਾਲਟ ਦਿਖਾਉਂਦਾ ਹੈ, WireGuard ਇੰਟਰਫੇਸ ਨਹੀਂ।
  • ਬੇਨਤੀ ਚੱਲਦਿਆਂ ਦੋਵੇਂ ਨਿਯਮਾਂ ਦੇ FORWARD ਕਾਊਂਟਰ ਵਧਦੇ ਹਨ।
  • ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਤੁਹਾਡੇ ਅਨੁਸਾਰ ਨੇਮਸਪੇਸ inode ਦੱਸਦੀ ਹੈ।
  • ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਨੇਮਸਪੇਸ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ; ਪਹਿਲਾਂ ਚੱਲਣ ਵਾਲੀ unit ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਹੋਰ ਮਾੜਾ, ਨੇਮਸਪੇਸ ਤੋਂ ਬਾਹਰ ਚੱਲਦੀ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ