ਕੀ VPN ਰੂਟ ਕੈਸ਼ ਤੁਹਾਡਾ ਬਦਲਾਅ ਲੁਕਾ ਰਿਹਾ ਹੈ? ਤਿੰਨ ਚੀਜ਼ਾਂ ਜਾਂਚੋ

ਬਦਲਾਅ ਲਾਗੂ ਨਾ ਹੋਣ ’ਤੇ ਰੂਟ ਕੈਸ਼ ਖਾਲੀ ਕਰਨਾ ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਹੈ, ਅਤੇ ਆਧੁਨਿਕ ਲਾਈਨਕਸ ’ਤੇ ਇਹ ਵਿਅਰਥ ਮਿਹਨਤ ਹੈ: ਗਲੋਬਲ IPv4 ਰੂਟ ਕੈਸ਼ ਸਾਲਾਂ ਪਹਿਲਾਂ ਹਟਾਇਆ ਗਿਆ ਸੀ, ਇਸ ਲਈ ip route show cache ਕੁਝ ਨਹੀਂ ਛਾਪਦਾ ਅਤੇ ਖਾਲੀ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਧੋਖਾ ਦੇਣ ਵਾਲੀ ਹਾਲਤ ਇੱਕ ਪਰਤ ਉੱਤੇ ਰਹਿੰਦੀ ਹੈ: ਸਾਕਟ ਵਿੱਚ, NAT ਮੈਪਿੰਗ ਵਿੱਚ, ਰਿਜ਼ੌਲਵਰ ਵਿੱਚ ਜਾਂ ਪੁਰਾਣੀ ਪ੍ਰੋਫਾਈਲ ਮੁੜ ਲਾਗੂ ਕਰਨ ਵਾਲੇ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਵਿੱਚ। ਤਿੰਨ ਸਵਾਲ ਉਹਨਾਂ ਕੇਸਾਂ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ: ਗਲਤ ਰਾਹ ਨਵੇਂ ਪ੍ਰਵਾਹ ਤੋਂ ਆ ਰਿਹਾ ਹੈ ਜਾਂ ਪੁਰਾਣੇ ਕਨੈਕਸ਼ਨ ਤੋਂ, ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਰੂਟ ਕੈਸ਼ ਰੱਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਹਾਲਤ ਰਾਊਟਿੰਗ ਵਿੱਚ ਹੈ ਜਾਂ ਉਸ ਦੇ ਉੱਤੇ। ਇੰਟਰਫੇਸ ਰੀਸੈਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਦੇ ਜਵਾਬ ਦਿਓ।

ਜਾਂਚ ਇੱਕ: ਪੁਰਾਣਾ ਰਾਹ ਨਵੇਂ ਪ੍ਰਵਾਹ ਤੋਂ ਆ ਰਿਹਾ ਹੈ?

ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਉਸ ਰੂਟ ਨੂੰ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਹ ਬਣਿਆ ਸੀ। ਇਸ ਲਈ ਟਨਲ ਉੱਤੇ SSH ਸੈਸ਼ਨ ਰਾਊਟਿੰਗ ਟੇਬਲ ਦੇ ਬਦਲਾਅ ਨੂੰ ਸਹਿ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨਵਾਂ ਸੈਸ਼ਨ ਤੁਰੰਤ ਨਵਾਂ ਰਾਹ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ «ਬਦਲਾਅ ਨੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ» ਦਾ ਅਰਥ ਅਕਸਰ «ਪੁਰਾਣਾ ਸਾਕਟ ਅਜੇ ਵੀ ਇਸ ਨੂੰ ਫੜੀ ਬੈਠਾ ਹੈ» ਹੁੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੀ ਵਿੰਡੋ ਨਾਲ ਨਹੀਂ, ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਟੈਸਟ ਕਰੋ।

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

ਜੇ ਨਵਾਂ ਪ੍ਰਵਾਹ ਸਹੀ ਰਾਹ ਲੈਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣਾ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਰਾਊਟਿੰਗ ਵੇਖਣਾ ਬੰਦ ਕਰੋ। ਰੂਟ ਸਹੀ ਸੀ; ਸੈਸ਼ਨ ਪੁਰਾਣਾ ਸੀ।

ਜਾਂਚ ਦੋ: ਕੀ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ ਰੂਟ ਕੈਸ਼ ਰੱਖਦਾ ਹੈ?

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

ਹੋਰ ਪਲੇਟਫਾਰਮ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਸਲਾਹ ਦੀ ਨਕਲ ਇੱਥੇ ਹੀ ਗਲਤ ਹੁੰਦੀ ਹੈ। Windows ਮੰਜ਼ਿਲ ਕੈਸ਼ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ netsh interface ip delete destinationcache ਨਾਲ ਸਾਫ਼ ਕਰ ਸਕਦੇ ਹੋ। BSD ਅਤੇ macOS route -n get ਰਾਹੀਂ ਪ੍ਰਤੀ-ਮੰਜ਼ਿਲ ਖੋਜਾਂ ਦਿਖਾਉਂਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਕੈਸ਼ ਆਪਣੇ ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ ਖਤਮ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ’ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਕਮਾਂਡ ਲਾਈਨਕਸ ’ਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦੀ, ਇਸ ਲਈ ਉਹੀ ਹੱਲ ਅਜ਼ਮਾਉਣ ਵਾਲੇ ਅੱਧੇ ਲੋਕਾਂ ਨੂੰ ਅਸਫਲ ਦਿਖਦਾ ਹੈ।

NAT ਜਾਂ conntrack ਟੇਬਲ ਰੂਟ ਕੈਸ਼ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਉਹੀ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਵਾਦ ਹੋਇਆ ਪ੍ਰਵਾਹ ਆਪਣਾ ਅਨੁਵਾਦ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਰਾਊਟਿੰਗ ਨੀਤੀ ਅੱਗੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ conntrack -L ਇਸ ਨੂੰ ਬਹੁਤ ਦੇਰ ਤੱਕ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਪੁਰਾਣੀ ਹਾਲਤ ਹੈ, ਪਰ ਰੂਟ ਸਾਫ਼ ਕਰਨਾ ਇਸ ਨੂੰ ਨਹੀਂ ਛੂਹੇਗਾ।

ਜਾਂਚ ਤਿੰਨ: ਹਾਲਤ ਰਾਊਟਿੰਗ ਵਿੱਚ ਹੈ ਜਾਂ ਉਸ ਦੇ ਉੱਤੇ?

ਹੋਰ ਕੁਝ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਖੋਜ ਪੜ੍ਹੋ: ਮੰਜ਼ਿਲ ਲਈ ip route get, ਫਿਰ from ਅਤੇ ਸਰੋਤ ਪਤੇ ਨਾਲ ਉਹੀ ਕਮਾਂਡ, ਫਿਰ ip rule show। ਜੇ ਇਹ ਤਿੰਨ ਤੁਹਾਡੇ ਇਰਾਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਤਾਂ ਰਾਊਟਿੰਗ ਠੀਕ ਕਰਨ ਵਾਲੀ ਪਰਤ ਨਹੀਂ, ਅਤੇ ਪੁਰਾਣਾ ਨਿਰੀਖਣ ਕਿਤੇ ਹੋਰ ਤੋਂ ਆਇਆ ਹੈ।

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

ਤਿੰਨ ਜਵਾਬ ਤੁਹਾਨੂੰ ਕੀ ਸਿੱਟਾ ਕੱਢਣ ਦਿੰਦੇ ਹਨ

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

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

ਜੇ ਸੱਚਮੁੱਚ ਕੁਝ ਸਾਫ਼ ਕਰਨਾ ਹੋਵੇ, ਤਾਂ ਨਿਦਾਨ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਚੀਜ਼ ਸਾਫ਼ ਕਰੋ: ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਾਕਟ, ਇੱਕ conntrack ਐਂਟਰੀ, ਰਿਜ਼ੌਲਵਰ ਕੈਸ਼। ਫਿਰ ਉਹੀ ਨਵੇਂ-ਪ੍ਰਵਾਹ ਟੈਸਟ ਦੁਹਰਾਓ ਅਤੇ ਕੀ ਬਦਲਿਆ ਲਿਖੋ।

ਆਪਣੇ ਨੋਟਸ ਵਿੱਚ ਤਿੰਨੇ ਹਾਲਤਾਂ ਵੱਖ ਰੱਖੋ

ਸੰਭਾਲੀ ਸੰਰਚਨਾ, ਮੌਜੂਦਾ ਖੋਜ ਅਤੇ ਨਿਰੀਖਤ ਪ੍ਰਵਾਹ ਤਿੰਨ ਵੱਖਰੇ ਤੱਥ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ «ਕੈਸ਼» ਵਿੱਚ ਮਿਲਾ ਦੇਣਾ ਹੀ ਨੁਕਸ ਨੂੰ ਮੁੜ ਪੈਦਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ। ਰੂਟ ਦਾ ਮਾਲਕ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਯੂਨਿਟ, ip route get ਦਾ ਆਉਟਪੁੱਟ, ਅਤੇ ਅਸਲੀ ਕਨੈਕਸ਼ਨ ਦਾ ਸਰੋਤ ਤੇ ਮੰਜ਼ਿਲ ਲਿਖੋ।

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