OpenVPN ਰਾਹੀਂ LAN ਪਹੁੰਚ ਟੁੱਟੀ? ਜ਼ੋਨ, ਰੂਟ ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਜਾਂਚੋ

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

LAN ਵੱਲ ਜਾਂਦੇ ਪੈਕਟ ਨੂੰ ਕਿਹੜਾ ਫਿਲਟਰ ਵੇਖਦਾ ਹੈ

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

ਵੰਡਿਆ ਟਨਲ ਨੂੰ ਧੱਕਿਆ ਪ੍ਰੀਫਿਕਸ ਕਿਉਂ ਚਾਹੀਦਾ ਹੈ

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਸਾਥੀ ਧੱਕਣ ਤੋਂ ਵੱਧ ਮੰਗਦਾ ਹੈ। ਸਰਵਰ ਨੇ ਸਿੱਖਣਾ ਹੈ ਕਿ ਉਸ ਸਾਥੀ ਦੇ ਪਿੱਛੇ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਹਨ, ਜੋ ਉਸ ਦੀ client-config-dir ਫਾਈਲ ਵਿੱਚਲੀ iroute ਲਾਈਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਉਸ ਦੀ ਆਪਣੀ ਟੇਬਲ ਨੂੰ ਟਨਲ ਵਿੱਚ ਜਾਣ ਵਾਲਾ ਮੇਲ ਖਾਂਦਾ ਰੂਟ ਵੀ ਚਾਹੀਦਾ ਹੈ।

ਜਵਾਬ ਨੂੰ ਉਹ ਪਤਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਪਹੁੰਚ ਸਕੇ

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

tcpdump -ni tun0 host 192.168.50.20

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

ਸਹੀ ਥਾਂ ਤੇ ਖਤਮ ਹੋਣ ਵਾਲੀ ਪੌੜੀ

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

ਨਾਮ ਪੌੜੀ ਦੇ ਅੰਤ ਵਿੱਚ ਆਉਂਦੇ ਹਨ, ਕਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਨਹੀਂ। ਜੋ ਸ਼ੇਅਰ 192.168.50.20 ਵਜੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਪਰ nas.local ਵਜੋਂ ਨਹੀਂ, ਉਹ ਨਾਮ ਨਿਪਟਾਰੇ ਜਾਂ ਖੋਜ ਪਿਛੇਤਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਸੋਧਾਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਬਦਲ ਸਕਦੀਆਂ।

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