OpenVPN 3 Linux: ਵਾਪਸ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ D-Bus ਗਲਤੀ ਪੜ੍ਹੋ
ਪੰਜ ਸੇਵਾਵਾਂ, ਇੱਕ ਫਰੰਟਐਂਡ। D-Bus ਗਲਤੀ ਨੂੰ ਉਸ ਹਿੱਸੇ ਨਾਲ ਜੋੜੋ ਜਿਸਨੇ ਇਨਕਾਰ ਕੀਤਾ, ਦੇਖੋ ਕਿ ਸੈਸ਼ਨ ਹੈ ਜਾਂ ਨਹੀਂ, ਫਿਰ ਉਸੇ ਹੱਦ 'ਤੇ ਸੁਧਾਰ ਕਰੋ।
OpenVPN 3 Linux ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਕਿਸੇ ਅਣਜਾਣ ਨਾਮ ਨਾਲ D-Bus ਢੰਗ ਦੀ ਗਲਤੀ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਲਾਲਚ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਪੈਕੇਜ ਦਾ ਸੰਸਕਰਣ ਹੇਠਾਂ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਆਸ ਰੱਖੀ ਜਾਵੇ। ਕਲਾਇੰਟ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਨਹੀਂ ਹੈ: ਕਮਾਂਡ-ਲਾਈਨ ਫਰੰਟਐਂਡ ਬੱਸ ਰਾਹੀਂ ਉਨ੍ਹਾਂ ਸੇਵਾਵਾਂ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰੋਫਾਈਲ, ਸੈਸ਼ਨ, VPN ਇੰਜਣ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੀਆਂ ਨੈੱਟਵਰਕ ਤਬਦੀਲੀਆਂ ਦੇ ਮਾਲਕ ਹਨ। ਇਹ ਤੈਅ ਕਰਨਾ ਕਿ ਇਨ੍ਹਾਂ ਪੰਜਾਂ ਵਿੱਚੋਂ ਕੌਣ ਅਸਫਲ ਕਾਲ ਦਾ ਮਾਲਕ ਹੈ, ਨਿਦਾਨ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਹਿੱਸਾ ਹੈ ਅਤੇ ਵਾਪਸ ਜਾਣ ਦੀ ਥਾਂ ਇੱਕ ਕਮਾਂਡ ਦਾ ਖਰਚ ਹੈ। ਅੱਗੇ ਉਹੀ ਫੈਸਲਾ ਹੈ, ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਿਸ ਵਿੱਚ ਅਸਫਲਤਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਦਿਸਦੀਆਂ ਹਨ।
ਇੱਕ ਕਮਾਂਡ ਪਿੱਛੇ ਪੰਜ ਮਾਲਕ
ਪੰਜ ਪ੍ਰਕਿਰਿਆਵਾਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਬੱਸ ਨਾਮ ਹੈ: ਤੁਹਾਡੀ ਕਮਾਂਡ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਫਰੰਟਐਂਡ, ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀ ਪਹੁੰਚ ਨੀਤੀ ਰੱਖਣ ਵਾਲਾ ਕਨਫਿਗਰੇਸ਼ਨ ਮੈਨੇਜਰ, ਸੈਸ਼ਨ ਦੀ ਉਮਰ ਰੱਖਣ ਵਾਲਾ ਸੈਸ਼ਨ ਮੈਨੇਜਰ, OpenVPN 3 Core Engine ਰਾਹੀਂ ਕਨੈਕਸ਼ਨ ਚਲਾਉਣ ਵਾਲਾ ਬੈਕਐਂਡ, ਅਤੇ ਇੰਟਰਫੇਸ, ਰਸਤੇ ਤੇ DNS ਸੈਟਿੰਗਾਂ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲੀ ਨੈੱਟਵਰਕ ਕਨਫਿਗਰੇਸ਼ਨ ਸੇਵਾ। ਇਸ ਲਈ ਕਨਫਿਗਰੇਸ਼ਨ ਆਬਜੈਕਟ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਗਲਤੀ ਬੈਕਐਂਡ ਦੀ ਗਲਤੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਸ਼ੁਰੂ ਨਾ ਹੋਣ ਵਾਲਾ ਬੈਕਐਂਡ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਅਸਫਲਤਾ ਨਹੀਂ ਹੈ। ਸੁਨੇਹੇ ਨੂੰ ਉਨ੍ਹਾਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਰੱਖਣਾ ਕਿਸੇ ਵੀ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਕਦਮ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ਕਿਹੜੀ ਲਾਈਨ ਸੱਚੀ ਹੈ। ਲਾਈਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਉਹ ਰਾਹ ਹੈ ਜਿਸ 'ਤੇ ਛੋਟਾ ਸੁਧਾਰ ਪੈਕੇਜਾਂ ਨਾਲ ਦੁਪਹਿਰ ਭਰ ਦਾ ਕੰਮ ਬਣ ਜਾਂਦਾ ਹੈ।
ਹੋਰ ਕੁਝ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਸਿਸਟਮ ਬੱਸ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀਆਂ ਸੇਵਾਵਾਂ ਮੌਜੂਦ ਹਨ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਥਾਪਿਤ ਹਿੱਸੇ ਇੱਕ ਸੰਸਕਰਣ 'ਤੇ ਸਹਿਮਤ ਹਨ। OpenVPN 3 Linux ਉਨ੍ਹਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਸਿਸਟਮ ਯੂਨਿਟ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੁੱਛਣ ਵਾਲੀ ਬੱਸ ਸਿਸਟਮ ਬੱਸ ਹੈ, ਸੰਸਕਰਣ ਦੀ ਪੁੱਛਗਿੱਛ ਲਈ ਪ੍ਰਬੰਧਕੀ ਅਧਿਕਾਰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ --user ਨਾਲ ਬਣੀ ਸੂਚੀ ਤੁਹਾਡੇ ਲੌਗਇਨ ਸੈਸ਼ਨ ਨੂੰ ਪੜ੍ਹਦੀ ਹੈ, ਜਿੱਥੇ ਯੂਨਿਟ ਕਦੇ ਨਹੀਂ ਦਿਸਦੇ। ਸੇਵਾਵਾਂ ਮੰਗ 'ਤੇ ਸਰਗਰਮ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਕੁਝ ਖਾਲੀ ਹੋਣ 'ਤੇ ਬੰਦ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਤੁਹਾਡੀ ਪਹਿਲੀ ਬੇਨਤੀ ਤੋਂ ਪਹਿਲਾਂ ਗਾਇਬ ਸੇਵਾ ਨੂੰ ਹਾਲੇ ਕਿਸੇ ਚੀਜ਼ ਬਾਰੇ ਪੁੱਛਿਆ ਹੀ ਨਹੀਂ ਗਿਆ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਤਿੰਨ ਕਮਾਂਡਾਂ VPN ਸੈਸ਼ਨ ਨਾ ਖੋਲ੍ਹ ਕੇ ਮੌਜੂਦਗੀ, ਸੰਸਕਰਣ ਅਤੇ ਯੂਨਿਟ ਦੀ ਹਾਲਤ ਦੱਸਦੀਆਂ ਹਨ।
sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'ਹਰ ਸੂਚੀ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦੀ ਹੈ
ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਦ੍ਰਿਸ਼ ਉਪਲਬਧ ਸਭ ਤੋਂ ਸਸਤਾ ਸਬੂਤ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਿਸਦੇ ਨਾਲੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਕਨਫਿਗਰੇਸ਼ਨ ਸੂਚੀ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪ੍ਰੋਫਾਈਲ ਆਯਾਤ ਹੋਈ ਹੈ ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਿ ਕੋਈ ਇਸ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸੈਸ਼ਨ ਸੂਚੀ ਵਿੱਚ ਸੈਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਆਬਜੈਕਟ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਿ ਦੂਰੋਂ ਪ੍ਰਮਾਣਿਕਤਾ ਪੂਰੀ ਹੋਈ ਹੈ ਜਾਂ ਨਹੀਂ।
openvpn3 configs-list
openvpn3 sessions-listਉਨ੍ਹਾਂ ਆਉਟਪੁੱਟਾਂ ਵਿੱਚ ਆਬਜੈਕਟ ਰਸਤੇ ਬੱਸ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਆਬਜੈਕਟ ਦਰਸਾਉਂਦੇ ਹਨ, ਫਾਈਲਾਂ ਨਹੀਂ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਸੋਧਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਅਤੇ ਪਹਿਲਾਂ ਦਰਜ ਕੀਤਾ ਰਸਤਾ ਉਸੇ ਪਲ ਪੁਰਾਣਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਹ ਸੈਸ਼ਨ ਡਿਸਕਨੈਕਟ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਨੋਟਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੁਬਾਰਾ ਵਰਤਣ ਨਾਲ "no such object" ਗਲਤੀਆਂ ਬਣਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ VPN ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤਾ ਪੜਾਅ ਸਾਰਣੀ ਇਹ ਵੱਖ ਕਰਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਦਾ ਹਰ ਕਦਮ ਕੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਖੁੱਲ੍ਹਾ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਦਾ ਫੈਸਲਾ ਬਿਲਕੁਲ ਇਸੇ ਫ਼ਰਕ 'ਤੇ ਟਿਕਿਆ ਹੈ। ਆਪਣੇ ਸਬੂਤ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਲਾਈਨ ਪੜ੍ਹੋ, ਫਿਰ ਗਲਤੀ ਦਾ ਲਿਖਤ ਦੁਬਾਰਾ ਪੜ੍ਹੋ।
| Stage | What exists | What proves it | What it does not prove |
|---|---|---|---|
| Profile imported | A configuration object held by the configuration manager | The profile is listed by the client | That the profile owner permits a connection |
| Session requested | A session object held by the session manager | The session appears in the session list | That the remote side accepted the credentials |
| Connect dispatched | An asynchronous attempt on the VPN backend | Status changes arrive for that session | That an interface was configured |
| Tunnel configured | An interface, routes and DNS settings | The network service reports success and routes appear | That traffic reaches the peer |
ਕਨੈਕਸ਼ਨ ਕਾਲ ਸੁਰੰਗ ਮੌਜੂਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ
ਕਨੈਕਸ਼ਨ ਕਾਲ ਤੁਹਾਨੂੰ ਨਿਗਰਾਨੀ ਲਈ ਸੈਸ਼ਨ ਦਿੰਦੀ ਹੈ ਅਤੇ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਸਫਲ ਕਾਲ ਤੋਂ ਬਾਅਦ ਚੁੱਪ ਇੱਕ ਆਮ ਵਿਚਕਾਰਲੀ ਹਾਲਤ ਹੈ, ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ। ਫਰੰਟਐਂਡ ਨੂੰ ਫਿਰ ਵੀ ਹਾਲਤ ਦੇ ਬਦਲਾਅ ਪਿੱਛਾ ਕਰਨੇ ਪੈਂਦੇ ਹਨ ਅਤੇ ਹਰ ਆਪਸੀ ਕਿਰਿਆ ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਦੇਣਾ ਪੈਂਦਾ ਹੈ। ਜਿਸ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ, ਉਹ ਅਜਿਹੀ ਹਾਲਤ ਵਿੱਚ ਉਡੀਕਦੀ ਹੈ ਜੋ ਬਿਲਕੁਲ ਅਟਕੇ ਬੈਕਐਂਡ ਵਰਗੀ ਦਿਸਦੀ ਹੈ। ਉਸ ਉਡੀਕ ਦੀ ਹਾਲਤ ਨੂੰ ਪਛਾਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਲੋਕਾਂ ਨੂੰ ਗਲਤ ਹਿੱਸੇ ਵੱਲ ਭੇਜਦੀ ਹੈ।
ਜਦੋਂ ਕੋਈ ਕੋਸ਼ਿਸ਼ ਚੱਲ ਰਹੀ ਹੋਵੇ, ਉਸ ਪ੍ਰੋਫਾਈਲ ਲਈ ਸੈਸ਼ਨ ਸੂਚੀ ਅਤੇ ਫਰੰਟਐਂਡ ਦਾ ਆਪਣਾ ਲੌਗ ਦੇਖੋ। ਜੋ ਸੈਸ਼ਨ ਆਪਣੀ ਸ਼ੁਰੂਆਤੀ ਹਾਲਤ ਕਦੇ ਨਹੀਂ ਛੱਡਦਾ ਉਹ ਰੁਕੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਲੌਗ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲੀਆਂ ਹੀ ਲਾਈਨਾਂ ਵਿੱਚ ਉਸਦਾ ਨਾਮ ਲੈ ਲੈਂਦਾ ਹੈ। ਪ੍ਰੋਫਾਈਲ ਦਾ ਨਾਮ ਨੇੜੇ ਰੱਖੋ, ਕਿਉਂਕਿ ਲੌਗ ਕਮਾਂਡ ਸੈਸ਼ਨ ਰਸਤਾ ਨਹੀਂ ਸਗੋਂ ਪ੍ਰੋਫਾਈਲ ਲੈਂਦੀ ਹੈ, ਜੋ ਰਸਤਾ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਥਾਂ ਸੂਚੀ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਦਾ ਇੱਕ ਹੋਰ ਕਾਰਨ ਹੈ।
openvpn3 sessions-list
openvpn3 log --config <profile> --level 6ਸੈਸ਼ਨ ਨਾ ਖੋਲ੍ਹ ਕੇ ਇੱਕ ਹਿੱਸੇ ਦਾ ਲੌਗ ਪੜ੍ਹਨਾ
ਜਦੋਂ ਫਰੰਟਐਂਡ ਕੋਈ ਕੰਮ ਦੀ ਗੱਲ ਨਹੀਂ ਦੱਸਦਾ, ਤਾਂ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਥਾਂ ਉਸ ਹਿੱਸੇ ਕੋਲ ਜਾਓ ਜਿਸਨੇ ਅਸਫਲਤਾ ਲੌਗ ਕੀਤੀ। ਸੈੱਟ ਕੀਤੇ systemd-journald ਲੌਗਰ ਨਾਲ, ਪ੍ਰਬੰਧਕ ਦਾ ਸੀਮਤ ਜਰਨਲ ਦ੍ਰਿਸ਼ ਇੱਕ ਹਿੱਸੇ ਦੀਆਂ ਘਟਨਾਵਾਂ ਪੜ੍ਹਦਾ ਹੈ, ਬੱਸ ਨੀਤੀ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਅਤੇ ਸੈਸ਼ਨ ਨਾ ਖੋਲ੍ਹ ਕੇ, ਅਤੇ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਜੋ ਨਿਦਾਨ ਮਾਪੀ ਜਾ ਰਹੀ ਸਿਸਟਮ ਨੂੰ ਹੀ ਬਦਲ ਦਿੰਦਾ ਹੈ ਉਹ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਯੂਨਿਟ ਅਨੁਸਾਰ ਛਾਂਟੋ, syslog ਟੈਗ ਅਨੁਸਾਰ ਨਹੀਂ: ਵੱਖਰੇ ਸੇਵਾ ਯੂਨਿਟ ਸਾਂਝੀ ਪਛਾਣ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੇ, ਇਸ ਲਈ ਟੈਗ ਦੀ ਪੁੱਛਗਿੱਛ ਖਾਲੀ ਪੰਨਾ ਵਾਪਸ ਕਰ ਸਕਦੀ ਹੈ ਜਦਕਿ ਯੂਨਿਟ ਨੇ ਖੁਦ ਅਸਫਲਤਾ ਦਰਜ ਕੀਤੀ ਹੋਵੇ।
ਕਿਸੇ ਤੋਂ ਮਦਦ ਮੰਗਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਖੇਤਰ ਲਿਖੋ: ਗਲਤੀ ਦਾ ਪੂਰਾ ਨਾਮ, ਸਬੰਧਤ ਸੇਵਾ ਅਤੇ ਆਬਜੈਕਟ, ਸਮੇਂ ਦੀ ਮੋਹਰ, ਅਤੇ ਸਥਾਪਿਤ ਪੈਕੇਜਾਂ ਦੇ ਸੰਸਕਰਣ। ਇਹੀ ਉਹ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਸੰਭਾਲ ਕਰਨ ਵਾਲੇ ਨੂੰ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਲਈ ਵੀ ਪ੍ਰੋਫਾਈਲ ਜਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਟਿਕਟ ਵਿੱਚ ਚਿਪਕਾਉਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਗਲਤੀ ਨੂੰ ਚੁੱਪ ਕਰਾਉਣ ਲਈ ਬੱਸ ਪਹੁੰਚ ਨੀਤੀ ਚੌੜੀ ਕਰਨਾ ਨਿਦਾਨ ਨਹੀਂ ਹੈ, ਇਹ ਉਹ ਹੱਦ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੀ ਥਾਂ ਹਿੱਸੇ ਦਾ ਨਾਮ ਲੈ ਰਹੀ ਸੀ। ਪ੍ਰੋਫਾਈਲ ਦੀ ਨਿੱਜੀ ਸਮੱਗਰੀ ਸਾਂਝੀਆਂ ਰਿਪੋਰਟਾਂ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੀ ਹੈ, ਜਿਸ ਕਾਰਨ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਬਾਹਰ ਰਹਿੰਦੇ ਹਨ।
journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>ਜਿਸ ਹੱਦ ਨੇ ਇਨਕਾਰ ਕੀਤਾ ਉਸਦਾ ਸੁਧਾਰ
ਨਕਸ਼ੇ ਦੀ ਹਰ ਲਾਈਨ ਦਾ ਆਪਣਾ ਸੁਧਾਰ ਹੈ, ਅਤੇ ਲਾਈਨਾਂ ਇੱਕ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀਆਂ। ਪ੍ਰੋਫਾਈਲ 'ਤੇ ਰੱਦ ਕੀਤੀ ਕਾਰਵਾਈ ਨੀਤੀ ਅਤੇ ਮਾਲਕੀ ਦਾ ਸਵਾਲ ਹੈ, ਜਦਕਿ ਸਰਗਰਮ ਨਾ ਹੋਣ ਵਾਲਾ ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ ਅਤੇ ਪੈਕੇਜਿੰਗ ਦਾ ਸਵਾਲ ਹੈ। ਪ੍ਰਮਾਣਿਕਤਾ ਰੱਦ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ, ਇਸ ਲਈ ਵਾਰ-ਵਾਰ ਪਾਸਵਰਡ ਬਦਲਣਾ ਸਥਾਨਕ ਸਰਗਰਮੀ ਦੀ ਸਮੱਸਿਆ ਸੁਧਾਰ ਨਹੀਂ ਸਕਦਾ। ਗਲਤ ਸੁਧਾਰ ਚੁਣਨਾ ਉਹ ਰਾਹ ਹੈ ਜਿਸ 'ਤੇ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਦੁਬਾਰਾ ਸਥਾਪਨਾ ਬਣ ਜਾਂਦੀ ਹੈ।
ਪੈਕੇਜ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣੀ ਬਾਈਨਰੀ ਨੂੰ ਉਸਦੀ ਥਾਂ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਇੱਕ ਸੁਸੰਗਤ ਅਤੇ ਸਮਰਥਿਤ ਸਥਾਪਨਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਨਿਯੰਤਰਿਤ ਵਾਪਸੀ ਪੁਸ਼ਟ ਹੋਏ ਰਿਗਰੈਸ਼ਨ ਦਾ ਜਾਇਜ਼ ਜਵਾਬ ਹੈ, ਬਸ਼ਰਤੇ ਪੈਕੇਜ ਸੁਸੰਗਤ ਰਹਿਣ ਅਤੇ ਸਮਰਥਿਤ ਸੰਭਾਲ ਵੱਲ ਵਾਪਸੀ ਦਾ ਰਾਹ ਮੌਜੂਦ ਹੋਵੇ। ਉਹ ਰਾਹ ਸੇਵਾ ਦੇ ਸ਼ੁਰੂ ਹੋਣਾ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ।
ਕੋਈ ਹੋਰ ਪਲੇਟਫਾਰਮ ਉਹੀ ਮੂਲ VPN ਲਾਇਬ੍ਰੇਰੀ ਸਾਂਝੀ ਕਰ ਸਕਦਾ ਹੈ Linux ਦੀਆਂ ਬੱਸ ਸੇਵਾਵਾਂ ਸਾਂਝੀਆਂ ਕੀਤੇ ਬਿਨਾਂ, ਇਸ ਲਈ Windows 'ਤੇ ਮਿਲਦੀ-ਜੁਲਦੀ ਅਸਫਲਤਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। D-Bus ਦਾ ਸੰਖੇਪ ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਅਤੇ ਸੈਸ਼ਨਾਂ ਲਈ ਖੋਲ੍ਹੇ ਗਏ ਆਬਜੈਕਟ ਰਸਤਿਆਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਿਦਾਨ ਜਿਸ ਢਾਂਚੇ 'ਤੇ ਟਿਕਿਆ ਹੈ ਉਹੀ ਹਿੱਸਾ ਹੈ। ਇੱਕ ਵਾਰ ਪੜ੍ਹੋ, ਅਤੇ ਅਗਲੀ ਗਲਤੀ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨਾਲ ਜੁੜੇ ਹਿੱਸੇ ਸਮੇਤ ਆਵੇਗੀ।