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

ਇਸ ਰਨਬੁੱਕ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਉਹ ਜਾਂਚ ਕ੍ਰਮ ਹੈ ਜੋ ਮੈਂ ਵਰਤਦਾ ਹਾਂ, ਨਾਲ ਹੀ ਹਰ ਨਿਰੀਖਣ ਦੇਣ ਵਾਲੀ ਕਮਾਂਡ।

ਬਾਈਂਡ ਅਸਲ ਵਿੱਚ ਕੀ ਤੈਅ ਕਰਦਾ ਹੈ

ਬਾਈਂਡ ਸਾਕਟ ਨੂੰ ਸਥਾਨਕ ਪਤਾ ਦਿੰਦਾ ਹੈ। ਫਿਰ ਕਰਨਲ ਉਹੀ ਰੂਟ ਖੋਜ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਉਹ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਂਦਾ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਨੀਤੀ ਨਿਯਮ ਇਹ ਨਾ ਬਦਲੇ ਕਿ ਉਹ ਖੋਜ ਕਿਹੜੀ ਟੇਬਲ ਪੜ੍ਹਦੀ ਹੈ।

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

Linux IP ਸਾਕਟ ਸੰਦਰਭ ਬਾਈਂਡ ਦੇ ਅਰਥਾਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ। ਰੂਟਿੰਗ ਵਾਲਾ ਅੱਧਾ ਹਿੱਸਾ ip-rule ਅਤੇ ip-route ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਵੱਖਰੇ ਮੈਨੂਅਲ ਹਨ।

ਪੱਕਾ ਕਰੋ ਕਿ ਪਤਾ ਇਸ ਨੇਮਸਪੇਸ ਦਾ ਹੈ

ਜਿਸ ਪਤੇ ਨਾਲ ਤੁਸੀਂ ਬੱਝ ਸਕਦੇ ਹੋ, ਉਹ ਉਸ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰਲੇ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਐਪ ਚੱਲਦੀ ਹੈ। ਪੀਅਰ ਪਤਾ, ਗੇਟਵੇ ਪਤਾ, ਜਾਂ ਸਿਰਫ਼ ਕਿਸੇ ਹੋਰ ਨੇਮਸਪੇਸ ਵਿੱਚ ਮੌਜੂਦ ਪਤਾ ਬੱਝ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਕਾਲ EADDRNOTAVAIL ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

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

ਉਸ ਸਰੋਤ ਅਤੇ ਮੰਤਵ ਲਈ ਖੋਜ ਪੜ੍ਹੋ

ਇੱਕ ਕਮਾਂਡ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜੋ ਬਾਈਂਡ ਨੇ ਨਹੀਂ ਦਿੱਤਾ:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

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

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

ਨੀਤੀ ਨਿਯਮ ਤਦ ਹੀ ਲਾਓ ਜੇ ਇਹੀ ਡਿਜ਼ਾਈਨ ਹੈ

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

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

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

ip rule del ਅਤੇ ip route flush table 100 ਨਾਲ ਵਾਪਸ ਲਵੋ। ਇਸ ਤਰੀਕੇ ਨਾਲ ਜੋੜਿਆ ਸਭ ਕੁਝ ਰੀਬੂਟ ਉੱਤੇ ਅਲੋਪ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕੋਈ ਮੈਨੇਜਰ ਇਸਨੂੰ ਨਹੀਂ ਲਿਖਦਾ; ਇਹ ਇੱਕ ਸੁਰੱਖਿਆ ਗੁਣ ਵੀ ਹੈ ਅਤੇ ਇਕੱਲੀ ਕਾਪੀ ਆਪਣੇ ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਵਿੱਚ ਨਾ ਰੱਖਣ ਦਾ ਕਾਰਨ ਵੀ।

ਤਿੰਨ ਨਿਰੀਖਣਾਂ ਨਾਲ ਪਰਖੋ

ਐਪ ਨੇ ਜੋ ਸਰੋਤ ਮੰਗਿਆ, ਖੋਜ ਨੇ ਜੋ ਰੂਟ ਚੁਣਿਆ, ਅਤੇ ਸਰਵਰ ਨੇ ਅਸਲ ਵਿੱਚ ਜੋ ਸਰੋਤ ਦੇਖਿਆ, ਤਿੰਨੇ ਦਰਜ ਕਰੋ।

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

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

ਸੰਬੰਧਿਤ ਲੇਖ