VPN ਚਾਲੂ ਰਹਿੰਦਿਆਂ ਦੂਜੇ ਨਿੱਜੀ ਰਸਤੇ ਉੱਤੇ SSH

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

ਨਵਾਂ ਰਸਤਾ ਨਵਾਂ ਸਰੋਤਾ ਕਿਉਂ ਨਹੀਂ ਬਣਾਉਂਦਾ

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

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

ਪਤੇ ਅਤੇ ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ

ਕੁਝ ਵੀ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਹੋਸਟ ਉੱਤੇ ਮੌਜੂਦ ਪਤੇ ਅਤੇ ਹੁਣ ਮੌਜੂਦ ਸਾਕਟ ਦਰਜ ਕਰੋ।

ip -br addr
ss -ltnp | grep ':22'

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

ਬਾਈਂਡਿੰਗ ਜੋੜੋ ਅਤੇ ਪੁਰਾਣੀ ਰੱਖੋ

OpenSSH ਕਈ ListenAddress ਐਂਟਰੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਿੱਜੀ ਰਸਤਾ ਜੋੜਦਿਆਂ VPN ਰਸਤਾ ਬਣਿਆ ਰਹਿ ਸਕਦਾ ਹੈ। ਫ਼ਾਈਲ ਨੂੰ ਮੁੜ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ।

sshd -t
systemctl reload sshd

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

ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਵੇਂ ਸੈਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ

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

ssh -v [email protected]

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

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