LAN ਰਾਊਟਰ ਅਤੇ VPN ਕਲਾਇੰਟ: ਦੋ ਡਿਵਾਈਸ, ਦੋ ਰੂਟ ਟੇਬਲ

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

ਕਿਸੇ ਰੂਟ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਹੌਪ ਖਿੱਚੋ

ਇੱਕ ਉਦਾਹਰਨ ਲੇਆਉਟ ਲਓ: LAN ਹੋਸਟ 192.168.50.0/24 ’ਤੇ, ਆਮ ਰਾਊਟਰ 192.168.50.1 ’ਤੇ, ਸਮਰਪਿਤ ਕਲਾਇੰਟ 192.168.50.15 ’ਤੇ, ਅਤੇ ਦੂਰ ਦਾ LAN 10.60.0.0/24 ’ਤੇ ਜੋ ਸਿਰਫ਼ ਉਸ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ ਜੋ ਉਹ ਕਲਾਇੰਟ ਰੱਖਦਾ ਹੈ। ਦੋਵੇਂ ਪ੍ਰਾਈਵੇਟ ਰੇਂਜਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੂਜੇ ਨੂੰ ਓਵਰਲੈਪ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਟਨਲ ਦੀ ਆਪਣੀ ਐਡਰੈਸ ਯੋਜਨਾ ਹੈ।

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

ਕਦਮ 1: ਰਾਊਟਰ ਨੂੰ ਟਨਲ ਵੱਲ ਨਹੀਂ, ਕਲਾਇੰਟ ਵੱਲ ਮੋੜੋ

LAN ਰਾਊਟਰ ’ਤੇ, ਇੱਕ ਮੰਜ਼ਿਲ ਰੂਟ ਜੋੜੋ ਜਿਸ ਦਾ ਅਗਲਾ ਹੌਪ ਕਲਾਇੰਟ ਦਾ LAN ਐਡਰੈਸ ਹੈ:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

ਦੂਜੀ ਕਮਾਂਡ ਦਾ ਜਵਾਬ ਵੇਖੋ। ਜੇ ਇਹ ਕਲਾਇੰਟ ਨੂੰ gateway ਅਤੇ LAN ਇੰਟਰਫ਼ੇਸ ਨੂੰ device ਵਜੋਂ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾ ਹੌਪ ਸਹੀ ਹੈ ਅਤੇ ਬਾਕੀ ਕੰਮ ਦੂਜੀ ਮਸ਼ੀਨ ’ਤੇ ਹੈ।

ਕਦਮ 2: ਕਲਾਇੰਟ ਨੂੰ ਟਨਲ ਪਾਸੇ ਆਪਣਾ ਰੂਟ ਦਿਓ

ਕਲਾਇੰਟ ਹੁਣ 10.60.0.0/24 ਲਈ ਪੈਕਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਆਪਣੀ ਟੇਬਲ ਵੇਖਦਾ ਹੈ। ਜੇ ਇਸ ਦੀ ਟਨਲ ਕੌਨਫਿਗਰੇਸ਼ਨ ਨੇ ਉਸ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਇੰਸਟਾਲ ਕੀਤਾ ਹੈ, ਤਾਂ ਪੈਕਟ ਐਨਕ੍ਰਿਪਟਿਡ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਨਹੀਂ, ਤਾਂ ਪੈਕਟ ਆਮ ਡਿਫ਼ਾਲਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ 192.168.50.1 ’ਤੇ ਵਾਪਸ ਜਾਂਦਾ ਹੈ, ਜੋ ਇਸ ਨੂੰ ਫਿਰ ਕਲਾਇੰਟ ਵੱਲ ਭੇਜਦਾ ਹੈ।

ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੋ:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

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

ਲੂਪ, ਜਦੋਂ ਹੁੰਦੀ ਹੈ, ਵਿਹਾਰ ਵਿੱਚ ਅਨੰਤ ਨਹੀਂ: ਹਰ ਪਾਸ ’ਤੇ TTL ਘਟਦਾ ਹੈ ਅਤੇ ਪੈਕਟ ਸਮਾਂ ਲੰਘਣ ਦੇ ਸੁਨੇਹੇ ਨਾਲ ਮਰ ਜਾਂਦਾ ਹੈ। ਇਸੇ ਲਈ ਦੁਹਰਾਇਆ traceroute ਚੱਕਰ ਦਾ ਸੰਕੇਤ ਦੇ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਿਰਫ਼ ਫਾਰਵਰਡ ਨਾ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਉਹੀ ਪੈਕਟ ਚੁੱਪਚਾਪ ਡੇਗ ਦਿੰਦਾ ਹੈ।

ਕਦਮ 3: ਫਾਰਵਰਡਿੰਗ ਦੀ ਆਗਿਆ ਦਿਓ ਅਤੇ ਵਾਪਸੀ ਦਾ ਰਾਹ ਚੁਣੋ

ਲੈਣਾ ਅਤੇ ਫਾਰਵਰਡ ਕਰਨਾ ਵੱਖਰੀਆਂ ਆਗਿਆਵਾਂ ਹਨ। ਕਲਾਇੰਟ ’ਤੇ net.ipv4.ip_forward=1 ਕਰਨਲ ਪੱਧਰ ’ਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੇ ਅਜੇ ਵੀ ਇਸ ਨੂੰ LAN ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਟਨਲ ਵਿਚਕਾਰ ਆਗਿਆ ਦੇਣੀ ਹੈ। ਜੋ ਨਿਯਮ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਪ੍ਰਬੰਧਨ ਪੇਜ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਉਹ ਦੂਰ ਦੇ LAN ਤੱਕ ਟ੍ਰਾਂਜ਼ਿਟ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦੇਵੇਗਾ, ਅਤੇ ਜਦੋਂ ਉਹੀ ਹੋਸਟ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਤਾਂ ਇਹ ਫ਼ਰਕ ਖੁੰਝਣਾ ਸੌਖਾ ਹੈ।

ਦੂਰ ਦੇ ਪਾਸੇ ਸ਼ੀਸ਼ੇ ਵਾਲੀ ਸਮੱਸਿਆ ਹੈ। ਇਸ ਨੂੰ ਜਾਣਨਾ ਚਾਹੀਦਾ ਹੈ ਕਿ 192.168.50.0/24 ਇਸ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ। OpenVPN ਨਾਲ ਆਮ ਤੌਰ ’ਤੇ ਇਸ ਦਾ ਮਤਲਬ ਸਰਵਰ ਕੌਨਫਿਗਰੇਸ਼ਨ ਵੱਲੋਂ ਧੱਕਿਆ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਰੂਟ, ਜਾਂ ਸਰਵਰ ’ਤੇ ਕਲਾਇੰਟ-ਖ਼ਾਸ ਫ਼ਾਈਲ ਹੁੰਦਾ ਹੈ ਜੋ ਕਲਾਇੰਟ ਪਿੱਛੇ ਦੇ LAN ਦਾ ਐਲਾਨ ਕਰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਦੂਰ ਦਾ LAN ਜਾਂ ਤਾਂ ਜਵਾਬ ਡੇਗ ਦਿੰਦਾ ਹੈ ਜਾਂ ਇਸ ਨੂੰ ਆਪਣੇ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ, ਯਾਨੀ ਇੰਟਰਨੈੱਟ ’ਤੇ ਭੇਜ ਦਿੰਦਾ ਹੈ।

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

ਕਦਮ 4: ਦੋਵੇਂ ਫ਼ੈਸਲੇ ਪੱਕੇ ਕਰੋ, ਫਿਰ ਅਸਲੀ ਰਾਹ ਦੀ ਜਾਂਚ ਕਰੋ

ਹਰ ਰੂਟ ਦਾ ਇੱਕ ਮਾਲਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਮਾਲਕ ਉਹ ਕੌਨਫਿਗਰੇਸ਼ਨ ਹੈ ਜੋ ਬੂਟ ’ਤੇ ਜਾਂ ਦੁਬਾਰਾ ਕਨੈਕਟ ’ਤੇ ਮੁੜ ਬਣਦੀ ਹੈ। ਰਾਊਟਰ ’ਤੇ ਇਹ ਸਟੈਟਿਕ ਰੂਟ ਐਂਟਰੀ ਹੋ ਸਕਦੀ ਹੈ; ਕਲਾਇੰਟ ’ਤੇ ਇਹ VPN ਪ੍ਰੋਫ਼ਾਈਲ, NetworkManager ਜਾਂ systemd-networkd ਹੋ ਸਕਦੀ ਹੈ। ਟਨਲ ਦੁਬਾਰਾ ਜੋੜ ਕੇ ਅਤੇ ਕਲਾਇੰਟ ਰੀਬੂਟ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਤਬਦੀਲੀ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਟੇਬਲ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।

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

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