ਕੀ WireGuard ਕਲਾਇੰਟ OpenVPN ਕਲਾਇੰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ?

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

ਲੱਛਣ ਵਿੱਚ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕੋ ਹਿੱਸਾ ਗ਼ਾਇਬ ਹੁੰਦਾ ਹੈ

ਇਹ ਡਿਜ਼ਾਈਨ wg1 ਉੱਤੇ 10.71.0.0/24 ਦਾ WireGuard ਪੂਲ ਅਤੇ tun1 ਉੱਤੇ 10.72.0.0/24 ਦਾ OpenVPN ਪੂਲ ਵਰਤਦਾ ਹੈ, ਦੋਵੇਂ ਇੱਕੋ ਗੇਟਵੇ ਉੱਤੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ। ਜਾਂਚ ਅਧੀਨ ਬੇਨਤੀ 10.71.0.5 ਤੋਂ 10.72.0.30 ਉੱਤੇ HTTPS ਤੱਕ ਜਾਂਦੀ ਹੈ। ਹੇਠਾਂ ਹਰ ਕਦਮ ਉਸੇ ਇੱਕ ਪ੍ਰਵਾਹ ਬਾਰੇ ਹੈ। ਹਰ ਜਾਂਚ ਦਾ ਅਸਫ਼ਲਤਾ ਦਾ ਨਿਸ਼ਾਨ ਵੱਖਰਾ ਹੈ ਭਾਵੇਂ ਵਰਤੋਂਕਾਰ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਗ਼ਾਇਬ ਹੁੰਦਾ ਹੈ।

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

ਸਪੋਕ ਦੀ ਟਿਕਾਣਾ ਕਵਰੇਜ ਵਧਾਓ

WireGuard ਕਲਾਇੰਟ ਉੱਤੇ, ਮੌਜੂਦਾ peer ਐਂਟਰੀ ਨੂੰ OpenVPN ਟਿਕਾਣੇ ਲਈ ਗੇਟਵੇ ਚੁਣਨਾ ਪਵੇਗਾ, ਭਾਵ ਟਿਕਾਣਾ ਪ੍ਰੀਫ਼ਿਕਸ ਉਸ peer ਦੀ ਮਨਜ਼ੂਰ ਸੂਚੀ ਵਿੱਚ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਨੂੰ ਜੋੜਨ ਨਾਲ ਦੂਜੀ ਟਨਲ ਨਹੀਂ ਬਣਦੀ; ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਉਸ ਪਤੇ ਨੂੰ ਲੱਭਦਿਆਂ ਕਿਹੜਾ peer ਚੁਣਦਾ ਹੈ, ਅਤੇ wg-quick ਨਾਲ ਰੂਟ ਆਮ ਤੌਰ 'ਤੇ ਸੂਚੀ ਦਾ ਆਪਣੇ ਆਪ ਪਾਲਣ ਕਰਦਾ ਹੈ।

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

ਗੇਟਵੇ ਉੱਤੇ ਸਰੋਤ ਮਾਲਕੀ ਰੱਖੋ

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

AllowedIPs = 10.71.0.5/32

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

OpenVPN ਪਾਸੇ ਨੂੰ ਵਾਪਸੀ ਰੂਟ ਦਿਓ

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

push "route 10.71.0.0 255.255.255.0"

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

ਸਿਰਫ਼ ਉਸੇ ਇੱਕ ਸੇਵਾ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿਓ ਜਿਸ ਦੀ ਤੁਸੀਂ ਮਨਜ਼ੂਰੀ ਦੇਣਾ ਚਾਹੁੰਦੇ ਸੀ

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

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