OpenVPN ਰਾਹੀਂ ਜਨਤਕ ਪ੍ਰੀਫ਼ਿਕਸ: ਵਾਪਸੀ ਦਾ ਰਾਹ ਠੀਕ ਕਰੋ

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

ਪ੍ਰੀਫ਼ਿਕਸ ਪਹਿਲਾਂ ਤੁਹਾਡੇ ਵੱਲ ਰਾਊਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

ਦੋ ਰਾਊਟਿੰਗ ਪੱਧਰ: ਕਰਨਲ ਰੂਟ ਅਤੇ iroute

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

ਸਰਵਰ-ਪਾਸੇ ਦਾ ਰੂਟ ਇੰਝ ਦਿਸਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਮਾਸਕ ਅਲਾਟਮੈਂਟ ਨਾਲ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ:

ip route add 198.51.100.64/28 dev tun0

ਕਲਾਇੰਟ-ਖਾਸ ਕਨਫਿਗਰੇਸ਼ਨ ਮਾਲਕੀ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੇ ਆਮ ਨਾਮ 'ਤੇ ਨਾਮਿਤ CCD ਫਾਈਲ ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਉਹੀ ਡਾਇਰੈਕਟਰੀ ਪੜ੍ਹਦਾ ਹੈ:

iroute 198.51.100.64 255.255.255.240

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

ਸੇਵਾ ਪਤਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ

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

ਸੇਵਾ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਖ਼ਤਮ ਕਰਨ ਵਾਲੇ Linux ਕਲਾਇੰਟ 'ਤੇ ਇੱਕ ਹੀ ਹੋਸਟ ਪਤਾ ਕਾਫ਼ੀ ਹੈ:

ip address add 198.51.100.70/32 dev lo

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

ਵਾਪਸੀ ਦੇ ਰਾਹ 'ਤੇ ਜਨਤਕ ਸਰੋਤ ਰੱਖੋ

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

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

iptables -t nat -S POSTROUTING

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

ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਡੈਲੀਗੇਟ ਕੀਤਾ ਪਤਾ ਕਿਹੜਾ ਰਾਹ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਚੱਲਦੇ ਸਮੇਂ ਟਨਲ ਵੇਖੋ:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

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

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

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