ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ SSH ਸੁਣ ਨਹੀਂ ਰਿਹਾ: VPN ਪਤਾ ਦੇਰ ਨਾਲ ਆਉਂਦਾ ਹੈ

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

ਬਾਈਂਡ ਗਲਤੀ ਅਸਲ ਵਿੱਚ ਕੀ ਕਹਿੰਦੀ ਹੈ

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

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

ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਪੋਰਟ ਦੀ ਮਾਲਕ ਹੈ

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

ਤਿਆਰੀ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ, ਨੀਂਦ ਨਹੀਂ

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

ip -4 addr show dev tun0
systemctl edit ssh.service

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

ਸਾਫ਼ ਬੂਟ ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ

ਸਭ ਕੁਝ ਆਨਲਾਈਨ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੱਥੋਂ ਰੀਸਟਾਰਟ ਬੂਟ ਕ੍ਰਮ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਟਨਲ ਨੂੰ ਆਪਣੇ ਆਪ ਚੜ੍ਹਨ ਲਈ ਸੰਰਚਿਤ ਕਰਕੇ ਮਸ਼ੀਨ ਨੂੰ ਰੀਬੂਟ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਸਰੋਤਾ ਬਿਨਾਂ ਦਖਲ ਦੇ ਦਿਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

ਸਫਲਤਾ ਦਾ ਮਾਪਦੰਡ ਉਹ ਸਰੋਤਾ ਹੈ ਜੋ ਆਪਣੀ ਦਸਤਾਵੇਜ਼ੀ ਨਿਰਭਰਤਾ ਅਧੀਨ ਦਿਖਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਜਿਸ ਨੂੰ ਕਿਸੇ ਨੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ ਯਾਦ ਰੱਖਿਆ।