SSH SOCKS ਪ੍ਰੌਕਸੀ ਉਦੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਇਸ ਦਾ SSH ਕਨੈਕਸ਼ਨ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸੁਪਰਵਾਈਜ਼ਰ ਉਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਉਹ ਹਰ ਵੈੱਬਸਾਈਟ ਬੇਨਤੀ ਨੂੰ ਜਾਰੀ ਨਹੀਂ ਰੱਖ ਸਕਦਾ ਜੋ ਪੁਰਾਣੀ ਸਟ੍ਰੀਮ ਵਰਤ ਰਹੀ ਸੀ।

ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰ ਰਹੇ SSH ਸੈਟਅਪ ਲਈ, autossh ਇੱਕ ਗਤੀਸ਼ੀਲ ਫਾਰਵਰਡਿੰਗ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ OpenSSH ਬੇਜਵਾਬ ਸਰਵਰ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ:

autossh -M 0 -N -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 127.0.0.1:1080 [email protected]

-M 0 autossh ਦੀ ਵੱਖਰੀ ਨਿਗਰਾਨੀ-ਪੋਰਟ ਵਿਵਸਥਾ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ SSH ਬਾਹਰ ਜਾਵੇ ਤਾਂ ਜੋ ਸੁਪਰਵਾਈਜ਼ਰ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਕੇ। server-alive ਵਿਕਲਪ SSH ਪੱਧਰ 'ਤੇ ਜੀਵਨਸ਼ੀਲਤਾ ਜਾਂਚ ਦਿੰਦੇ ਹਨ; ਉਹ ਤੁਹਾਡੇ ਵੱਲੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਹਰ ਮੰਜ਼ਿਲ ਤੋਂ ਪੰਨਾ ਨਹੀਂ ਮੰਗਦੇ।

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ