WireGuard ਨਿਸ਼ਕਿਰਿਆ ਤੋਂ ਬਾਅਦ ਫੇਲ ਹੁੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਦਿਸ਼ਾ ਜਾਂਚੋ

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

ਕਿਹੜੀ ਦਿਸ਼ਾ ਫੇਲ ਹੁੰਦੀ ਹੈ?

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

ਨੋਟ ਕਰੋ ਕਿ ਸ਼ਾਂਤ ਸਮਾਂ ਕਿੰਨਾ ਰਿਹਾ ਅਤੇ ਡਿਵਾਈਸ ਸੁੱਤਾ ਜਾਂ ਇਸ ਵਿਚਕਾਰ ਕਿਸੇ ਹੋਰ ਨੈੱਟਵਰਕ ’ਤੇ ਗਿਆ। ਇਹ ਦੋ ਤੱਥ ਕਿਸੇ ਵੀ ਸੈਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਨਿਦਾਨ ਬਦਲ ਦਿੰਦੇ ਹਨ।

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

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

ਨੀਂਦ, ਰੇਡੀਓ ਅਤੇ ਐਪ ਦੀ ਸਥਿਤੀ

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

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

keepalive ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

PersistentKeepalive ਸਾਥੀ ਨੂੰ ਸਮੇਂ-ਸਮੇਂ ’ਤੇ ਪ੍ਰਮਾਣਿਤ ਖਾਲੀ ਪੈਕਟ ਭੇਜਦਾ ਹੈ, ਜੋ ਸਾਥੀਆਂ ਵਿਚਕਾਰ NAT ਮੈਪਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖਣ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਦਾ ਸਿਰਾ ਅਦਿਆਤ ਰੱਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਜਿਵੇਂ WireGuard ਦੀ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਦੱਸਦੀ ਹੈ। ਇਹ ਸੁੱਤੇ ਰੇਡੀਓ, ਗੁਆਚੇ ਰਸਤੇ ਜਾਂ ਕਦੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰਨ ਵਾਲੀ ਐਪ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਅੰਤਰਾਲ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ ਚੁਣੋ, ਅਤੇ ਸਿਰਫ਼ ਸਥਿਤੀ ਡਿਸਪਲੇ ਸ਼ਾਂਤ ਹੋਣ ਕਾਰਨ ਹਰ ਥਾਂ ਹਮਲਾਵਰ ਮੁੱਲ ਚਾਲੂ ਨਾ ਕਰੋ।

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

ਪਹਿਲਾਂ ਫੇਲ ਹੋਣ ਵਾਲਾ ਅੰਤਰਾਲ ਬਿਤਾਓ

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

ਹਰ ਜਾਂਚ ਵਿੱਚ ਇੱਕ ਬਦਲਾਅ ਰੱਖੋ ਅਤੇ ਵਰਤਿਆ ਨਿਸ਼ਕਿਰਿਆ ਸਮਾਂ ਲਿਖੋ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਹਰ ਅਗਲੀ ਤੁਲਨਾ ਖਿਸਕ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਹੜਾ ਬਦਲਾਅ ਮਾਇਨੇ ਰੱਖਦਾ ਸੀ। ਚਾਰ ਤੱਥ ਇਕੱਠੇ ਲਿਖੋ: ਦਿਸ਼ਾ, ਸਮਾਂ, ਨੀਂਦ ਦੀ ਸਥਿਤੀ ਅਤੇ ਐਪ ਦਾ ਵਿਵਹਾਰ।