Linux 'ਤੇ Kerio VPN ਕਲਾਇੰਟ: ਕ੍ਰਮ ਵਿੱਚ ਪੰਜ ਜਾਂਚਾਂ
ਕ੍ਰਮ ਵਿੱਚ ਪੰਜ ਜਾਂਚਾਂ: ਪੈਕੇਜ ਆਰਕੀਟੈਕਚਰ, CLI ਵਿਜ਼ਾਰਡ, ਕੌਂਫਿਗ ਫਾਈਲ, ਸੇਵਾ ਸਕ੍ਰਿਪਟ ਅਤੇ ਲੌਗ। ਪਹਿਲੀ ਅਸਫਲ ਜਾਂਚ 'ਤੇ ਰੁਕੋ।
Linux 'ਤੇ Kerio VPN ਕਲਾਇੰਟ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਡੈਸਕਟਾਪ 'ਤੇ ਕੋਈ ਆਈਕਨ ਨਹੀਂ ਦਿਖਦਾ ਅਤੇ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਇਸ ਕਲਾਇੰਟ ਦਾ ਆਮ ਰੂਪ ਹੈ, ਟੁੱਟੀ ਸਥਾਪਨਾ ਨਹੀਂ: GFI ਦੇ Linux ਨਿਰਦੇਸ਼ ਕਮਾਂਡ-ਲਾਈਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਤੇ ਸੇਵਾ ਸਕ੍ਰਿਪਟ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਕੋਈ GUI ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਵੱਖਰੀ ਪਰਤ ਹਟਾਉਂਦੀ ਹੈ। ਪਹਿਲੀ ਅਸਫਲਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿੱਥੇ ਰੁਕਣਾ ਹੈ, ਅਤੇ ਅੱਗੇ ਛਾਲ ਮਾਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਪੈਕੇਜ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਹੈ ਜੋ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।
ਪੱਕਾ ਕਰੋ ਕਿ ਬਿਲਡ ਮਸ਼ੀਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ
ਸ਼ੁਰੂ ਕਰੋ dpkg ਮਸ਼ੀਨ ਕੀ ਹੈ ਅਤੇ ਪੈਕੇਜ ਕਿਸ ਲਈ ਬਣਾਇਆ ਗਿਆ ਦਿਖਾਉਂਦਾ ਹੈ। ਆਮ 64-ਬਿੱਟ ਸਿਸਟਮ 'ਤੇ dpkg --print-architecture ਛਾਪਦਾ ਹੈ amd64, ਅਤੇ ਵਿਕਰੇਤਾ ਦਾ ਪੰਨਾ ਆਮ Debian ਪੈਕੇਜ ਦੇ ਕੋਲ amd64 ਪੈਕੇਜ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਸਥਾਪਤ ਕੀਤੀ ਫਾਈਲ ਦੇ ਨਾਮ ਵਿੱਚ ਰਿਲੀਜ਼ ਸਟ੍ਰਿੰਗ ਪੜ੍ਹੋ, ਦੋਵੇਂ ਮੇਲ ਖਾਂਦੇ ਹਨ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ।
2013 ਦਾ i386 ਲਈ ਬਣਿਆ ਆਰਕਾਈਵ ਸਿਰਫ਼ --force-architecture ਦੇਣ ਕਰਕੇ 64-ਬਿੱਟ ਨਹੀਂ ਬਣਦਾ। ਜ਼ਬਰਦਸਤੀ ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਵਿਦੇਸ਼ੀ ਬਾਈਨਰੀਆਂ ਬੈਠਦੀਆਂ ਹਨ, ਅਜੇ ਵੀ ਚੱਲਣ ਵਾਲੇ ਲਾਂਚਰ ਪਿੱਛੇ ਨਿਰਭਰਤਾ ਦੀ ਅਸਫਲਤਾ ਲੁਕਦੀ ਹੈ, ਅਤੇ ਡੈਮਨ ਗਲਤ ਲਾਇਬ੍ਰੇਰੀਆਂ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਰਿਲੀਜ਼ ਸਿਰਫ਼ 32-ਬਿੱਟ ਹੈ, ਤਾਂ ਇਸਨੂੰ 32-ਬਿੱਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚਲਾਓ ਜਾਂ ਗੇਟਵੇ ਮਾਲਕ ਤੋਂ ਨਵਾਂ ਬਿਲਡ ਮੰਗੋ।
ਨਿਰਭਰਤਾ ਲਾਈਨ ਵੀ ਜਾਂਚੋ। dpkg -s kerio-control-vpnclient | grep -i depends ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੈਕੇਜ ਕੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਧੂਰਾ ਵਰਜ਼ਨ ਪਿੰਨ ਜਾਂ ਗੁੰਮ ਰਨਟਾਈਮ ਲਾਇਬ੍ਰੇਰੀ ਇੱਥੇ ਦਿਖਦੀ ਹੈ, ਕਲਾਇੰਟ ਲੌਗ ਵਿੱਚ ਨਹੀਂ।
ਪੈਕੇਜ ਵਿਜ਼ਾਰਡ ਰਾਹੀਂ ਇਸਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ
ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਕਲਾਇੰਟ ਦੀ ਐਪ ਡਰਾਅਰ ਵਿੱਚ ਕੋਈ ਐਂਟਰੀ ਨਹੀਂ, ਇਸ ਲਈ ਗੁੰਮ ਆਈਕਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਫਲ ਹੋਇਆ ਜਾਂ ਨਹੀਂ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਵਿਜ਼ਾਰਡ ਦੁਬਾਰਾ ਖੋਲ੍ਹਣ ਲਈ sudo dpkg-reconfigure kerio-control-vpnclient ਚਲਾਓ ਅਤੇ ਇਸਦੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ: VPN ਐਂਡਪੌਇੰਟ, ਖਾਤੇ ਦੇ ਵੇਰਵੇ ਅਤੇ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਫਿੰਗਰਪ੍ਰਿੰਟ।
ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੇ ਸਵਾਲ ਨੂੰ ਇੱਕੋ ਥਾਂ ਮੰਨੋ ਜਿੱਥੇ ਗਲਤ ਸਰਵਰ ਜਿੱਤ ਸਕਦਾ ਹੈ। ਮੁੱਲ ਦੀ ਤੁਲਨਾ ਗੇਟਵੇ ਚਲਾਉਣ ਵਾਲੇ ਪ੍ਰਸ਼ਾਸਕ ਵੱਲੋਂ ਦਿੱਤੀ ਸਰਵਰ ਜਾਣਕਾਰੀ ਨਾਲ ਕਰੋ, ਐਂਡਪੌਇੰਟ ਜੋ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਉਸ ਨਾਲ ਨਹੀਂ। ਜਿਸ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨੂੰ ਤੁਸੀਂ ਜਾਂਚ ਨਹੀਂ ਸਕਦੇ ਉਸਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਇਸ ਸੂਚੀ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਨੂੰ ਸਜਾਵਟ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਪਿੰਨ ਸੰਭਾਲਣ ਤੋਂ ਬਾਅਦ ਦੁਸ਼ਮਣ ਸਰਵਰ ਅਸਲੀ ਵਰਗਾ ਹੀ ਦਿਖਦਾ ਹੈ। ਜੇ ਮੁੱਲ ਕਿਸੇ ਹੋਰ ਚੈਨਲ ਰਾਹੀਂ ਪੁਸ਼ਟੀ ਨਾ ਹੋ ਸਕੇ, ਤਾਂ ਰੁਕੋ ਅਤੇ ਪੁੱਛੋ, ਭਾਵੇਂ ਟਨਲ ਹੋਰ ਤਰ੍ਹਾਂ ਉੱਪਰ ਆ ਜਾਂਦਾ।
ਵਿਜ਼ਾਰਡ ਦੁਬਾਰਾ ਚਲਾਉਣ ਨਾਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਦੀ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਮੁੜ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਤੁਸੀਂ ਜਿਸ ਸੈਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਉਹ ਉਸ VPN 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ ਤਾਂ ਮਸ਼ੀਨ ਤੱਕ ਦੂਜਾ ਰਾਹ ਰੱਖੋ। ਪਾਸਵਰਡ ਆਮ ਪ੍ਰੌਂਪਟ 'ਤੇ ਟਾਈਪ ਕਰੋ, ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਵਿੱਚ ਪਹੁੰਚਣ ਵਾਲੇ ਕਮਾਂਡ ਵਿੱਚ ਪਾਉਣ ਦੀ ਬਜਾਏ।
ਵਿਜ਼ਾਰਡ ਜੋ ਫਾਈਲ ਲਿਖਦਾ ਹੈ ਉਸਨੂੰ ਜਾਣੋ
ਕੌਂਫਿਗਰੇਸ਼ਨ ਇੱਥੇ ਹੈ: /etc/kerio-kvc.conf ਅਤੇ ਇਹ ਖਾਤਾ ਅਤੇ ਪਿੰਨ ਕੀਤੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੋਵੇਂ ਰੱਖਦੀ ਹੈ। ਇਸਨੂੰ ਗੁਪਤ ਸਮੱਗਰੀ ਮੰਨੋ। sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ਇਸਨੂੰ ਸਭ ਲਈ ਪੜ੍ਹਨਯੋਗ ਨਹੀਂ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ।
ਅਧਿਕਾਰਤ ਹੱਥੀ ਸੋਧ ਤੋਂ ਬਾਅਦ, ਨੈੱਟਵਰਕ ਸਟੈਕ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਬਜਾਏ ਫਾਈਲ ਦਾ ਮਾਲਕ ਡੈਮਨ ਮੁੜ ਲੋਡ ਕਰੋ: sudo /etc/init.d/kerio-kvc reload। ਮੁੜ ਲੋਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੁਬਾਰਾ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਜੀਵਤ ਕਨੈਕਸ਼ਨ 'ਤੇ ਇਹ ਨਿਸ਼ਕਿਰਿਆ ਕਾਰਜ ਨਹੀਂ ਹੈ।
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਿਛਲੀ ਫਾਈਲ ਦੀ ਕਾਪੀ ਕਰੋ। ਜੇ ਸੋਧ ਤੋਂ ਬਾਅਦ ਪ੍ਰਮਾਣੀਕਰਨ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਆਖਰੀ ਕੰਮ ਕਰਨ ਵਾਲੀ ਕਾਪੀ ਬਹਾਲ ਕਰਨ ਵਿੱਚ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ ਇਹ ਸੋਧ ਨੂੰ ਨੈੱਟਵਰਕ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ, ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹਿਲਿਆ ਇਹ ਜਾਣਨ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਇਹੀ ਹੈ।
ਜੀਵਤ ਸੈਸ਼ਨ ਨੂੰ ਬੂਟ ਵਿਵਹਾਰ ਤੋਂ ਵੱਖ ਕਰੋ
ਸੇਵਾ ਸਕ੍ਰਿਪਟ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ: sudo /etc/init.d/kerio-kvc stop ਹੁਣੇ ਟਨਲ ਖਤਮ ਕਰਦਾ ਹੈ ਅਤੇ start ਇਸਨੂੰ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਕੋਈ ਵੀ ਕਮਾਂਡ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦੀ ਕਿ ਅਗਲੇ ਬੂਟ 'ਤੇ ਕੀ ਹੋਵੇਗਾ, ਅਤੇ ਦੂਰੋਂ ਪ੍ਰਬੰਧਿਤ ਮਸ਼ੀਨ 'ਤੇ ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਲਿੰਕ ਹਟਾਉਣ ਜਾਂ ਕੁਝ ਮਾਸਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਸਟਾਰਟਅੱਪ ਕਿਸਦਾ ਹੈ। ਪੈਕੇਜ ਆਪਣੀ init ਸਕ੍ਰਿਪਟ ਸਥਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, unit ਬਣਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਦੋਵੇਂ, ਅਤੇ ਗਲਤ ਨਾਮ ਨਿਸ਼ਕਿਰਿਆ ਕਰਨ ਨਾਲ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। systemctl status kerio-kvc ਨੂੰ ਪੈਕੇਜ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵਰਤੇ ਨਾਮ ਨਾਲ ਜਾਂਚੋ, ਫਿਰ ਬੂਟ ਪ੍ਰਕਿਰਿਆ ਅਸਲ ਵਿੱਚ ਜੋ ਪਾਥ ਪੜ੍ਹਦੀ ਹੈ ਉਸਨੂੰ ਨਿਸ਼ਕਿਰਿਆ ਕਰੋ।
ਕੌਂਫਿਗਰੇਸ਼ਨ ਇੱਕੋ ਜਿਹੀ ਦਿਖਦੀ ਹੈ ਇਸ ਲਈ OpenVPN unit ਨਾ ਬਦਲੋ। ਇਹ ਕਲਾਇੰਟ Kerio ਗੇਟਵੇ ਨਾਲ ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਗੱਲ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਉਸੇ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਦੂਜਾ ਡੈਮਨ ਪ੍ਰਮਾਣੀਕਰਨ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਵਾਧੂ ਅਸਫਲਤਾ ਸਬੂਤ ਪੜ੍ਹਨਾ ਔਖਾ ਬਣਾਉਂਦੀ ਹੈ। GFI ਦਾ Linux ਕਲਾਇੰਟ ਵੀ ਇੱਕ ਸਮੇਂ ਸਿਰਫ਼ ਇੱਕ VPN ਕਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ; ਇਹ ਸੀਮਾ ਕਲਾਇੰਟ 'ਤੇ ਲਾਗੂ ਹੈ, ਗੇਟਵੇ ਦੀ ਵਰਤੋਂਕਰਤਾ ਸਮਰੱਥਾ 'ਤੇ ਨਹੀਂ।
ਲੌਗ ਪੜ੍ਹੋ, ਫਿਰ ਸਰੋਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
ਤਿੰਨ ਫਾਈਲਾਂ /var/log/kerio-kvc ਡੈਮਨ ਦੀ ਕਹਾਣੀ ਦੱਸਦੀਆਂ ਹਨ: init.log ਜੀਵਨ ਚੱਕਰ ਦੀਆਂ ਘਟਨਾਵਾਂ ਲਈ, error.log ਗੰਭੀਰ ਅਸਫਲਤਾਵਾਂ ਲਈ ਅਤੇ debug.log ਵੇਰਵਿਆਂ ਲਈ। ਤੁਹਾਡੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਭ ਤੋਂ ਛੋਟਾ ਹਿੱਸਾ ਪੜ੍ਹੋ, ਅਤੇ ਕਿਤੇ ਵੀ ਪੇਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਐਂਡਪੌਇੰਟ ਅਤੇ ਵਰਤੋਂਕਰਤਾ ਨਾਮ ਹਟਾਓ। init.log ਵਿੱਚ ਵਿਜ਼ਾਰਡ ਚਲਾਉਣ ਦੇ ਸਮੇਂ ਦੇ ਆਸਪਾਸ ਖਾਲੀ ਥਾਂ ਹੋਵੇ ਤਾਂ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਡੈਮਨ ਕਦੇ ਮੁੜ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ।
| File | Read it for | Skip it when |
|---|---|---|
init.log | start, reload and stop events | you already know the daemon restarted |
error.log | failed authentication and certificate problems | the tunnel is up and traffic still fails |
debug.log | protocol detail worth attaching to a ticket | the error is already named in error.log |
ਵੈਧ ਪੈਕੇਜ, ਚੱਲਦਾ ਡੈਮਨ ਅਤੇ ਪਹੁੰਚਯੋਗ ਸਰੋਤ ਤਿੰਨ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ, ਅਤੇ ਤਿੰਨੇ ਪੂਰੇ ਹੋਣ 'ਤੇ ਹੀ ਸੂਚੀ ਪੂਰੀ ਹੁੰਦੀ ਹੈ। ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਗੇਟਵੇ ਪਿੱਛੇ ਹੀ ਮੌਜੂਦ ਹੋਸਟ ਮੰਗੋ, ਫਿਰ ਉਸ 'ਤੇ ਆਮ ਸੇਵਾ ਖੋਲ੍ਹੋ। ਟਨਲ ਉੱਪਰ ਹੈ ਪਰ ਸਰੋਤ ਨਹੀਂ, ਤਾਂ ਬਾਕੀ ਦੋਸ਼ ਗੇਟਵੇ ਰੂਟ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਵਿੱਚ ਹੈ, ਹੁਣੇ ਮੁੜ ਕੌਂਫਿਗਰ ਕੀਤੇ ਕਲਾਇੰਟ ਵਿੱਚ ਨਹੀਂ।
ਤੁਸੀਂ ਜਿਸ ਹਾਲਤ ਵਿੱਚ ਅੰਤ ਕੀਤਾ ਉਹ ਦਰਜ ਕਰੋ: ਪੈਕੇਜ ਰਿਲੀਜ਼, ਆਰਕੀਟੈਕਚਰ, ਫਿੰਗਰਪ੍ਰਿੰਟ ਕਿਸੇ ਹੋਰ ਚੈਨਲ ਰਾਹੀਂ ਜਾਂਚੀ ਗਈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਕਿਹੜਾ ਮੁੜ ਲੋਡ ਜਾਂ ਮੁੜ ਸ਼ੁਰੂ ਕੀਤਾ। ਉਹੀ ਨੋਟ ਅਗਲੇ ਵਿਅਕਤੀ ਦੀ ਪਹਿਲੀ ਜਾਂਚ ਸਸਤੀ ਬਣਾਉਂਦਾ ਹੈ।