OpenVPN ਦਾ "File exists" ਰੂਟ ਉੱਤੇ ਫਾਈਲ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ

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

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

ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗ ਰਿਹਾ ਸੀ

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

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

ਮੌਜੂਦਾ ਰੂਟ ਪੜ੍ਹੋ, ਸਿਰਫ਼ ਪਤਾ ਨਹੀਂ

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

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

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

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

ਪ੍ਰੀਫਿਕਸ ਦੇ ਚਾਰ ਮਾਲਕ ਹੋ ਸਕਦੇ ਹਨ

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

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

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

block-local ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

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

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

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

ਚੱਕਰ ਬੰਦ ਕਰੋ: ਦੋਹਰੇਪਣ ਨੂੰ ਇਸਦੇ ਸਰੋਤ ਉੱਤੇ ਹਟਾਓ

ਇੱਕ ਵਾਰ ਜਾਣ ਲਓ ਕਿ ਕਿਹੜਾ ਮਾਲਕ ਐਂਟਰੀ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜਿੱਥੇ ਨਿਰਦੇਸ਼ ਪਰਿਭਾਸ਼ਿਤ ਹੈ ਉੱਥੇ ਹੀ ਦੋਹਰਾ ਨਿਰਦੇਸ਼ ਹਟਾ ਦਿਓ। ਇਹ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ route ਲਾਈਨ, ਸਰਵਰ ਤੋਂ ਆਇਆ push, ਜਾਂ ਹੁਣ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਾ ਹੋਣ ਵਾਲਾ ਹੁੱਕ ਹੋ ਸਕਦਾ ਹੈ।

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

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

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