ਤੁਹਾਡੀ ਜਨਤਕ Linux ਸੇਵਾ VPN ਰਾਹੀਂ ਕਿਉਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ

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

ਗ਼ਲਤ ਧਾਰਨਾ: ਜਵਾਬ ਉਸੇ ਇੰਟਰਫ਼ੇਸ ਦੀ ਪੈਰਵੀ ਕਰਦੇ ਹਨ ਜਿਸ ’ਤੇ ਆਏ

ਇਹ ਤਰਕਸੰਗਤ ਲੱਗਦਾ ਹੈ ਕਿ eth0 ’ਤੇ ਆਉਣ ਵਾਲਾ ਪੈਕਟ eth0 ਰਾਹੀਂ ਹੀ ਜਾਵੇ। ਬਿਨਾਂ ਹਾਲਤ ਵਾਲੇ ਪੈਕਟ ਫ਼ਿਲਟਰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਆਉਣ ਵਾਲੇ ਪਾਸੇ tcpdump ਬੇਨਤੀ ਠੀਕ ਉੱਥੇ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਉਮੀਦ ਹੁੰਦੀ ਹੈ। ਹੋਸਟ ਵੱਲੋਂ ਆਪ ਬਣਾਏ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਰੂਟਿੰਗ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦੀ।

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

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

ਕਰਨਲ ਅਸਲ ਵਿੱਚ ਕੀ ਰੂਟ ਕਰਦਾ ਹੈ: ਸਰੋਤ ਪਤਾ

ਤੁਹਾਨੂੰ ਜੋ ਹੈਂਡਲ ਚਾਹੀਦਾ ਹੈ ਉਹ ਸਥਾਨਕ ਪਤਾ ਹੈ ਜੋ ਸੇਵਾ ਜਵਾਬਾਂ ਲਈ ਵਰਤਦੀ ਹੈ। eth0 ਪਤਾ ਉਦਾਹਰਨ ਵਜੋਂ 192.0.2.10/24 ਅਤੇ ਗੇਟਵੇ 192.0.2.1 ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਉਹ ਪਤਾ ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ। ਕਲਾਊਡ VM ’ਤੇ ਜਨਤਕ ਪਤਾ ਉੱਪਰ ਅਨੁਵਾਦਿਤ ਹੋ ਕੇ ਮਹਿਮਾਨ ਵਿੱਚ ਨਾ ਹੋਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਉਹੀ ਪਤਾ ਵਰਤੋ ਜੋ ਹੋਸਟ ਕੋਲ ਅਸਲ ਵਿੱਚ ਹੈ।

ਸਾਰਣੀ ਨੰਬਰ ਜਾਂ ਨਿਯਮ ਤਰਜੀਹ ਰਾਖਵੀਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਹਾਲਤ ਵੇਖੋ। ਮੌਜੂਦਾ ਨੀਤੀ ਨਿਯਮ ਨਵੇਂ ਨੂੰ ਛਾਇਆ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਸੇ ਨੰਬਰ ਵਾਲੀ ਪੁਰਾਣੀ ਸਾਰਣੀ ਪਹਿਲਾਂ ਹੀ ਅਸੰਬੰਧਿਤ ਮਾਰਗ ਰੱਖ ਸਕਦੀ ਹੈ:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

ਅੱਧਾ ਡਿਫ਼ਾਲਟ ਨਹੀਂ, ਪੂਰੀ ਵਾਪਸੀ ਸਾਰਣੀ ਬਣਾਓ

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

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

ਕ੍ਰਮ ਵੀ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ। ਘੱਟ ਤਰਜੀਹ ਨੰਬਰ ਵਾਲਾ ਵਿਸ਼ਾਲ ਨਿਯਮ ਪਹਿਲਾਂ ਮੁੱਲਾਂਕਣ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਮੁੱਖ ਸਾਰਣੀ ਵਿੱਚ ਵਾਪਸ ਭੇਜ ਸਕਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਨਿਯਮ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੋੜਨ ਤੋਂ ਬਾਅਦ ip rule show ਨਾਲ ਤਰਜੀਹਾਂ ਜਾਂਚੋ, ਸਿਰਫ਼ ਬੂਟ ’ਤੇ ਨਹੀਂ।

ਸਰੋਤ-ਯੋਗ ਖੋਜ ਨਾਲ ਤਸਦੀਕ ਕਰੋ

ਕਰਨਲ ਨੂੰ ਸੇਵਾ ਦੇ ਪਤੇ ਤੋਂ ਪਰਖ ਮੰਜ਼ਿਲ ਵੱਲ ਰੂਟ ਕਰਨ ਲਈ ਕਹੋ। ਜਵਾਬ ਵਿੱਚ ਟਨਲ ਨਹੀਂ, eth0 ਅਤੇ WAN ਗੇਟਵੇ ਦਾ ਨਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

ਅੰਤਿਮ ਮਾਰਗ ਅਤੇ ਨਿਯਮ ਉਸ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਹੇਠ ਰੱਖੋ ਜੋ ਇੰਟਰਫ਼ੇਸ ਦਾ ਮਾਲਕ ਹੈ। ਪਤਾ ਬਦਲਾਅ, DHCP ਨਵੀਨੀਕਰਨ ਅਤੇ VPN ਮੁੜ-ਕਨੈਕਸ਼ਨ ਸਾਰੇ ਕਰਨਲ ਹਾਲਤ ਮੁੜ ਲਿਖਦੇ ਹਨ, ਅਤੇ ਹੱਥ ਨਾਲ ਜੋੜਿਆ ਨਿਯਮ ਅਗਲੀ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਪੁਰਾਣੇ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਇਹ ਅਪਵਾਦ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ

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

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

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

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