പുതിയ Ubuntu-യിൽ GlobalProtect-ന്റെ Linux ക്ലയന്റ് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ന്യായമായ ഊഹം ഇതാണ്: നിങ്ങളുടെ 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 അല്ലെങ്കിൽ /gateway എന്നതിൽ അവസാനിക്കുന്ന URL പോർട്ടൽ ഘട്ടം ഒഴിവാക്കുന്നു. നിരവധി ഗേറ്റ്വേകൾ വാഗ്ദാനം ചെയ്യുമ്പോൾ, --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 പതിപ്പിൽ പ്രവർത്തിപ്പിക്കുക, നിങ്ങളുടെ വർക്ക്സ്റ്റേഷൻ മുന്നോട്ട് പോയെങ്കിൽ വെർച്വൽ മെഷീനിൽ. ഇത് ഡെസ്ക്ടോപ്പ് സുരക്ഷിതമായി നിലനിർത്തുകയും പഴയ ആശ്രിതത്വം വീണ്ടും നിർമ്മിക്കാവുന്ന അതിരിനുള്ളിൽ വയ്ക്കുകയും ചെയ്യുന്നു.