UDP ਸਕੈਨ ਕਹਿੰਦਾ ਹੈ ਫਿਲਟਰ ਕੀਤਾ: ਕੀ ਤੁਹਾਡਾ WireGuard ਸਾਥੀ ਸੱਚਮੁੱਚ ਬੰਦ ਹੈ?

ਸਕੈਨਰ UDP ਪੋਰਟ ਲਈ ਖੁੱਲ੍ਹਾ ਜਾਂ ਫਿਲਟਰ ਕੀਤਾ ਛਾਪਦੇ ਹਨ, ਅਤੇ ਸਿੱਟਾ ਆਮ ਤੌਰ ’ਤੇ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ: ਟਨਲ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ। ਇਹ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਸਕੈਨ ਨੇ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕੀਤਾ। UDP ਕੋਈ ਕਨੈਕਸ਼ਨ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ ਚੁੱਕਦਾ, ਅਤੇ WireGuard ਉਸ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਜਿਸ ਨੂੰ ਉਹ ਤਸਦੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਇਸ ਲਈ ਬਹੁਤੀਆਂ ਜਾਂਚਾਂ ਲਈ ਚੁੱਪੀ ਹੀ ਉਮੀਦ ਕੀਤੀ ਜਵਾਬ ਹੈ।

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

ਸਕੈਨਰ ਕੀ ਦੇਖ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

UDP ਸਕੈਨਰ ਇੱਕ ਪੇਲੋਡ ਭੇਜਦਾ ਹੈ ਅਤੇ ਉਡੀਕਦਾ ਹੈ। ਜੇ ICMP port-unreachable ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੋਰਟ ਨੂੰ ਬੰਦ ਦੱਸ ਸਕਦਾ ਹੈ। ਜੇ ਕੁਝ ਵੀ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਨਤੀਜਾ ਬਣਾਵਟ ਹੀ ਅਸਪਸ਼ਟ ਹੈ: ਫਿਲਟਰ ਕੀਤਾ ਰਾਹ, ਗੈਰਹਾਜ਼ਰ ਹੋਸਟ ਅਤੇ ਚੱਲ ਰਹੀ ਸੇਵਾ ਜਿਸ ਨੇ ਪੇਲੋਡ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ, ਸਾਰੇ ਇੱਕੋ ਚੁੱਪੀ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਤਿੰਨ ਵੱਖਰੀਆਂ ਹਾਲਤਾਂ, ਇੱਕ ਆਊਟਪੁੱਟ ਸਟਰਿੰਗ।

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

ਉਸੇ ਪੋਰਟ ਨੰਬਰ ’ਤੇ TCP ਟੈਸਟ ਕੋਈ ਸੰਬੰਧਿਤ ਚੀਜ਼ ਨਹੀਂ ਜਾਂਚਦਾ। ਇਹ ਕਿਸੇ ਹੋਰ ਸਰੋਤੇ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਮੌਜੂਦ ਨਾ ਹੋਵੇ, ਅਤੇ ਉਸ ਦਾ ਇਨਕਾਰ UDP ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।

ਇਸ ਲਈ ਖੁੱਲ੍ਹੀਆਂ ਫਿਲਟਰ ਕੀਤੀਆਂ ਹਾਲਤਾਂ ਤੁਹਾਡੇ ਸਰਵਰ ਨਾਲੋਂ ਸਕੈਨਰ ਦੀ ਅਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਵਧੇਰੇ ਸਹੀ ਢੰਗ ਨਾਲ ਦੱਸਦੀਆਂ ਹਨ।

ਅਸਲ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਤੋਂ ਅੰਦਰ ਤੱਕ ਤੁਰੋ

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

ਫਿਰ ਤੀਜੀ ਥਾਂ ਤੋਂ ਵੱਖਰਾ ਸਕੈਨ ਚਲਾਉਣ ਦੀ ਥਾਂ, ਇੱਕ ਅਧਿਕਾਰਤ ਕੋਸ਼ਿਸ਼ ਦੌਰਾਨ ਸਰਵਰ ਵੱਲ ਦੇਖੋ:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦੇ ਹੋ ਤਾਂ ਉੱਥੇ ਹੀ ਸੰਬੰਧ ਜੋੜੋ

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

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

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

ਸਕੈਨ ਦੇ ਨਤੀਜੇ ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਪੜ੍ਹਨਾ

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

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

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