ਉਹੀ .ovpn ਫਾਈਲ ਇੱਕ ਸ਼ੈੱਲ ਤੋਂ ਕਨੈਕਟ ਹੁੰਦੀ ਹੈ ਅਤੇ NetworkManager ਵਿੱਚ ਆਯਾਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸਮਾਂ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਕੁਦਰਤੀ ਸਿੱਟਾ ਇਹ ਹੈ ਕਿ VPN ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ। ਵਧੇਰੇ ਸੰਭਾਵਿਤ ਵਿਆਖਿਆ ਛੋਟੀ ਹੈ: NetworkManager ਨੇ ਫਾਈਲ ਨਹੀਂ ਰੱਖੀ, ਇਸਦਾ ਕੁਝ ਹਿੱਸਾ ਸੰਭਾਲੇ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਆਯਾਤ ਕੀਤਾ, ਅਤੇ ਚੱਲ ਰਹੀ ਟਨਲ ਇਸਦੀ ਬਜਾਏ ਉਹ ਸੰਭਾਲਿਆ ਡੇਟਾ ਵਰਤਦੀ ਹੈ। ਫਾਈਲ ਹੁਣ ਕੀ ਕਹਿੰਦੀ ਹੈ, ਇਸਦਾ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕੀ ਹੈ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ।

ਫਾਈਲ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ ਹੈ

ਆਯਾਤ ਇੱਕ ਅਨੁਵਾਦ ਹੈ, ਮਾਊਂਟ ਨਹੀਂ। ਪਲੱਗਇਨ ਜੋ ਵਿਕਲਪ ਸਮਝਦਾ ਹੈ ਉਹ ਕਨੈਕਸ਼ਨ ਦੇ vpn.data ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਕੁੰਜੀਆਂ ਬਣ ਜਾਂਦੇ ਹਨ; ਜੋ ਵਿਕਲਪ ਇਹ ਨਹੀਂ ਸਮਝਦਾ ਉਹ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਾਂ ਕਿਤੇ ਹੋਰ ਦਰਜ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮੂਲ ਪਾਥ ਸਿਰਫ਼ ਇੱਕ ਹਵਾਲਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਸਰੋਤ ਫਾਈਲ ਦਾ ਸੰਪਾਦਨ ਕਰਨ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲੇ ਕਨੈਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।

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

ਸੰਭਾਲਿਆ ਪ੍ਰੋਫਾਈਲ ਪੜ੍ਹੋ, ਸੰਵਾਦ ਨਹੀਂ

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

ਜਦੋਂ ਦੋ ਪ੍ਰੋਫਾਈਲ ਇੱਕੋ ਨਾਮ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਤਾਂ UUID ਵਰਤੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੇਵਾ ਕਿਸਮ ਤੁਹਾਡੀ ਉਮੀਦ ਵਾਲਾ OpenVPN ਪਲੱਗਇਨ ਹੈ, ਕੋਈ ਹੋਰ VPN ਕਿਸਮ ਨਹੀਂ ਜੋ ਸੰਜੋਗ ਨਾਲ ਸਥਾਪਿਤ ਹੋਵੇ। ਫਿਰ ਐਂਡਪੌਇੰਟ, ਟਰਾਂਸਪੋਰਟ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਹਵਾਲਿਆਂ ਦੀ ਤੁਲਨਾ ਕੰਮ ਕਰ ਰਹੀ ਕਾਲ ਨਾਲ ਕਰੋ।

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

ਦੋ ਕੁੰਜੀਆਂ, ਅਤੇ ਇੱਕ ਜ਼ਰੂਰੀ ਦਿਸ਼ਾ

TLS ਪ੍ਰਮਾਣੀਕਰਨ ਵਰਤਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਲਈ, ਪਲੱਗਇਨ ਸਾਂਝੀ ਕੁੰਜੀ ਦਾ ਪਾਥ ta ਵਿੱਚ ਅਤੇ ਦਿਸ਼ਾ ta-dir ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਤੈਨਾਤੀ ਇੱਕ ਵਰਤਦੀ ਹੈ। ਦੋਵੇਂ ਪ੍ਰੋਫਾਈਲ ਦੇ ਡੇਟਾ ਸ਼ਬਦਕੋਸ਼ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਸਰਵਰ ਦੀ ਉਮੀਦ ਨਾਲ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ।

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

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

ਇੱਕ ਐਂਟਰੀ ਅੱਪਡੇਟ ਕਰੋ, ਸ਼ਬਦਕੋਸ਼ ਨਹੀਂ

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

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

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

ਨਿਯੰਤਰਣ-ਚੈਨਲ ਦੇ ਮੋਡਾਂ ਨੂੰ ਨਾ ਮਿਲਾਓ

tls-auth, tls-crypt, ਅਤੇ tls-crypt-v2 ਵੱਖਰੀਆਂ ਵਿਵਸਥਾਵਾਂ ਹਨ। ਮਿਲਦੀ-ਜੁਲਦੀ ਦਿਖਣ ਵਾਲੀ ਕੁੰਜੀ ਫਾਈਲ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦੀ, ਅਤੇ ਦੂਜੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਫਾਰਮੈਟ ਕੀਤੀ ਕੁੰਜੀ ਹੋਣ ਕਰਕੇ TLS-Auth ਖੇਤਰ ਭਰਨਾ ਅਜਿਹਾ ਪ੍ਰੋਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਗਲਤ ਕੁੰਜੀ ਵਰਗੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

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

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

ਸੰਬੰਧਿਤ ਲੇਖ