LAN ਸਰਵਰ 'ਤੇ VPN ਕਲਾਇੰਟ: ਜਵਾਬ ਗਲਤ ਰਾਹ ਕਿਉਂ ਲੈਂਦੇ ਹਨ

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

ਜਵਾਬ ਨਵਾਂ ਪੈਕਟ ਹੈ, ਰਾਹ ਦਾ ਉਲਟਾ ਸਫ਼ਰ ਨਹੀਂ

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

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

ਬਾਕੀ ਪੜ੍ਹਦਿਆਂ ਦੋ ਸਬਨੈੱਟ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ। ਇੱਕ VPN ਪਤਾ ਪੂਲ ਹੈ ਜਿੱਥੋਂ ਦੂਰ ਦੇ ਕਲਾਇੰਟ ਆਉਂਦੇ ਹਨ, ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ 10.64.0.0/24। ਦੂਜਾ ਉਹ LAN ਹੈ ਜੋ ਚੱਲਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, 172.16.24.0/24, ਇਸ ਦਾ ਰਾਊਟਰ 172.16.24.1 'ਤੇ। ਖਰਾਬੀ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫ਼ਿਕ ਡਿਫ਼ਾਲਟ ਰੂਟ ਤੈਅ ਕਰਦਾ ਹੈ।

ਕੈਪਚਰ ਅਤੇ ਲੁੱਕਅੱਪ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਜਵਾਬ ਕਿਹੜਾ ਡਿਵਾਈਸ ਵਰਤੇਗਾ। ਲੁੱਕਅੱਪ ਕੈਪਚਰ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ ਅਤੇ ਪੈਕਟ ਬਣਨ ਵੇਲੇ ਕਰਨਲ ਜਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਵੇਗਾ, ਉਸੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

ਜਵਾਬ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਪੜ੍ਹੋ। ਜੇ ਇਹ dev tun0 ਦੱਸਦਾ ਹੈ, ਤਾਂ ਹੋਸਟ ਜਵਾਬ ਨੂੰ ਇਨਕੈਪਸੂਲੇਟ ਕਰਕੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਦੇਵੇਗਾ, ਅਤੇ LAN ਕਲਾਇੰਟ ਇਸ ਨੂੰ ਕਦੇ ਨਹੀਂ ਵੇਖੇਗਾ। ਜੇ ਇਹ dev eth0 ਦੱਸਦਾ ਹੈ ਪਰ ਕਲਾਇੰਟ ਨੂੰ ਫਿਰ ਵੀ ਸਮਾਂ-ਸਮਾਪਤੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਰੂਟ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਹੈ ਅਤੇ ਪੈਕਟ ਬਾਅਦ ਵਿੱਚ ਸੁੱਟਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਜੋ ਦੂਜੀ ਸਮੱਸਿਆ ਅਤੇ ਦੂਜਾ ਹੱਲ ਹੈ।

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

ਟਨਲ ਨੂੰ ਪਛਾੜਨ ਵਾਲਾ ਸਭ ਤੋਂ ਤੰਗ ਰੂਟ ਸਥਾਪਤ ਕਰੋ

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

ਦੂਜੇ add ਦੀ ਥਾਂ replace ਵਰਤੋ, ਕਿਉਂਕਿ ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲਾ ਕਲਾਇੰਟ ਆਪਣੀ ਐਂਟਰੀ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਤ ਕਰ ਚੁੱਕਾ ਹੋਵੇਗਾ ਅਤੇ ਦੂਜਾ add ਮੌਜੂਦਾ ਰੂਟ ਦੀ ਗਲਤੀ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜੋ ਇਜਾਜ਼ਤ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। Windows ਹੋਸਟ 'ਤੇ ਬਰਾਬਰ route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p ਹੈ, ਜਿੱਥੇ -p ਰੀਬੂਟ ਦੌਰਾਨ ਐਂਟਰੀ ਰੱਖਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਦੁਬਾਰਾ ਉੱਠਣ 'ਤੇ ਕਲਾਇੰਟ ਸਾਰਣੀ ਮੁੜ ਬਣਾ ਸਕਦਾ ਹੈ। ਆਧੁਨਿਕ Windows ਹੋਸਟ 'ਤੇ ਸਮਰਥਿਤ ਬਰਾਬਰ New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore ਹੈ, ਅਤੇ ਪੁਰਾਣਾ route ਹੁਕਮ ਲੀਗੇਸੀ ਰੂਪ ਵਜੋਂ ਰੱਖਿਆ ਗਿਆ ਹੈ।

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

ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਵੀ ਜਵਾਬ ਰੱਖੋ

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

ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਸਹੀ ਰੂਟ ਨੂੰ ਫਿਰ ਵੀ ਹਰਾ ਸਕਦਾ ਹੈ। ਜੇ ਕੈਪਚਰ ਹੁਣ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਵਾਬ eth0 ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਫਿਰ ਵੀ ਸਮਾਂ-ਸਮਾਪਤੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਜਾਂਚੋ ਕਿ ਹੋਸਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟ ਸੁੱਟ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਖ਼ਤ ਰਿਵਰਸ-ਪਾਥ ਫ਼ਿਲਟਰਿੰਗ ਅਤੇ net.ipv4.conf.all.rp_filter ਨੂੰ 1 'ਤੇ ਸੈੱਟ ਕਰਨਾ, ਉਹ ਪੈਕਟ ਸੁੱਟਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਸਰੋਤ ਜਿਸ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਆਇਆ ਉਸੇ ਰਾਹੀਂ ਵਾਪਸ ਰਾਊਟ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਇਹ ਠੀਕ ਉਹੀ ਅਸਮਮਿਤ ਸਥਿਤੀ ਹੈ ਜੋ ਤੁਸੀਂ ਹੁਣੇ ਬਣਾਈ ਅਤੇ ਫਿਰ ਠੀਕ ਕੀਤੀ, ਅਤੇ conntrack ਸਥਿਤੀ ਫਾਰਵਰਡ ਕੀਤੇ ਪੋਰਟਾਂ ਲਈ ਵੀ ਉਹੀ ਕਹਾਣੀ ਕਹਿੰਦੀ ਹੈ।

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