નવા 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 અથવા એવું 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 સંસ્કરણ પર ચલાવો, વર્ચ્યુઅલ મશીનમાં જો તમારું વર્કસ્ટેશન આગળ વધી ગયું હોય. આ ડેસ્કટોપ અકબંધ રાખે છે અને જૂની નિર્ભરતાને એવી હદમાં રાખે છે જે તમે ફરી બનાવી શકો.