VPN ਉੱਤੇ SSH ਹਰ ਮਿੰਟ ਟੁੱਟਦਾ ਹੈ? ਕਾਰਨ keepalive ਨਹੀਂ

SSH ਜੁੜਦਾ ਹੈ, ਲਗਭਗ ਇੱਕ ਮਿੰਟ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ ਹਰ ਵਾਰ ਲਗਭਗ ਉਸੇ ਅੰਤਰਾਲ 'ਤੇ ਜੰਮ ਜਾਂਦਾ ਹੈ। ਆਮ ਵਿਆਖਿਆ ਨਿਸ਼ਕਿਰਿਆ ਟਾਈਮਆਊਟ ਹੈ, ਇਸ ਲਈ ਲੋਕ MTU ਘਟਾਉਂਦੇ ਹਨ ਅਤੇ ਕਲਾਇੰਟ keepalives ਸੈੱਟ ਕਰਦੇ ਹਨ। ਜਿਸ WireGuard ਲਿੰਕ 'ਤੇ ਮੈਂ ਕੰਮ ਕੀਤਾ, ਉਹ ਇਹ ਸਭ ਪਹਿਲਾਂ ਹੀ ਝੱਲ ਚੁੱਕਾ ਸੀ: ਛੋਟਾ ਟਨਲ MTU, client-alive ਸੈਟਿੰਗਾਂ, ਕਨਫਿਗਰ ਕੀਤਾ ਟਨਲ keepalive। ਟੁੱਟਣਾ ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਜਾਰੀ ਰਿਹਾ। ਕਾਰਨ ਅਸਮਮਿਤ LAN ਰੂਟ ਨਿਕਲਿਆ, ਅਤੇ ਇਹ ਪੈਟਰਨ ਪਛਾਣਨ ਯੋਗ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟਾਈਮਰ-ਆਧਾਰਿਤ ਹਰ ਉਪਾਅ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ।

keepalive ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਹੋਸਟ ਅਜੇ ਵੀ ਭੇਜਣ ਲਈ ਤਿਆਰ ਹੈ। ਇਹ ਸਥਿਤੀ ਰੱਖਣ ਵਾਲੇ ਡਿਵਾਈਸ ਨੂੰ ਉਹ ਜਵਾਬ ਨਹੀਂ ਦਿਖਾ ਸਕਦਾ ਜੋ ਕਦੇ ਇਸ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ।

ਮਿੱਥ: keepalives ਚੁੱਪ ਟੁੱਟਣ ਨੂੰ ਠੀਕ ਕਰਦੇ ਹਨ

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

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

ਸੰਕੇਤ ਨਿਯਮਿਤਤਾ ਹੈ, ਨਾਲ ਹੀ ਉਹ ਸੈਸ਼ਨ ਜੋ ਉਸ ਅੰਤਰਾਲ ਦੇ ਅੰਦਰ ਵਰਤੋਂ ਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਨਿਸ਼ਕਿਰਿਆ ਟਾਈਮਆਊਟ ਉਦੋਂ ਵੱਜਦੇ ਹਨ ਜਦੋਂ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਉਦੋਂ ਵੱਜਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਟਾਈਪ ਕਰ ਰਹੇ ਹੋ।

ਵਾਧੂ ਗੇਟਵੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

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

ਹੇਠਾਂ ਦਿੱਤੇ ਪਤੇ ਉਸ ਵਿਵਸਥਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਕਲਾਇੰਟ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ, ਇਸ ਲਈ ਇਸਦੀ ਭਾਲ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਫਾਈਲ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ।

ਇੱਕ ਜਾਣਬੁੱਝ ਕੇ ਚੁਣਿਆ ਮਾਰਗ ਚੁਣੋ

ਉਪਰੋਕਤ ਵਿਵਸਥਾ ਲਈ, ਦੂਰ ਦੇ ਸਬਨੈੱਟ ਨੂੰ ਸਿੱਧਾ VPN ਗੇਟਵੇ 'ਤੇ ਰੂਟ ਕਰਨਾ ਅੱਧਾ ਕਨੈਕਸ਼ਨ ਹਟਾ ਦਿੰਦਾ ਹੈ:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

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

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

ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਪਰਖੋ

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

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

ਅਸਮਮਿਤੀ ਕਦੋਂ ਠੀਕ ਹੈ

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

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