ਇੱਕ ਪੋਰਟ ਲਈ VPN ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਲਈ ਪਾਲਿਸੀ ਰੂਟਿੰਗ ਚਾਹੀਦੀ ਹੈ

ਬੇਨਤੀ ਹਮੇਸ਼ਾ ਇੱਕੋ ਵਾਕ ਦਾ ਇੱਕ ਰੂਪ ਹੁੰਦੀ ਹੈ: ਬ੍ਰਾਊਜ਼ਿੰਗ ਲਈ VPN ਰੱਖੋ, ਪਰ SSH ਜਾਂ ਬੈਕਅੱਪ ਜੌਬ ਨੂੰ ਆਮ ਕਨੈਕਸ਼ਨ ਵਰਤਣ ਦਿਓ। ਇਸ ਬਾਰੇ ਘੁੰਮ ਰਹੀ ਸਲਾਹ, ਕਿ ਪੋਰਟ ਨੂੰ iptables NAT ਨਿਯਮਾਂ ਨਾਲ ਫਾਰਵਰਡ ਕਰੋ, ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਦੀ। NAT ਨਿਯਮ ਇੱਕ ਫਲੋ ਦੇ ਅੰਦਰ ਪਤੇ ਅਤੇ ਪੋਰਟਾਂ ਬਦਲਦਾ ਹੈ; ਇਹ ਕਦੇ ਨਹੀਂ ਚੁਣਦਾ ਕਿ ਪੈਕਟ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਵੇ। ਇਹ ਫੈਸਲਾ ਰੂਟਿੰਗ ਲੁੱਕਅੱਪ ਦਾ ਹੈ, ਅਤੇ ਰੂਟਿੰਗ ਲੁੱਕਅੱਪ ਨੂੰ ਪੋਰਟ ਦੇਖਣ ਲਈ ਮਦਦ ਚਾਹੀਦੀ ਹੈ।

ਸਾਦਾ ਰੂਟ ਪੋਰਟ ਨਾਲ ਕਿਉਂ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦਾ

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

ਮੌਜੂਦਾ iproute2 ਅਤੇ ਕਰਨਲ ਨਿਯਮ ਚੋਣਕਾਰ ਨੂੰ ਚੌੜਾ ਕਰਦੇ ਹਨ: ipproto, sport ਅਤੇ dport ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ip rule add ipproto tcp dport 22 table 100 ਇਰਾਦੇ ਨੂੰ ਇੱਕ ਲਾਈਨ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ip rule add help ਨੂੰ ਅਸਲ ਹੋਸਟ ਉੱਤੇ ਚਲਾਓ ਤਾਂ ਜੋ ਪਤਾ ਲੱਗੇ ਕਿ ਤੁਹਾਡਾ ਬਿਲਡ dport ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕਮਾਂਡ ਵਿੱਚ ਹੀ ਮੁਕੰਮਲ ਹੋ; ਜੇ ਨਹੀਂ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤਾ ਮਾਰਕ ਰਾਹ ਬਰਾਬਰ ਹੈ।

ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਨਿਯਮ ਸਿਰਫ਼ ਇੱਕ ਸੰਕੇਤ ਹੈ। ਟੇਬਲ 100 ਨੂੰ ਅਜੇ ਵੀ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।

ਤਿੰਨ ਹਿੱਸੇ, ਜਾਂ ਇੱਕ

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

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

ਤਿੰਨੇ ਹਿੱਸੇ ਕ੍ਰਮ ਵਿੱਚ

ਪਹਿਲਾਂ, ਜਿਨ੍ਹਾਂ ਫਲੋਜ਼ ਨੂੰ ਮੋੜਨਾ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ ਮਾਰਕ ਕਰੋ, ਅਜਿਹੀ ਚੇਨ ਵਿੱਚ ਜੋ ਰੂਟ ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਮਾਰਕ ਮੌਜੂਦ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਜਲਦੀ ਚੱਲਦੀ ਹੈ:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

ਦੂਜਾ, ਮਾਰਕ ਕੀਤੇ ਪੈਕਟਾਂ ਨੂੰ ਵੱਖਰੀ ਟੇਬਲ ਵਿੱਚ ਭੇਜੋ:

ip rule add fwmark 0x1/0x1 table 100

ਤੀਜਾ, ਉਸ ਟੇਬਲ ਨੂੰ ਭੌਤਿਕ ਲਿੰਕ ਰਾਹੀਂ ਡਿਫਾਲਟ ਰੂਟ ਦਿਓ। ਪਤੇ ਸਿਰਫ਼ ਉਦਾਹਰਨ ਹਨ; ਆਪਣੇ ਲਗਾਓ:

ip route add default via 192.168.1.1 dev wlan0 table 100

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

ਪਹਿਲੇ ਪੈਕਟ ਤੋਂ ਬਾਅਦ ਇਹ ਚੱਲਦਾ ਕਿਵੇਂ ਰਹਿੰਦਾ ਹੈ

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

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

ਟਨਲ ਦੀ ਆਪਣੀ ਟ੍ਰਾਂਸਪੋਰਟ ਨੂੰ ਮਾਰਕ ਨਾ ਕਰੋ। WireGuard ਜਾਂ UDP OpenVPN ਟਨਲ TCP 22 ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਉੱਪਰਲਾ ਨੁਸਖਾ ਸੁਰੱਖਿਅਤ ਹੈ, ਪਰ ਟਨਲ ਮੰਜ਼ਿਲ ਤੋਂ ਇਲਾਵਾ ਸਭ ਕੁਝ ਵਜੋਂ ਲਿਖੀ ਛੋਟ ਐਨਕ੍ਰਿਪਟਿਡ ਪੈਕਟ ਫੜ ਸਕਦੀ ਹੈ ਅਤੇ ਟਨਲ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਤੋੜ ਸਕਦੀ ਹੈ ਜੋ ਰੂਟਿੰਗ ਲੂਪ ਵਾਂਗ ਲੱਗੇ।

ਮੰਨਣ ਦੀ ਥਾਂ ਇਸਨੂੰ ਜਾਂਚੋ

ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਹੜਾ ਰਾਹ ਲਵੇਗਾ, ਮੰਜ਼ਿਲ ਲਈ ਅਤੇ ਪੋਰਟ ਲਈ, ਫਿਰ ਅਸਲ ਟ੍ਰਾਂਸਫਰ ਚਲਾਓ:

ip route get 203.0.113.10
ip rule show
nft list ruleset

ਜੇ ਮਾਰਕ ਮੌਜੂਦ ਹੈ ਪਰ ਕਾਊਂਟਰ ਕਦੇ ਨਹੀਂ ਵਧਦੇ, ਤਾਂ ਨਿਯਮ ਮੇਲ ਨਹੀਂ ਖਾ ਰਿਹਾ। ਕਾਊਂਟਰ ਉਸ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਉਸ ਪਾਲਿਸੀ ਵਿੱਚ ਫ਼ਰਕ ਦਰਸਾਉਂਦੇ ਹਨ ਜੋ ਕਰਨਲ ਲਾਗੂ ਕਰ ਰਿਹਾ ਹੈ।

ਜਦੋਂ ਇਹ ਗ਼ਲਤ ਸਾਧਨ ਹੈ

ਪੋਰਟ-ਅਧਾਰਿਤ ਛੋਟਾਂ ਕੁਦਰਤੀ ਤੌਰ ਉੱਤੇ ਨਾਜ਼ੁਕ ਹੁੰਦੀਆਂ ਹਨ। ਸੇਵਾਵਾਂ ਪੋਰਟ ਬਦਲਦੀਆਂ ਹਨ, HTTP/3 UDP 443 ਵਜੋਂ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਕਈ ਕਿਸਮਾਂ ਦੇ ਕਈ ਫਲੋ ਖੋਲ੍ਹ ਸਕਦੀ ਹੈ। ਜੇ ਅਸਲ ਲੋੜ ਇਹ ਹੈ ਕਿ ਇਹ ਪ੍ਰੋਗਰਾਮ ਆਮ ਲਿੰਕ ਵਰਤੇ, ਤਾਂ ਰੂਟਿੰਗ ਪਰਤ ਗ਼ਲਤ ਥਾਂ ਹੈ; ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਜਾਂ ਪ੍ਰਤੀ-ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੌਕਸੀ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ।

ਜੇ ਲੋੜ ਇਹ ਹੈ ਕਿ ਇਹ ਸਬਨੈੱਟ ਆਮ ਲਿੰਕ ਵਰਤੇ, ਤਾਂ ਮਾਰਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡੋ ਅਤੇ ਵਧੇਰੇ ਖ਼ਾਸ ਰੂਟ ਜੋੜੋ। ਇਹ ਸੌਖਾ ਹੈ, ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਵਿਅਕਤੀ ਰੂਲਸੈੱਟ ਪੜ੍ਹੇ ਬਿਨਾਂ ਇਸਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ।

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