ਜਦੋਂ OpenVPN ਦਾ ਸਰਵਰ ਉਸੇ ਹੋਸਟ 'ਤੇ ਚੱਲਦਾ ਹੈ ਤਾਂ ਕਲਾਇੰਟ ਰੁਕ ਜਾਂਦਾ ਹੈ

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

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

ਲੱਛਣ ਨੂੰ ਉਲਟਾ ਪੜ੍ਹੋ

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

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

ਹਰ ਇੰਸਟੈਂਸ ਲਈ ਇੱਕ ਸਾਕਟ ਅਤੇ ਇੱਕ ਡਿਵਾਈਸ

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

lport 1195
nobind
dev tun1

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

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

ਡਿਫਾਲਟ ਰੂਟ ਲਈ ਇੱਕ ਮਾਲਕ ਚੁਣੋ

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

ਸਟੇਟਸ ਲਾਈਨ ਨਾਲ ਨਹੀਂ, ਟੇਬਲ ਨਾਲ ਜਾਂਚੋ

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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