WireGuard ਨਵੀਨਤਮ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਦਿਖਾ ਰਿਹਾ: ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

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

ਜਾਂਚ ਉਹ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪੈਕਟ ਹੈ ਜੋ peer ਨੂੰ ਲੈ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਮੰਜ਼ਿਲ ਵੱਲ। ਉਸ ਸਥਿਤੀ ਸਕ੍ਰੀਨ ਦੀ ਬਾਕੀ ਹਰ ਚੀਜ਼ ਗਤੀਵਿਧੀ ਨਹੀਂ, ਇਰਾਦਾ ਦੱਸਦੀ ਹੈ।

ਨਿਸ਼ਕਿਰਿਆ ਇੰਟਰਫੇਸ ਕੋਲ ਦੱਸਣ ਲਈ ਕੁਝ ਨਹੀਂ

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

ਜੇ ਦੋਵੇਂ ਪਾਸਿਆਂ ਕਾਊਂਟਰ ਜ਼ੀਰੋ ’ਤੇ ਹਨ, ਸਮੱਸਿਆ ਟਨਲ ਤੋਂ ਉੱਪਰ ਹੈ। ਇੰਟਰਫੇਸ ਤੱਕ ਕੁਝ ਨਹੀਂ ਪਹੁੰਚਾ ਜੋ ਕੁਝ ਸ਼ੁਰੂ ਕਰੇ।

ਉਹ ਟ੍ਰੈਫਿਕ ਟ੍ਰਿਗਰ ਕਰੋ ਜੋ peer ਲੈ ਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਰੱਖਦਾ ਹੈ

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

ਰੂਟ ਪੁੱਛਗਿੱਛ ping ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਇਹ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਪੈਕਟ ਕਦੇ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਨਹੀਂ ਹੋਇਆ ਅਤੇ ਖਾਲੀ ਹੈਂਡਸ਼ੇਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਨਹੀਂ, ਰਾਊਟਿੰਗ ਦਾ ਜਵਾਬ ਹੈ। peer ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰੂਟ ਠੀਕ ਕਰੋ।

ਕੁੰਜੀ ਜੋੜੀ ਅਤੇ ਐਂਡਪੌਇੰਟ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

ਐਂਡਪੌਇੰਟ ਨੂੰ ਵੀ ਉਹੀ ਜਾਂਚ ਚਾਹੀਦੀ ਹੈ: ਹੋਸਟਨਾਮ, ਪਤਾ, UDP ਪੋਰਟ ਅਤੇ ਉੱਥੇ ਪਹੁੰਚਣ ਲਈ ਵਰਤਿਆ ਪਰਿਵਾਰ। ਪੁਰਾਣਾ ਪਤਾ ਜਾਂ ਗਲਤ ਪੋਰਟ ਸੁਨੇਹੇ ਦੀ ਬਜਾਏ ਚੁੱਪੀ ਦਿੰਦਾ ਹੈ।

ਬਾਹਰੀ UDP ਮਾਰਗ ’ਤੇ ਨਜ਼ਰ ਰੱਖੋ

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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