VPN ਤੋਂ ਬਾਹਰ ਸਿਰਫ਼ ਇੱਕ ਸਥਾਨਕ ਵੈੱਬ ਸੇਵਾ ਨੂੰ ਪੋਰਟ ਅਨੁਸਾਰ ਰੂਟ ਕਰੋ

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

ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੋਂ ਸ਼ਰਤਾਂ ਜਾਂਚੋ

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

ਦੂਜੀ ਸ਼ਰਤ ਨੀਤੀ ਹੈ, ਯੰਤਰ-ਵਿਦਿਆ ਨਹੀਂ। ਸੁਰੰਗ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਵਾਲਾ ਹਰ ਰੂਟ ਸੁਰੰਗ ਦੇ ਮਕਸਦ ਦਾ ਅਪਵਾਦ ਹੈ, ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਹੋਸਟ ਉੱਤੇ ਉਹ ਫ਼ੈਸਲਾ ਨੀਤੀ ਦੇ ਮਾਲਕ ਦਾ ਹੁੰਦਾ ਹੈ, ਟਾਈਮਆਊਟ ਡੀਬੱਗ ਕਰਨ ਵਾਲੇ ਵਿਅਕਤੀ ਦਾ ਨਹੀਂ।

ਜਵਾਬ ਨੂੰ ਮਿਲਾਓ, ਕਲਾਇੰਟ ਦੇ ਮੰਜ਼ਿਲ ਪੋਰਟ ਨੂੰ ਨਹੀਂ

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

ਜਵਾਬ ਦੀ ਦਿਸ਼ਾ ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ। ਸਰੋਤ ਪੋਰਟ ਮਿਲਾਓ, ਨਿਯਮ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਬਣੇ ਪੈਕਟਾਂ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਅਤੇ ਨਿਯਮ ਬ੍ਰਾਊਜ਼ਰ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਸੇਵਾ ਦੇ ਆਪਣੇ ਜਵਾਬਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ।

ਨਿਯਮ ਦੇ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰੀ ਰਿਟਰਨ ਟੇਬਲ ਬਣਾਓ

ਖਾਲੀ ਟੇਬਲ ਦਾ ਮਤਲਬ ਹੈ ਕੋਈ ਰੂਟ ਨਹੀਂ, ਜੋ ਟੁੱਟੀ ਨੀਤੀ ਨਾਲੋਂ ਟੁੱਟੀ ਸੇਵਾ ਵਰਗਾ ਦਿਸਦਾ ਹੈ। ਪਹਿਲਾਂ ਇਸ ਨੂੰ ਭਰੋ, ਅਜਿਹੇ ਟੇਬਲ ਨੰਬਰ ਅਤੇ ਤਰਜੀਹ ਨਾਲ ਜਿਸ ਉੱਤੇ ਹੋਸਟ ਉੱਤੇ ਹੋਰ ਕੁਝ ਦਾਅਵਾ ਨਾ ਕਰੇ:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

ਸੰਖਿਆਵਾਂ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ ਜੀਵੰਤ ਹੋਸਟ ਤੋਂ ਪੜ੍ਹੋ। ip -4 rule show ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਤਰਜੀਹਾਂ ਲਈਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਤਰਜੀਹ ਉੱਤੇ ਨਿਯਮ ਜੋੜਨ ਨਾਲ ਆਪਣੇ ਆਪ ਸਹੀ ਦਿਸਦੇ ਦੋ ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਚੁੱਪਚਾਪ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਇੱਥੇ ਅਸਲੀ ਕੰਮ ਦੋ ਚੋਣਕਾਰ ਕਰਦੇ ਹਨ। iif lo ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਕਰਨਲ ਹੋਸਟ ਵੱਲੋਂ ਖੁਦ ਬਣਾਏ ਪੈਕਟਾਂ ਦੀ ਸੂਚਨਾ ਕਿਵੇਂ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ ਬਾਹਰੋਂ ਆਉਣ ਵਾਲੇ ਫਾਰਵਰਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਗਲਤੀ ਨਾਲ ਨਹੀਂ ਫੜ ਸਕਦਾ। ipproto tcp sport 443 ਇਸ ਨੂੰ ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਇੱਕ ਪੋਰਟ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਜੋ ਲੋੜ ਅਨੁਸਾਰ ਜਿੰਨਾ ਤੰਗ ਹੋ ਸਕਦਾ ਹੈ ਓਨਾ ਤੰਗ ਹੈ। ਪ੍ਰੋਟੋਕਾਲ ਚੋਣਕਾਰ ਹਟਾ ਦਿਓ ਤਾਂ ਨਿਯਮ UDP 443 ਵੀ ਫੜ ਲਵੇਗਾ, ਜੋ ਵੱਖਰੇ ਵਿਵਹਾਰ ਵਾਲੀ ਵੱਖਰੀ ਸੇਵਾ ਹੈ।

ਨਿੱਜੀ ਜਵਾਬ ਸੁਰੰਗ ਦੇ ਅੰਦਰ ਰੱਖੋ

ਜੇ ਉਹੀ ਸੁਣਨ ਵਾਲਾ ਨਿੱਜੀ ਪਾਸੇ ਦੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਟੇਬਲ 100 ਵਿੱਚ ਸਭ ਕੁਝ ਫੜਨ ਵਾਲਾ WAN ਡਿਫ਼ਾਲਟ ਉਹ ਜਵਾਬ ਅਪਲਿੰਕ ਰਾਹੀਂ ਵਾਪਸ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ। ਜੋ ਨਿੱਜੀ ਪ੍ਰੀਫ਼ਿਕਸ WAN ਡਿਫ਼ਾਲਟ ਦੀ ਪਾਲਣਾ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ ਉਹ ਜੋੜੋ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਅਗਲੇ ਨੀਤੀ-ਨਿਯਮ ਉੱਤੇ ਡਿੱਗਣ ਦਿਓ:

ip -4 route add table 100 throw 10.90.0.0/24

throw ਰੂਟ ਇਸ ਟੇਬਲ ਵਿੱਚ ਖੋਜ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪੈਕਟ ਨੂੰ ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਅਗਲੀ VPN ਨੀਤੀ ਨੂੰ ਆਪਣਾ ਮੌਕਾ ਮਿਲੇ। ਇਹ ਖੁਦ ਸੁਰੰਗ ਵਿੱਚ ਕੁਝ ਵੀ ਰੂਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਜੇ ਬਾਅਦ ਦੇ ਕਿਸੇ ਨਿਯਮ ਕੋਲ ਮੇਲ ਖਾਂਦਾ ਰੂਟ ਨਹੀਂ ਹੈ ਤਾਂ ਪੈਕਟ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ; throw ਨੂੰ ਹੱਲ ਮੰਨਣ ਦੀ ਬਜਾਏ ਅਗਲੀ ਨੀਤੀ ਜਾਂਚੋ।

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

TCP, ਫਿਰ QUIC, ਫਿਰ ਰੀਬੂਟ ਜਾਂਚੋ

ਅਧਿਕਾਰਤ ਬਾਹਰੀ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕ ਅਤੇ ਨਿੱਜੀ ਪਾਸੇ ਤੋਂ ਇੱਕ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ, ਫਿਰ ਅਸਲ ਪਤਿਆਂ ਅਤੇ ਪੋਰਟਾਂ ਨਾਲ ਜਵਾਬ-ਖੋਜ ਜਾਂਚੋ। ਬਾਹਰੀ ਜਵਾਬ ਟੇਬਲ 100 ਲਵੇ ਅਤੇ ਨਿੱਜੀ ਜਵਾਬ ਨਾ ਲਵੇ, ਤਾਂ ਨੀਤੀ ਉਹੀ ਕਰ ਰਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਮੰਗਿਆ ਸੀ।

HTTP/3 UDP ਉੱਤੇ ਪਰੋਸਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ TCP ਨਿਯਮ ਨਾਲ ਨਹੀਂ ਮਿਲੇਗਾ, ਇਸ ਲਈ QUIC ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਆਪਣਾ ਚੋਣਕਾਰ ਚਾਹੀਦਾ ਹੈ, ਵਰਨਾ HTTPS ਚੱਲਦੇ ਹੋਣ ਦੌਰਾਨ ਵੀ ਇਹ ਸੁਰੰਗ ਵਰਤਦਾ ਰਹੇਗਾ। ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਨਿਯਮਾਂ ਉੱਤੇ ਟਿਕਦੇ ਹੋ ਉਹਨਾਂ ਨੂੰ ਇੰਟਰਫ਼ੇਸ ਦੇ ਮਾਲਕ ਹਿੱਸੇ ਕੋਲ ਸੰਭਾਲੋ, ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਜਾਂ DHCP ਨਵੀਨੀਕਰਨ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਮੁਕਾਬਲੇ ਵਾਲਾ ਮੈਨੇਜਰ ਰਨਟਾਈਮ ਰੂਟ ਹਟਾ ਦੇਵੇ, ਤਾਂ ਉਹ ਮੂਲ ਵਿੱਚ ਠੀਕ ਕਰਨ ਵਾਲੀ ਮਾਲਕੀ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਉੱਤੇ ਹੋਰ ਵਿਸਤ੍ਰਿਤ NAT ਨਿਯਮ ਜੋੜਨ ਦਾ ਕਾਰਨ ਨਹੀਂ।