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

ਸੁਰੰਗ ਕੀ ਬਦਲਦੀ ਹੈ ਅਤੇ SSH ਅਜੇ ਵੀ ਕੀ ਤੈਅ ਕਰਦਾ ਹੈ

ਸੁਰੰਗ ਪਹੁੰਚਯੋਗਤਾ ਬਦਲਦੀ ਹੈ: ਕਿਹੜੇ ਪਤੇ ਪਹੁੰਚੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਿੱਥੋਂ। ਇਹ ਉਹ ਨਹੀਂ ਬਦਲਦੀ ਜੋ TCP ਕਨੈਕਸ਼ਨ ਬਣਨ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਸਰਵਰ ਹੋਸਟ ਕੁੰਜੀ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਪਛਾਣ ਮੰਗਦਾ ਹੈ।

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

ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗ ਵੀ ਵੱਖਰੇ ਹਨ, ਅਤੇ ਇਹੀ ਵੱਖਰਾਪਣ ਘਟਨਾ ਵੇਲੇ ਕੰਮ ਆਉਂਦਾ ਹੈ।

ਤਿੰਨ ਸ਼ਰਤਾਂ ਜੋ ਪਹੁੰਚ ਮਾਡਲ ਤੈਅ ਕਰਦੀਆਂ ਹਨ

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

ਤੀਜਾ, ਕੀ ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਸੇਵਾ ਨਿਯੰਤਰਣ ਜਾਂ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਨਿਯੰਤਰਣ ਚਾਹੀਦਾ ਹੈ? VPN ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ; SSH ਖਾਤੇ ਤੱਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ। ਜੇ ਲੋੜ ਇਹ ਹੈ ਕਿ ਇੱਕ ਠੇਕੇਦਾਰ ਇੱਕ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚੇ ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ, ਤਾਂ ਇਹ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸੁਰੰਗ ਇਸਨੂੰ ਬਿਆਨ ਨਹੀਂ ਕਰ ਸਕਦੀ।

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

SSH ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿੱਜੀ ਰਾਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

ਇਹ ਅਸੰਗਤੀ VPN ਰਾਹੀਂ ਸਭ ਤੋਂ ਆਮ ਆਪਣੇ ਆਪ ਪੈਦਾ ਕੀਤੀ SSH ਫੇਲ੍ਹ ਹੈ।

ਫੇਲ੍ਹ ਦਾ ਪੜਾਅ ਪੜ੍ਹੋ, ਸੰਯੁਕਤ ਗਲਤੀ ਨਹੀਂ

ਤਿੰਨ ਪੜਾਅ ਤਿੰਨ ਵੱਖਰੇ ਸੰਦੇਸ਼ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਬਾਰੇ ਹੈ।

StageWhat you seeWhat it points at
Before the connectionTimeout, no routeTunnel, route or gateway permission
Connection refusedImmediate resetNothing listening, or a host firewall rejecting
AuthenticationPermission denied after a promptUser, key or server policy

ਸਹੀ ਗਲਤੀ ਅਤੇ ਸਰਵਰ ਦਾ ਆਪਣਾ ਲੌਗ ਵਰਤੋ, ਨਾ ਕਿ VPN ਅਤੇ SSH ਦੋਨੋਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਇਕੱਠੇ ਰੀਸੈਟ ਕਰੋ। ਦੋਨੋਂ ਰੀਸੈਟ ਕਰਨਾ ਹੀ ਪੰਜ ਮਿੰਟ ਦੀ ਜਾਂਚ ਨੂੰ ਦੋ ਦਿਨ ਦੀ ਪਛਾਣ ਘਟਨਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਵਿਸਤ੍ਰਿਤ ਆਉਟਪੁੱਟ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਪੜਾਅ ਤੱਕ ਪਹੁੰਚੇ:

ssh -vv [email protected]

ਹੋਸਟ ਕੁੰਜੀਆਂ ਅਤੇ ਅਧਿਕਾਰ ਕਾਇਮ ਰੱਖੋ

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

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

ਸੇਵਾ ਪਹੁੰਚ ਨੂੰ ਲੋੜੀਂਦੀਆਂ ਪਛਾਣਾਂ ਤੱਕ ਸੀਮਤ ਕਰੋ ਅਤੇ ਨੈੱਟਵਰਕ ਬਦਲਾਵਾਂ ਲਈ ਇੱਕ ਅਧਿਕ੍ਰਿਤ ਰਿਕਵਰੀ ਰਾਹ ਰੱਖੋ।

ਸੰਬੰਧਿਤ ਲੇਖ