SSH ਰਾਹੀਂ VPN ਕਲਾਇੰਟ ਚਲਾ ਰਹੇ ਹੋ? ਪਹਿਲਾਂ ਆਪਣਾ ਰੂਟ ਪਿੰਨ ਕਰੋ

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

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਦਰਜ ਕਰੋ

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

ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਨਵੇਂ ਲੌਗਇਨ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਨਾ ਕਰੋ। ਨਵਾਂ ਸੈਸ਼ਨ ਪੁਰਾਣੇ ਕੋਲ ਹੁਣ ਨਾ ਰਹੀ ਸਥਿਤੀ ਕਾਰਨ ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

ਪਤਾ ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਪਿੰਨ ਕਰੋ

ਹੱਥ ਨਾਲ ਜੋੜਿਆ ਰੂਟ ਰੀਬੂਟ ਉੱਤੇ ਅਲੋਪ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਟੇਬਲ ਅਪਡੇਟਾਂ ਨਾਲ ਸਪਰਧਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਅਪਵਾਦ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਟੇਬਲ ਪ੍ਰਬੰਧਿਤ ਹੁੰਦੀ ਹੈ। OpenVPN ਵਿੱਚ net_gateway ਕੀਵਰਡ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਗੇਟਵੇ ਵਿੱਚ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ route 203.0.113.9 255.255.255.255 net_gateway ਇਸਦੇ ਬਾਹਰ ਠੀਕ ਇੱਕ ਪਤਾ ਰੱਖਦਾ ਹੈ। WireGuard ਨੂੰ ਵੱਖਰਾ ਢੰਗ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ wg-quick ਰੂਟ ਖੁਦ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ: Table = off ਸੈੱਟ ਕਰੋ ਅਤੇ PostUp ਵਿੱਚ ਅਪਵਾਦ ਜੋੜੋ, ਇਸਨੂੰ ਹਟਾਉਣ ਵਾਲੇ ਮੇਲ ਖਾਂਦੇ PostDown ਸਮੇਤ। ਦੋਵੇਂ ਰੂਪ ਇੱਕੋ ਮਨਸ਼ਾ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਅਪਵਾਦ ਨੂੰ ਸਭ ਲਈ ਟਨਲ ਕਮਜ਼ੋਰ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਪਤੇ ਤੱਕ ਸੀਮਿਤ ਰੱਖਦੇ ਹਨ।

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

ਜਾਂ ਮੁੱਖ ਟੇਬਲ ਨੂੰ ਸਮੀਕਰਨ ਵਿੱਚੋਂ ਕੱਢੋ

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

ਦੋਵੇਂ ਇੱਕ ਹੋਸਟ ਰੂਟ ਤੋਂ ਵੱਧ ਮਸ਼ੀਨਰੀ ਹਨ, ਅਤੇ ਜਦੋਂ ਮਸ਼ੀਨ ਉੱਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਚੀਜ਼ ਨੂੰ ਟਨਲ ਤੋਂ ਬਚਣਾ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਲਾਇਕ ਹਨ।

ਮੰਨ ਲਓ ਕਿ ਪਿੰਨਿੰਗ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ

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

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

ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਕਰੋ ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

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

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