WireGuard ਹੈਂਡਸ਼ੇਕ ਕੰਮ ਕਰਦਾ ਹੈ, ਸੇਵਾ ਨਹੀਂ

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

ਜੋ ਪਹਿਲਾ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਉੱਥੇ ਰੁਕੋ, ਅਤੇ ਬਾਕੀਆਂ ਲਈ ਨਿਯਮ ਨਾ ਜੋੜੋ।

ਹੈਂਡਸ਼ੇਕ ਸਿਰਫ਼ ਟਨਲ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

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

ਸੁਣਨ ਵਾਲਾ ਅਤੇ ਮਾਰਗ ਪੜ੍ਹੋ

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

ਸਥਾਨਕ ਇਨਪੁਟ ਲਈ ਨਿਯਮ ਲਾਗੂ ਕਰੋ, ਫਾਰਵਰਡਿੰਗ ਲਈ ਨਹੀਂ

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

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

ਸਰਟੀਫਿਕੇਟ ਜਾਂਚਾਂ ਆਪਣੀ ਥਾਂ ਰਹਿਣ ਦਿਓ। ਅਣਕਿਆਸੀ ਸਰਟੀਫਿਕੇਟ ਪਛਾਣ ਇਹ ਜਾਣਕਾਰੀ ਹੈ ਕਿ ਕਿਹੜੇ ਹੋਸਟ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਨਾ ਕਿ ਟਾਲਣਯੋਗ ਰੁਕਾਵਟ। ਇਸ ਉੱਤੇ ਕਲਿੱਕ ਕਰਕੇ ਅੱਗੇ ਵਧਣਾ ਗਲਤ ਸੇਵਾ ਪਛਾਣਨ ਵਾਲਾ ਇਕੱਲਾ ਸੁਰਾਗ ਲੁਕਾ ਦਿੰਦਾ ਹੈ।

ਨਾਮ, ਆਕਾਰ ਅਤੇ ਪਛਾਣ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਵੱਖ ਕਰੋ

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

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

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