OpenVPN ਹਾਲੇ ਵੀ ਪੁਰਾਣੇ ਰੂਟ ਧੱਕ ਰਿਹਾ ਹੈ? ਦੇਖੋ ਇਸ ਨੇ ਕੀ ਲੋਡ ਕੀਤਾ

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

ਹੇਠਾਂ ਦਿੱਤੀ ਤੁਲਨਾ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਹਰ ਵੱਲ ਜਾਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਕਿਹੜੀ ਫਾਈਲ ਲਾਗੂ ਹੈ ਇਹ ਸਿਰਫ਼ ਪ੍ਰਕਿਰਿਆ ਹੀ ਜਾਣਦੀ ਹੈ।

ਤੁਹਾਡੇ ਵੱਲੋਂ ਸੋਧੀ ਫਾਈਲ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਵੱਲੋਂ ਪੜ੍ਹੀ ਜਾਣ ਵਾਲੀ ਫਾਈਲ

unit ਅਤੇ ਉਸ ਵੱਲੋਂ ਬਣਾਈ ਕਮਾਂਡ ਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। systemd ਹੋਸਟ ਉੱਤੇ systemctl cat openvpn@server ExecStart ਲਾਈਨ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਇੰਸਟੈਂਸ unit ਆਮ ਤੌਰ ਉੱਤੇ ਆਪਣਾ ਸੰਰਚਨਾ ਮਾਰਗ ਇੰਸਟੈਂਸ ਦੇ ਨਾਂ ਤੋਂ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ openvpn@office ਵਜੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਡੈਮਨ openvpn@server ਵਜੋਂ ਸ਼ੁਰੂ ਕੀਤੇ ਨਾਲੋਂ ਵੱਖਰੀ ਫਾਈਲ ਪੜ੍ਹਦਾ ਹੈ। ਇਸ ਦੀ ਤੁਲਨਾ ਚੱਲ ਰਹੀ ਪ੍ਰਕਿਰਿਆ ਦੇ argv ਨਾਲ ਕਰੋ। ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਸਾਧਨ ਤਬਦੀਲੀ ਗੁਆਉਣ ਦਾ ਇੱਕ ਹੋਰ ਢੰਗ ਜੋੜਦਾ ਹੈ: ਇਹ ਸਹੀ ਫਾਈਲ ਅਜਿਹੀ ਥਾਂ ਲਿਖ ਸਕਦਾ ਹੈ ਜਿਸਦਾ unit ਕਦੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਫਿਰ ਸਫਲ ਡਿਪਲਾਏ ਕੁਝ ਨਾ ਕੀਤਾ ਹੋਇਆ ਜਾਪਦਾ ਹੈ।

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

ਸਰਵਰ ਕੀ ਧੱਕਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਕੀ ਸਥਾਪਤ ਕਰਦਾ ਹੈ

ਧੱਕੇ ਗਏ ਰੂਟ ਨੂੰ ਦੋ ਫਿਲਟਰ ਪਾਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ। ਸਰਵਰ ਉੱਤੇ ਇਹ ਲੋਡ ਕੀਤੀ ਸੰਰਚਨਾ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਟਿੱਪਣੀ ਕੀਤੇ ਬਲਾਕ ਵਿੱਚ ਜਾਂ ਉਸ ਕਲਾਇੰਟ-ਖਾਸ ਫਾਈਲ ਵਿੱਚ ਨਹੀਂ ਜਿਸਦਾ ਨਾਂ ਨਹੀਂ ਮਿਲਦਾ। ਕਲਾਇੰਟ ਉੱਤੇ pull ਸਮਰੱਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ pull-filter ਉਸ ਚੋਣ ਨੂੰ ਨਹੀਂ ਸੁੱਟ ਸਕਦਾ। verbosity 4 ਨਾਲ ਜੁੜੋ ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਦੱਸੇ ਧੱਕੇ ਗਏ ਵਿਕਲਪ ਪੜ੍ਹੋ: ਜੇ ਰੂਟ ਉਸ ਸੂਚੀ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੇ ਆਪਣਾ ਕੰਮ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਥਾਪਤ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਲਾਇੰਟ ਕਰ ਰਿਹਾ ਹੈ।

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

ਧੱਕਿਆ ਗਿਆ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਵਾਪਸੀ ਦਾ ਰੂਟ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ

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

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

ਦੋਹਾਂ ਸਿਰਿਆਂ ਦੀਆਂ ਸਾਰਣੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

ਤਿੰਨ ਪਛਾਣਾਂ ਇਕੱਠੀਆਂ ਰੱਖੋ: ਸੰਰਚਨਾ ਮਾਰਗ, unit ਜਾਂ ਇੰਸਟੈਂਸ ਦਾ ਨਾਂ, ਅਤੇ ਉਹ ਕਲਾਇੰਟ ਪਛਾਣ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਜਾਂਚ ਕੀਤੀ।

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

ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਣ ਵਾਲੀ ਰੂਟ ਸਮੱਸਿਆ ਅਕਸਰ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਹੀ ਨਹੀਂ ਹੁੰਦੀ; ਖ਼ਰਾਬੀ ਤੁਸੀਂ ਲਗਾਤਾਰ ਪੜ੍ਹਦੇ ਰਹਿੰਦੇ ਹੋ ਉਸ ਸਾਰਣੀ ਤੋਂ ਉੱਪਰ ਹੁੰਦੀ ਹੈ।