Linux ਉੱਤੇ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨੂੰ VPN ਨਾਲ ਜੋੜਨਾ ਮੁੱਖ ਤੌਰ ਉੱਤੇ ਰੂਟਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਿਰਫ਼ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਮਾਰਗ ਚੁਣਨ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਟਨਲ ਕੋਲ ਡਿਫਾਲਟ ਮਾਰਗ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ OUTPUT ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਦਾ UID ਮਿਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਨਿਯਮ ਉਹੀ ਟ੍ਰੈਫਿਕ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਉਹੀ ਨਿਯਮ ਪ੍ਰੋਗਰਾਮ ਦੇ DNS ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਰਿਜ਼ਾਲਵਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੀ ਨਹੀਂ ਵੇਖਦਾ। ਕ੍ਰਮ ਸਹੀ ਕਰੋ, ਅਤੇ ਬਿਨਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰਾਂ ਵਾਲਾ ਇੱਕ ਖਾਤਾ ਭਰੋਸੇਯੋਗ ਸਪਲਿਟ-ਟਨਲ ਚੋਣਕਰਤਾ ਬਣ ਜਾਂਦਾ ਹੈ।

ਫ਼ੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਖਾਤੇ ਨੂੰ ਮਾਰਗ ਦਿਓ

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

ਖਾਤੇ ਨੂੰ ਪਹਿਲਾਂ ਉਸਦੀ ਆਪਣੀ ਟੇਬਲ ਰਾਹੀਂ ਲੰਘਾਓ, ਫਿਰ ਫਾਇਰਵਾਲ ਨੂੰ ਨਤੀਜਾ ਪੁਸ਼ਟੀ ਕਰਨ ਦਿਓ। ਇਹ iproute2 ਨੂੰ uidrange ਸਮਝਣ ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ip rule help ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਦੱਸਦਾ ਹੈ। ਟੇਬਲ 100 ਟਨਲ ਰਾਹੀਂ ਡਿਫਾਲਟ ਮਾਰਗ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਨਿਯਮ ਸਿਰਫ਼ UID 1000 ਨੂੰ ਉਸ ਟੇਬਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਬਾਕੀ ਸਭ ਮੁੱਖ ਟੇਬਲ ਉੱਤੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਭੌਤਿਕ ਲਿੰਕ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ।

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

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

loopback ਛੋਟ ਟਨਲ ਨੂੰ ਕਿਉਂ ਮਾਰਦੀ ਹੈ

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

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

loopback ਅਜੇ ਵੀ DROP ਉੱਤੇ ਆਪਣੇ ACCEPT ਦਾ ਹੱਕਦਾਰ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰੋਗਰਾਮ ਦਾ ਪਹਿਲਾ DNS ਪੈਕੇਟ lo ਰਾਹੀਂ ਸਥਾਨਕ ਸਟਬ ਵੱਲ ਜਾਂਦਾ ਹੈ। ਦੋਵੇਂ ਨਿਯਮ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਖਾਤਾ ਸਟਬ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਫਿਰ ਟਨਲ ਤੱਕ, ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ।

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 ਵੱਖਰਾ ਨਿਯਮ-ਸਮੂਹ ਹੈ, ਅਤੇ ਸਿਰਫ਼ v4 ਲਈ ਬਣੀ ਜੋੜੀ ip6tables ਨੂੰ ਅਛੂਤਾ ਛੱਡ ਦਿੰਦੀ ਹੈ। AAAA ਰਿਕਾਰਡ ਪਸੰਦ ਕਰਨ ਵਾਲਾ ਪ੍ਰੋਗਰਾਮ ਫਿਰ DROP ਤੱਕ ਕਦੇ ਨਾ ਪਹੁੰਚ ਕੇ ਭੌਤਿਕ ਲਿੰਕ ਰਾਹੀਂ ਬਾਹਰ ਚਲਾ ਜਾਵੇਗਾ। ਦੋਵੇਂ ਨਿਯਮ ip6tables ਵਿੱਚ ਦਰਸਾਓ, ਜਾਂ ਜਦੋਂ ਟਨਲ ਕੋਈ v6 ਪਤਾ ਨਾ ਲੈ ਜਾਵੇ ਤਾਂ ਹੋਸਟ ਉੱਤੇ IPv6 ਬੰਦ ਕਰੋ। ਹੱਥ ਨਾਲ ਜੋੜੇ ਨਿਯਮ ਵੀ ਰੀਬੂਟ ਉੱਤੇ ਮਿਟ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ netfilter-persistent save ਨਾਲ ਸੰਭਾਲੋ ਜਾਂ ਉਹੀ ਤਰਕ ਬੂਟ ਯੂਨਿਟ ਵੱਲੋਂ ਲੋਡ ਹੋਣ ਵਾਲੀ nftables ਟੇਬਲ ਵਜੋਂ ਮੁੜ ਬਣਾਓ।

DNS ਜਵਾਬ ਦੂਜੀ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਆਉਂਦੇ ਹਨ

ਪ੍ਰੋਗਰਾਮ ਦੀ 127.0.0.53 ਵੱਲ ਬੇਨਤੀ loopback ACCEPT ਰਾਹੀਂ ਲੰਘਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ UID ਮਿਲਾਨ ਰੁਕਦਾ ਹੈ। ਸਟਬ ਰਿਜ਼ਾਲਵਰ ਆਪਣੇ ਸੇਵਾ ਖਾਤੇ ਤੋਂ ਉੱਪਰ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ vpnapp ਨਾਲ ਬੱਝਿਆ ਨਿਯਮ ਦੂਜੀ ਬੇਨਤੀ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ। ਜੇ ਰਿਜ਼ਾਲਵਰ ਲਿੰਕ ਲਈ LAN ਸਰਵਰ ਚੁਣਦਾ ਹੈ, ਤਾਂ ਜਵਾਬ ਭੌਤਿਕ NIC ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਪ੍ਰੋਗਰਾਮ ਦੇ ਆਪਣੇ ਪੈਕੇਟ ਟਨਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਦਿਸਣ ਵਾਲਾ ਨਤੀਜਾ ਟੁੱਟੇ ਨਾਵਾਂ ਨਾਲ ਚੱਲਦਾ ਟਨਲ ਹੈ, ਜਾਂ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨਾ ਚੁਣੇ ਸਰਵਰ ਵੱਲੋਂ ਜਵਾਬ ਦਿੱਤੇ ਨਾਮ ਹਨ।

ਨਾਮ-ਹੱਲ ਪ੍ਰੋਗਰਾਮ ਉੱਤੇ ਨਹੀਂ, ਟਨਲ ਦੇ ਲਿੰਕ ਉੱਤੇ ਠੀਕ ਕਰੋ। ਟਨਲ ਪ੍ਰੋਫਾਈਲ ਨੂੰ DNS ਸਰਵਰ ਅਤੇ ਰੂਟਿੰਗ ਡੋਮੇਨ ਦਿਓ, ਫਿਰ resolvectl query ਅਤੇ resolvectl status tun0 ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਜ਼ਾਲਵਰ ਮਹੱਤਵਪੂਰਨ ਨਾਵਾਂ ਲਈ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਨਾਮ-ਸਥਾਨ ਦੇ ਅੰਦਰ ਸਮੱਸਿਆ ਮਿਟ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਥਾਨ ਦਾ ਰਿਜ਼ਾਲਵਰ ਸਿਰਫ਼ ਟਨਲ ਜਾਣਦਾ ਹੈ।

ਖਾਤੇ ਤੋਂ ਹੀ ਨਿਯਮ ਜਾਂਚੋ

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

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

ਕਾਊਂਟਰ ਦਿਖਾਉਂਦੇ ਹਨ ਕਿ ਨਿਯਮ ਕਦੇ ਚੱਲਿਆ ਜਾਂ ਨਹੀਂ। iptables -vnL OUTPUT ਚਲਾਓ, ਹਰ ਨਿਯਮ ਦੇ ਕੋਲ ਪੈਕੇਟ-ਗਿਣਤੀ ਪੜ੍ਹੋ, ਅਤੇ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਤੋਂ ਬਾਅਦ DROP ਦੇ ਕੋਲ ਸਿਫ਼ਰ ਨੂੰ ਮਿਲਾਨ ਦੀ ਗਲਤੀ ਮੰਨੋ।

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

ਸੰਬੰਧਿਤ ਲੇਖ