VPN ਕਲਾਇੰਟ ਸਰਵਰ ਤੱਕ ਪੁੱਜਦੇ ਹਨ, LAN ਤੱਕ ਨਹੀਂ: ਕਿਹੜਾ ਹੱਲ?

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

ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੀ ਦਿਸ਼ਾ ਟੁੱਟੀ ਹੈ

ਬੇਨਤੀ VPN ਪੂਲ ਤੋਂ ਆਏ ਸਰੋਤ ਪਤੇ ਨਾਲ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਆਉਂਦੀ ਹੈ। ਸਰਵਰ ਇਸਨੂੰ LAN ਦੇ ਹੋਸਟ ਤੱਕ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਉਹ ਹੋਸਟ ਉਸ ਗੇਟਵੇ ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਜਿਸਦਾ ਨਾਮ ਉਸਦੀ ਆਪਣੀ ਸਾਰਣੀ ਲੈਂਦੀ ਹੈ, ਆਮ ਤੌਰ ਤੇ LAN ਦਾ ਰਾਊਟਰ। ਜੇ ਰਾਊਟਰ ਕੋਲ ਪੂਲ ਲਈ ਰੂਟ ਨਹੀਂ ਹੈ, ਤਾਂ ਜਵਾਬ ਉੱਥੇ ਹੀ ਮਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇੰਟਰਨੈੱਟ ਵੱਲ ਭਟਕਦਾ ਹੈ।

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

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

ਜੇ LAN ਦਾ ਹੋਸਟ ਪਹਿਲਾਂ ਹੀ VPN ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ MTU ਸੀਮਾ ਹੈ, ਵਾਪਸੀ ਦਾ ਰਾਹ ਗੁੰਮ ਨਹੀਂ। ਫਿਲਟਰ ਠੀਕ ਕਰਨ ਲਈ ਰੂਟ ਨਾ ਜੋੜੋ।

ਪਹਿਲਾ ਸਵਾਲ: ਕੀ ਤੁਸੀਂ ਦੂਰ ਦੇ LAN ਦਾ ਰਾਊਟਰ ਸੰਪਾਦਿਤ ਕਰ ਸਕਦੇ ਹੋ?

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

ਕੋਈ ਪੂਲ ਬਦਲਣ ਵਾਲੇ ਦਿਨ ਇਹ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਮੁੱਲ ਇੱਕ ਵਾਰ ਲਿਖ ਲਓ ਅਤੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਥਾਂ ਦੇ ਬਦਲਾਅ ਨੂੰ ਤਿੰਨਾਂ ਦਾ ਬਦਲਾਅ ਮੰਨੋ।

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

ਦੂਜਾ ਸਵਾਲ: ਕੀ LAN ਕਲਾਇੰਟ ਪਤੇ ਦੇਖਣਾ ਬੰਦ ਕਰ ਸਕਦਾ ਹੈ?

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

ਕੀਮਤ ਐਟ੍ਰਿਬਿਊਸ਼ਨ ਹੈ: ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਪਤੇ LAN ਦੇ ਲਾਗਾਂ ਤੋਂ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। LAN ਦੇ ਹੋਸਟ ਉੱਤੇ ਕੋਈ ਵੀ ਆਗਿਆ ਸੂਚੀ ਤਦ ਪੂਲ ਦੀ ਥਾਂ ਸਰਵਰ ਦਾ ਨਾਮ ਲਵੇਗੀ।

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

ਤੀਜਾ ਸਵਾਲ: ਕੀ ਸਰਵਰ ਖੁਦ ਕਿਸੇ ਦੂਜੇ ਟਨਲ ਦਾ ਕਲਾਇੰਟ ਹੈ?

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

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

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

ਫਿਰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਅਤੇ ਦੋਵੇਂ ਆਕਾਰ ਜਾਂਚੋ

ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਤੋਂ LAN ਦੇ ਹੋਸਟ ਤੱਕ ਅਤੇ ਫਿਰ LAN ਦੇ ਹੋਸਟ ਤੋਂ ਕਲਾਇੰਟ ਤੱਕ ping ਕਰੋ। ਦੂਜੀ ਦਿਸ਼ਾ ਉਹੀ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਹੀ ਅਧੂਰੇ ਅਨੁਵਾਦ ਨਿਯਮ ਨੂੰ ਬੇਨਕਾਬ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਨਤੀਜੇ ਸਮੇਂ ਦੀ ਮੋਹਰ ਨਾਲ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਦਾ ਰਿਗ੍ਰੈਸ਼ਨ ਤੁਲਨਾਯੋਗ ਹੋਵੇ।

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

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