VPN ਲੌਗਾਂ ਲਈ journalctl: ਕਿਹੜੀ ਯੂਨਿਟ ਕਨੈਕਸ਼ਨ ਦੀ ਮਾਲਕ ਹੈ?

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

ਤਿੰਨ ਆਮ ਮਾਲਕਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

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

NetworkManager ਆਪਣੇ ਬਣਾਏ ਪ੍ਰੋਫਾਈਲਾਂ ਦਾ ਮਾਲਕ ਹੈ, ਅਤੇ ਅਧਾਰ ਪਲੱਗਇਨ VPN ਸਹਾਇਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਇਸ ਦੇ ਸੁਨੇਹੇ NetworkManager.service ਅਧੀਨ ਰਹਿੰਦੇ ਹਨ। ਜਦੋਂ ਪ੍ਰੋਫਾਈਲ ਇਸ ਤਰ੍ਹਾਂ ਪ੍ਰਬੰਧਿਤ ਹੋਵੇ ਤਾਂ ਮੈਨੇਜਰ ਅਤੇ ਸਹਾਇਕ ਯੂਨਿਟ ਦੋਵਾਂ ਨੂੰ ਪੁੱਛੋ।

ਕਿਊਰੀ ਨੂੰ ਇੱਕ ਯੂਨਿਟ ਅਤੇ ਇੱਕ ਵਿੰਡੋ ਤੱਕ ਸੰਕੁਚਿਤ ਕਰੋ

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

journalctl -u [email protected] --since today
systemctl list-units --type=service | grep -i vpn
systemctl cat [email protected]

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

ਪਹਿਲਾ ਅਸਫਲ ਪੜਾਅ ਪੜ੍ਹੋ

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

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

ਅਸਫਲ ਸੇਵਾ ਨੂੰ ਹੱਥ ਨਾਲ ਚਲਾਏ ਕਲਾਇੰਟ ਨਾਲ ਨਾ ਮਿਲਾਓ

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

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

ਨਿਰਯਾਤ ਨਹੀਂ, ਅੰਸ਼ ਸਾਂਝਾ ਕਰੋ

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

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