ਕੀ ਦੋ OpenVPN ਸਰਵਰਾਂ ਦੇ ਕਲਾਇੰਟ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ?

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

ਭਰਮ: ਇੱਕ ਖਾਤਾ ਸੂਚੀ, ਇੱਕ ਨੈੱਟਵਰਕ

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

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

ਹਰ ਗੇਟਵੇ ਨੂੰ ਆਪਣਾ ਪੂਲ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਪਤਾ ਦਿਓ

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

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

ਦੋਵੇਂ ਪਾਸਿਆਂ ਰੂਟ ਲਾਓ

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

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

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

ਮਾਲਕੀ ਦਾ ਨਾਟਕ ਕੀਤੇ ਬਿਨਾਂ ਕਲਾਇੰਟ ਰੂਟ ਧੱਕੋ

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

push "route 10.64.20.0 255.255.255.0"

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

ਇੱਕ ਬੇਨਤੀ ਸਾਬਤ ਕਰੋ ਅਤੇ ਦੂਜੀ ਨਾਮਨਜ਼ੂਰ ਕਰੋ

ਇੱਕ ਅਸਲੀ ਕਾਰਵਾਈ ਚੁਣੋ, ਜਿਵੇਂ 10.64.10.21 ਉੱਤੇ ਕਲਾਇੰਟ ਤੋਂ 10.64.20.37 ਉੱਤੇ ਸੇਵਾ ਤੱਕ HTTPS, ਅਤੇ ਦੋਵਾਂ ਹੋਸਟਾਂ ਉੱਤੇ ਠੀਕ ਉਹੀ ਇਜਾਜ਼ਤ ਦਿਓ। ਹਰ ਫਾਇਰਵਾਲ ਆਪਣੇ ਇਨਬਾਊਂਡ ਪਾਸੇ ਬੇਨਤੀ ਅਤੇ ਵਾਪਸੀ ਪਾਸੇ ਟਰੈਕ ਕੀਤਾ ਜਵਾਬ ਸਵੀਕਾਰਦਾ ਹੈ; ਮੰਜ਼ਿਲ ਦੀ ਆਪਣੀ ਸੇਵਾ ਨੀਤੀ ਨੂੰ ਅਜੇ ਵੀ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

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

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