ਪੂਰੀ ਟਨਲ ਨੇ ਤੁਹਾਡਾ SSH ਸੈਸ਼ਨ ਮਾਰ ਦਿੱਤਾ: ਵਾਪਸੀ ਮਾਰਗ ਪਿਨ ਕਰੋ

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

redirect-gateway ਅਸਲ ਵਿੱਚ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ

ਆਪਣੇ def1 ਰੂਪ ਵਿੱਚ redirect-gateway ਡਿਫਾਲਟ ਮਾਰਗ ਮੁੜ ਲਿਖਣ ਦੀ ਬਜਾਏ 0.0.0.0/1 ਅਤੇ 128.0.0.0/1 ਜੋੜਦਾ ਹੈ। ਇਹ ਦੋਵੇਂ ਅੱਧੇ ਪੂਰੀ ਪਤਾ-ਥਾਂ ਨੂੰ ਢਕਦੇ ਹਨ ਅਤੇ ਦੋਵੇਂ 0.0.0.0/0 ਨਾਲੋਂ ਲੰਮੇ ਪ੍ਰੀਫਿਕਸ ਰਹਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਮੇਲ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਵੀ ਮੰਜ਼ਿਲ ਹੁਣ ਟਨਲ ਵਿੱਚ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਉਹ ਵਿਧੀ ਹੈ ਜੋ ਯਾਦ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਹੇਠਾਂ ਦਾ ਹਰ ਸੁਧਾਰ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਮੇਲ ਸਥਾਪਿਤ ਕਰਕੇ ਕੰਮ ਕਰਦਾ ਹੈ।

ਤੁਹਾਡਾ ਪ੍ਰਬੰਧਕੀ ਪਤਾ ਉਹਨਾਂ ਮੰਜ਼ਿਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

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

ip route show table main | head -n 20
ip route get 198.51.100.23

ਆਪਣਾ ਸਰੋਤ ਪਤਾ ਅਤੇ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਰਾਹ ਲੱਭੋ

ਸਰਵਰ 'ਤੇ ਸਥਾਪਿਤ SSH ਕਨੈਕਸ਼ਨ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਉਹ ਪੀਅਰ ਪਤਾ ਨੋਟ ਕਰੋ ਜਿੱਥੋਂ ਇਹ ਆਇਆ। ਉਹੀ ਪਤਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਵਾਪਸੀ ਮਾਰਗ ਨੂੰ ਢਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਹਮੇਸ਼ਾ ਉਹ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ: ਜੰਪ ਹੋਸਟ, NAT ਗੇਟਵੇ ਜਾਂ ਆਪਰੇਟਰ ਦਾ ਅਨੁਵਾਦਕ ਕੋਈ ਹੋਰ ਸਰੋਤ ਰੱਖ ਸਕਦਾ ਹੈ।

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

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

ਅੱਧ-ਡਿਫਾਲਟਾਂ ਨੂੰ ਪਛਾੜਨ ਵਾਲਾ ਹੋਸਟ ਮਾਰਗ ਪਿਨ ਕਰੋ

ਇੱਕ /32 ਮਾਰਗ ਦੋਵੇਂ ਅੱਧ-ਡਿਫਾਲਟਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨਾਲੋਂ ਵੀ ਲੰਮਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਪਤੇ 'ਤੇ ਆਉਣ ਵਾਲੇ ਜਵਾਬ ਟਨਲ ਦੀ ਬਜਾਏ ਇਸਨੂੰ ਲੈਂਦੇ ਹਨ। ਅਗਲਾ ਹੌਪ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਗੇਟਵੇ ਹੈ ਅਤੇ ਜੰਤਰ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਹੈ, ਜੋ ਪੈਕਟ ਨੂੰ ਉਸੇ ਰਾਹ 'ਤੇ ਰੱਖਦਾ ਹੈ ਜੋ ਇਸਨੇ ਟਨਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਸੀ।

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

ਸਾਰਣੀ ਵੇਖਣ ਦੀ ਬਜਾਏ ਲੁਕਅੱਪ ਨਾਲ ਜਾਂਚੋ: ਜਵਾਬ ਵਿੱਚ eth0 ਅਤੇ ਗੇਟਵੇ ਦਾ ਨਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਦੇ ਵੀ tun0 ਨਹੀਂ।

OpenVPN ਪਹਿਲਾਂ ਹੀ VPN ਸਰਵਰ ਦੇ ਆਪਣੇ ਪਤੇ ਵੱਲ ਹੋਸਟ ਮਾਰਗ ਇਸੇ ਕਾਰਨ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਢਾਂਚਾ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਹੈ ਅਤੇ ਪ੍ਰਬੰਧਕੀ ਪਤਾ ਕੇਵਲ ਇੱਕ ਹੋਰ ਅਪਵਾਦ ਹੈ। ਇਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ route-nopull ਵੱਲ ਨਾ ਜਾਓ, ਕਿਉਂਕਿ ਇਹ ਟਨਲ ਨੂੰ ਲੋੜੀਂਦੇ ਧੱਕੇ ਹੋਏ ਮਾਰਗ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਜਿਹਨਾਂ ਵਿੱਚ ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ ਅਤੇ DNS ਚੋਣਾਂ ਵੀ ਸ਼ਾਮਲ ਹਨ।

ਇਸਨੂੰ ਦੁਬਾਰਾ ਜੁੜਨ 'ਤੇ ਟਿਕਣ ਦਿਓ

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

ਇੱਕ route-up ਸਕ੍ਰਿਪਟ ਅਤੇ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਦਾ pre-up ਹੁੱਕ ਦੋਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਜਾਂਚ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਉਹੀ ਲੁਕਅੱਪ ਹੈ।

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

ਜਦੋਂ ਪਿਨ ਕੀਤਾ ਮਾਰਗ ਵੀ ਕਾਫ਼ੀ ਨਾ ਹੋਵੇ

ਰਿਵਰਸ-ਪਾਥ ਫਿਲਟਰਿੰਗ ਉਹ ਪੈਕਟ ਸੁੱਟ ਸਕਦੀ ਹੈ ਜੋ ਇੱਕ ਇੰਟਰਫੇਸ 'ਤੇ ਆ ਕੇ ਦੂਜੇ ਰਾਹੀਂ ਨਿਕਲਦਾ ਹੈ, ਅਤੇ ਪਿਨ ਕੀਤਾ ਮਾਰਗ ਠੀਕ ਇਹੀ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਕੁਝ ਵੀ ਵਿਸ਼ਵ-ਪੱਧਰੀ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ rp_filter ਦਾ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਜਾਂਚੋ, ਅਤੇ ਜਾਂਚ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ ਅਸਮਾਨਤਾ ਸੁਧਾਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਸੈਟਿੰਗ ਪ੍ਰਤੀ-ਇੰਟਰਫੇਸ ਹੈ, ਅਤੇ loose ਮੋਡ ਅਕਸਰ ਪੈਕਟ ਸੁੱਟਣ ਦੀ ਬਜਾਏ ਸਿਰਫ ਅਸਮਾਨਤਾ ਦਰਜ ਕਰਦਾ ਹੈ। ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਫਿਲਟਰ ਤੁਹਾਡੀ ਗਲਤੀ ਹੈ, ਦੋਵੇਂ ਪੜ੍ਹੋ।

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

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