ਵਾਜਬ ਅਨੁਮਾਨ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ GlobalProtect ਪੋਰਟਲ ਤੋਂ ਆਇਆ .deb ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ, ਜਾਂ ਵਿਕਰੇਤਾ ਨੇ ਖਰਾਬ ਬਿਲਡ ਜਾਰੀ ਕੀਤਾ ਹੈ। ਆਮ ਤੌਰ ਉੱਤੇ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ। ਵਿਕਰੇਤਾ ਦਾ Linux ਇੰਟਰਫੇਸ ਅਜੇ ਵੀ Qt5 WebKit ਨਾਲ ਜੁੜਿਆ ਹੈ, ਅਤੇ ਨਵੇਂ Ubuntu ਸੰਸਕਰਣ ਇਹ ਹੁਣ ਨਹੀਂ ਦਿੰਦੇ, ਇਸ ਲਈ ਪੈਕੇਜ ਅਜਿਹੀ ਲਾਇਬ੍ਰੇਰੀ ਮੰਗ ਰਿਹਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਵੰਡ ਨੇ ਜਾਣਬੁੱਝ ਕੇ ਹਟਾਈ ਹੈ। ਇਹ ਪੈਕੇਜਿੰਗ ਦੀ ਬੇਮੇਲ ਹੈ, ਖਰਾਬ ਡਾਊਨਲੋਡ ਨਹੀਂ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਦੁਪਹਿਰ ਪੈਕੇਜ ਥੋਪਣ ਵਿੱਚ ਲੰਘਾਓਗੇ ਜਾਂ ਦਸ ਮਿੰਟ ਦੂਜਾ ਕਲਾਇੰਟ ਚੁਣਨ ਵਿੱਚ।

.deb ਟੁੱਟਿਆ ਨਹੀਂ

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

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

ਨਿਰਭਰਤਾ ਨੂੰ ਥੋਪਣ ਦੀ ਬਜਾਏ ਪੁਸ਼ਟੀ ਕਰੋ

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

sudo apt install ./GlobalProtect_UI_deb-*.deb
apt-cache policy libqt5webkit5
apt-cache rdepends --installed libqt5webkit5

ਜੇ apt-cache policy ਕੋਈ ਉਮੀਦਵਾਰ ਨਹੀਂ ਦੱਸਦਾ, ਤਾਂ ਇਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਛੱਡੋ ਅਤੇ ਬਦਲ ਚੁਣਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਦਿਲਚਸਪ ਗੱਲ ਗਾਇਬ ਪੈਕੇਜ ਦਾ ਨਾਮ ਨਹੀਂ; ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਵਿਕਰੇਤਾ ਦਾ ਨਿਰਭਰਤਾ ਗ੍ਰਾਫ਼ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰਾਂ ਵੱਲੋਂ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ ਵੰਡਾਂ ਨਾਲ ਨਹੀਂ ਵਧਿਆ।

ਪੁਰਾਣੇ ਪੈਕੇਜ ਥੋਪਣਾ ਡੈਸਕਟਾਪ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ

ਜੋ ਹੱਲ ਘੁੰਮ ਰਿਹਾ ਹੈ ਉਹ ਹੈ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਤੋਂ ਖਿੱਚ ਲੈਣਾ। ਮੌਜੂਦਾ Ubuntu ਉੱਤੇ ਇਹ Qt5 ਦੇ ਛੋਟੇ ਸੰਸਕਰਣ ਦੇ ਟਕਰਾਅ ਉੱਤੇ ਜਾ ਕੇ ਰੁਕਦਾ ਹੈ: ਪੁਰਾਣੇ ਪੈਕੇਜ libqt5core5t64 ਨੂੰ ਪਿੱਛੇ ਖਿੱਚਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਸਥਾਪਿਤ KDE ਅਤੇ PyQt ਪੈਕੇਜ ਅਜਿਹਾ ABI ਸੰਸਕਰਣ ਮੰਗਣ ਲੱਗਦੇ ਹਨ ਜੋ ਘਟਾਈ ਗਈ ਲਾਇਬ੍ਰੇਰੀ ਹੁਣ ਨਹੀਂ ਦਿੰਦੀ। ਨਤੀਜਾ ਅੰਸ਼ਕ ਅੱਪਗ੍ਰੇਡ ਹੈ ਜੋ ਅਸੰਬੰਧਿਤ ਐਪਲੀਕੇਸ਼ਨ ਤੋੜ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਦੁਪਹਿਰ ਤੋਂ ਕਾਫ਼ੀ ਬੁਰਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।

ਇਹ ਨਤੀਜਾ ਉਮੀਦਯੋਗ ਹੈ, ਬਦਕਿਸਮਤੀ ਨਹੀਂ। Qt ਦੀਆਂ ਛੋਟੇ ਸੰਸਕਰਣਾਂ ਲਈ ABI ਉਮੀਦਾਂ ਸਖ਼ਤ ਹਨ, ਅਤੇ ਇੱਕ ਵੰਡ ਇੱਕ ਲਗਾਤਾਰ ਸਮੂਹ ਦਿੰਦੀ ਹੈ। ਦੂਜੇ ਸੰਸਕਰਣ ਤੋਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਮਿਲਾਉਣਾ ਨਿਸ਼ਾਨਾ ਸੁਧਾਰ ਨਹੀਂ; ਇਹ ਦੂਜਾ, ਘੱਟ ਨਿਯੰਤਰਿਤ ਅੱਪਗ੍ਰੇਡ ਹੈ।

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

openconnect ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਦਾ ਹੈ

OpenConnect GlobalProtect ਦਾ ਪ੍ਰੋਟੋਕੋਲ ਸਿੱਧਾ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨੋਟ ਦੋਵੇਂ ਸੱਦ ਅਤੇ ਦੋ ਸਰਵਰ ਇੰਟਰਫੇਸਾਂ ਵਿਚਕਾਰ ਵੰਡ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ। ਪੋਰਟਲ ਸੈਟਿੰਗਾਂ ਅਤੇ ਗੇਟਵੇ ਸੂਚੀ ਵੰਡਦਾ ਹੈ; ਗੇਟਵੇ ਟਨਲ ਖ਼ਤਮ ਕਰਦਾ ਹੈ:

openconnect --protocol=gp vpn.example.com
openconnect --protocol=gp --authgroup=staff vpn.example.com

ਜੇ ਪੋਰਟਲ ਉਹ ਗੇਟਵੇ ਛੱਡ ਦੇਵੇ ਜਿਸ ਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ, --usergroup=gateway ਜਾਂ ਅਜਿਹਾ URL ਜੋ /gateway ਉੱਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਪੋਰਟਲ ਕਦਮ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਕਈ ਗੇਟਵੇ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, --authgroup=NAME ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਚੁਣਦਾ ਹੈ। ਪ੍ਰਮਾਣਿਕਤਾ ਵਰਤੋਂਕਾਰ ਨਾਮ ਅਤੇ ਪਾਸਵਰਡ ਹੈ, ਲੋੜ ਅਨੁਸਾਰ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨਾਲ, ਅਤੇ SAML ਗੇਟਵੇ ਅਮਲ ਵਿੱਚ network-manager-openconnect ਰਾਹੀਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਹੱਥ ਨਾਲ ਲਿਖੀ ਕਮਾਂਡ ਲਾਈਨ ਦੀ ਬਜਾਏ।

ਸਖ਼ਤ posture ਨੀਤੀ ਵਾਲਾ ਗੇਟਵੇ ਟਨਲ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ HIP ਰਿਪੋਰਟ ਵੀ ਮੰਗ ਸਕਦਾ ਹੈ। OpenConnect ਇੱਕ ਬਣਾ ਕੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਗੇਟਵੇ ਅਜਿਹੀ ਸੂਚੀ ਮੰਗੇ ਜੋ ਉਹ ਨਹੀਂ ਬਣਾ ਸਕਦਾ, ਤਾਂ ਕੋਈ ਫਲੈਗ ਉਹ ਨੀਤੀ ਨਹੀਂ ਬਦਲਦਾ; ਇਹ ਸਰਵਰ ਪਾਸੇ ਦਾ ਫੈਸਲਾ ਹੈ।

ਟਨਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਜਾਣੋ ਕਿ openconnect ਕੀ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ

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

ip -4 addr show
ip route
resolvectl status

MTU ਵੱਖਰੀ ਨਜ਼ਰ ਦਾ ਹੱਕਦਾਰ ਹੈ। GlobalProtect ਦੀ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਹਮੇਸ਼ਾ ਸਿਫ਼ਰ MTU ਦੱਸਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਇੰਕੈਪਸੂਲੇਸ਼ਨ ਓਵਰਹੈੱਡ ਤੋਂ ਇੱਕ ਅੰਦਾਜ਼ਾ ਲਾਉਂਦਾ ਹੈ। ਵੱਡੇ ਸਥਾਨਾਂਤਰਣ ਜੋ ਅਟਕ ਜਾਂਦੇ ਹਨ ਜਦਕਿ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਲੰਘ ਜਾਂਦੀਆਂ ਹਨ, ਉਹੀ ਕਲਾਸਿਕ ਲੱਛਣ ਹੈ, ਅਤੇ ਇਲਾਜ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਸਪੱਸ਼ਟ MTU ਹੈ, ਮਾਰਗ ਖੋਜ ਬੰਦ ਕਰਨਾ ਨਹੀਂ।

IPv6 ਫਿਰ ਵੱਖਰਾ ਮਾਮਲਾ ਹੈ। PAN ਨੇ ਇਸ ਨੂੰ GlobalProtect 4.0 ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ, ਅਤੇ OpenConnect ਦਾ ਸਮਰਥਨ ਸੰਸਕਰਣ 9.0 ਤੋਂ ਪ੍ਰਯੋਗਾਤਮਕ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਪਤਾ ਪਰਿਵਾਰ IPv4 ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਟਨਲ ਉੱਪਰ ਆ ਗਿਆ। ਅਤੇ ਜੇ ਗੇਟਵੇ ਅਜਿਹੀ posture ਜਾਂਚ ਥੋਪੇ ਜੋ ਓਪਨ ਸੋਰਸ ਕਲਾਇੰਟ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਵਿਕਰੇਤਾ ਦਾ ਕਲਾਇੰਟ ਸਮਰਥਿਤ LTS ਸੰਸਕਰਣ ਉੱਤੇ ਚਲਾਓ, ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵਿੱਚ ਜੇ ਤੁਹਾਡਾ ਵਰਕਸਟੇਸ਼ਨ ਅੱਗੇ ਵਧ ਚੁੱਕਾ ਹੈ। ਇਹ ਡੈਸਕਟਾਪ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੀ ਨਿਰਭਰਤਾ ਨੂੰ ਅਜਿਹੀ ਹੱਦ ਅੰਦਰ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮੁੜ ਬਣਾ ਸਕਦੇ ਹੋ।

ਸੰਬੰਧਿਤ ਲੇਖ