ਇੱਕੋ ਰਾਹ ਸਾਬਤ ਕਰਨ ਵਾਲਾ ਦੋ ਪੀਅਰ ਵਾਲਾ WireGuard ਟੈਸਟ ਕਿਵੇਂ ਬਣਾਈਏ

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

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

ਕੁੰਜੀਆਂ, ਪਤੇ ਅਤੇ ਇੱਕੋ ਐਂਡਪੌਇੰਟ

ਹਰ ਸਿਸਟਮ ਉੱਤੇ ਕੁੰਜੀ ਜੋੜੀ ਬਣਾਓ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਸਿਰਫ਼ ਜਨਤਕ ਅੱਧੇ ਭਾਗ ਭੇਜੋ। wg genkey | tee privatekey | wg pubkey > publickey ਦਸਤਾਵੇਜ਼ਬੱਧ ਇੱਕ-ਲਾਈਨ ਹੁਕਮ ਹੈ, ਅਤੇ ਇਹ ਨਿੱਜੀ ਕੁੰਜੀ ਨੂੰ ਉਸ ਫਾਈਲ ਵਿੱਚ ਛੱਡਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦੇ ਹੋ। ਟਨਲ ਪਤੇ ਉਸ ਦਾਇਰੇ ਵਿੱਚੋਂ ਚੁਣੋ ਜੋ ਤੁਹਾਡੀ ਹੋਰ ਕਿਸੇ ਵੀ ਸੰਰਚਨਾ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ, ਜਿਵੇਂ 10.99.0.1/24 ਅਤੇ 10.99.0.2/24। ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਪਤਾ ਕਿਹੜੀ ਮਸ਼ੀਨ ਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਬਾਅਦ ਵਾਲੀ ਜਾਂਚ ਉਸੇ ਮੈਪਿੰਗ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਨਿੱਜੀ ਕੁੰਜੀਆਂ ਕਦੇ ਸਫ਼ਰ ਨਹੀਂ ਕਰਦੀਆਂ। ਜੇ ਟੈਸਟ ਨੂੰ ਇੱਕ ਦੂਜੇ ਪਾਸੇ ਕਾਪੀ ਕਰਨੀ ਪਵੇ, ਤਾਂ ਟੈਸਟ ਪਹਿਲਾਂ ਹੀ ਗਲਤ ਹੋ ਚੁੱਕਾ ਹੈ। ਜਦੋਂ ਦੋਵੇਂ ਸਿਸਟਮ NAT ਪਿੱਛੇ ਹੋਣ, ਘੱਟੋ-ਘੱਟ ਇੱਕ ਨੂੰ ਪਹੁੰਚਯੋਗ UDP ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ ਜਦਕਿ ਦੂਜਾ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ Endpoint ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਜਨਤਕ ਪਤਾ ਤੇ ਪੋਰਟ ਤੁਹਾਡੇ ਨੋਟਾਂ ਵਿੱਚ ਹੋਣ, 51820 ਬਾਰੇ ਤੁਹਾਡੇ ਅੰਦਾਜ਼ਿਆਂ ਵਿੱਚ ਨਹੀਂ।

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

wg ਨਾਲ ਸੰਬੰਧਿਤ ਫੀਲਡ ਅਤੇ ਜੋ ਨਹੀਂ

ਮੁੱਖ ਫੀਲਡ ਸਮੂਹ ਛੋਟਾ ਹੈ: Interface ਹੇਠਾਂ PrivateKey ਅਤੇ ListenPort, Peer ਹੇਠਾਂ PublicKey, AllowedIPs ਅਤੇ Endpoint। Address ਅਤੇ DNS wg ਨੂੰ ਨਹੀਂ ਸਗੋਂ wg-quick ਨੂੰ ਸੰਬੰਧਿਤ ਹਨ, ਅਤੇ ਉਹੀ ਸੰਰਚਨਾ ਕਿਸੇ ਹੋਰ ਸਾਧਨ ਵਿੱਚ ਜਾਣ ਵੇਲੇ ਇਹ ਫ਼ਰਕ ਡੰਗਦਾ ਹੈ।

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

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

ਆਈਕਨ ਦੀ ਥਾਂ ਹੈਂਡਸ਼ੇਕ ਪੜ੍ਹਨਾ

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

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

ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੇਵਾ ਸਾਬਤ ਕਰਨਾ, ਫਿਰ ਉਲਟ ਦਿਸ਼ਾ

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

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

ਆਧਾਰ ਨੂੰ ਸੰਦਰਭ ਵਜੋਂ ਰੱਖਣਾ

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

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