Juniper કે Pulse ગેટવે: કયો OpenConnect પ્રોટોકોલ વાપરવો

OpenConnect માટે પ્રોટોકોલ પસંદ કરવો એ મેળ બેસાડવાની કસરત છે, બ્રાન્ડ શોધ નહીં. લોગિન પાના પર Juniper કહેતું ગેટવે Network Connect, Pulse અથવા બંને આપી શકે છે, અને ક્લાયન્ટનું મૂળભૂત મૂલ્ય એમાંથી કોઈ નથી. અનુમાન કરવાથી નિષ્ફળ લોગિન થાય છે અને તેનાથી ખરાબ, એક સપોર્ટ થ્રેડ જે પ્રોટોકોલની અસંગતિ માટે ક્રેડેન્શિયલને દોષ આપે છે. પ્રોફાઇલમાં હોસ્ટનામ લખતા પહેલા સેવાની ખાતરી કરો.

OpenConnect જૂના પ્રોટોકોલને nc અને નવાને pulse કહે છે, અને બંને એક જ બાઈનરીમાં રહે છે. તમે પસંદ કરેલો ફ્લેગ લોગિન આદાન-પ્રદાન બદલે છે, સફળ કનેક્શન પછીના રાઉટિંગને નહીં.

બે પ્રોટોકોલ નામો એક ઉત્પાદન ઇતિહાસ વહેંચે છે

Juniper નું Network Connect અને પછીનું Pulse Secure ક્લાયન્ટ અલગ પ્રોટોકોલ છે જે એક ઉપકરણ પરિવારે સમય જતાં આપ્યા છે. OpenConnect એ પ્રથમ માટે nc હેન્ડલર અને બીજા માટે pulse હેન્ડલર વિકસાવ્યું. આ અલગ કોડ પથ અને અલગ વિનંતી ફોર્મેટ છે, તેથી એકમાં સપોર્ટ હોવાથી બીજા વિશે કંઈ ખબર પડતી નથી.

લોગિન સંવાદમાં તફાવત તરત દેખાય છે: એન્ડપોઇન્ટ, ફોર્મ ફીલ્ડ અને ક્લાયન્ટ નામંજૂર કરેલા બીજા પરિબળની જાણ કેવી રીતે કરે છે, તે બંને હેન્ડલર વચ્ચે અલગ પડે છે.

કમાન્ડ લાઇને પસંદગી એક શબ્દનો ફેરફાર છે: Network Connect માટે openconnect --protocol=nc vpn.example.com, અથવા Pulse માટે openconnect --protocol=pulse vpn.example.com. બંને પ્રયાસો વાસ્તવિક કનેક્શન પ્રયાસો છે જે રાઉટ અને DNS ફરી ગોઠવી શકે છે, તેથી તેમને જાણી જોઈને ચલાવો. પ્રોટોકોલ ભૂલ ટાળવા માટે ક્યારેય કમાન્ડ લાઇન પર પાસવર્ડ ન મૂકો અથવા પ્રમાણપત્ર ચકાસણી બંધ ન કરો, કારણ કે તે અસંગતિને ઠીક કરવાને બદલે છુપાવે છે. ક્લાયન્ટ શું મોકલે છે તે જોવું હોય તો --dump-http-traffic આદાન-પ્રદાન છાપે છે, જે સામાન્ય રીતે ગેટવે જે હેન્ડલરની અપેક્ષા રાખે છે તે ઓળખે છે.

ગેટવે જે આપે છે તેની સાથે પ્રોટોકોલ મેળવો

ઉપકરણ ફક્ત તે પ્રોટોકોલનો જ જવાબ આપે છે જેના માટે તે ગોઠવાયેલું છે. ફક્ત Pulse સેવા માન્ય ક્રેડેન્શિયલ સાથે પણ nc લોગિન નકારે છે, અને જૂની Network Connect સેવા પાસે જવાબ આપવા pulse એન્ડપોઇન્ટ નથી. એડમિનિસ્ટ્રેટરને પૂછો કે કયું સક્ષમ છે અને તેઓ કયા ક્લાયન્ટને સમર્થન આપે છે. નામ બદલાયેલું ઉપકરણ, જૂનું વિકિ પાનું અને પરિચિત વેબ પોર્ટલ એ બધા નબળા પુરાવા છે.

પ્રોટોકોલ જાણ્યા પછી આસપાસની જરૂરિયાતોની ખાતરી કરો: પ્રમાણપત્ર અથવા ટોકન પ્રમાણીકરણ, auth જૂથની પસંદગી અને કોઈપણ એન્ડપોઇન્ટ અનુપાલન ચકાસણી. આ નક્કી કરે છે કે કમાન્ડ-લાઇન ક્લાયન્ટ લોગિન પૂર્ણ કરી શકે છે કે નહીં.

પ્રમાણીકરણ પ્રોટોકોલ પહેલાં પ્રશ્નનો ઉકેલ લાવી શકે છે

એક ડિપ્લોયમેન્ટ ક્લાયન્ટ પ્રમાણપત્ર, બ્રાઉઝર દ્વારા SAML રાઉન્ડ ટ્રિપ, અથવા એક્સેસ આપતા પહેલા મશીનની તપાસ કરતું હોસ્ટ ચેકર માંગી શકે છે. OpenConnect નું pulse હેન્ડલર આ પ્રવાહોમાંથી કેટલાક માટે સુસંગતતાની મર્યાદા દસ્તાવેજ કરે છે, અને nc હેન્ડલરની પોતાની ખામીઓ છે. બ્રાઉઝરમાં કામ કરતો પાસવર્ડ સાબિત કરે છે કે ખાતું માન્ય છે; તે સાબિત કરતું નથી કે કોઈપણ CLI અથવા ડેસ્કટોપ પ્લગઇન એ જ ક્રમ પૂર્ણ કરી શકે છે. જ્યારે હોસ્ટ ચેકર સંડોવાયેલું હોય, ત્યારે ક્લાયન્ટને એડમિનિસ્ટ્રેટર દ્વારા આપેલી રેપર સ્ક્રિપ્ટની જરૂર હોય છે. તેના વિના લોગિન પહેલા જવાબ પછી અટકી જાય છે અને પ્રોટોકોલ નિષ્ફળતા જેવું લાગે છે, જ્યારે તે વાસ્તવમાં ખૂટતું અનુપાલન પગલું છે.

auth જૂથની પસંદગી બીજું સામાન્ય અડચણ છે, કારણ કે ઘણા જૂથોવાળું ગેટવે અપેક્ષા રાખે છે કે ક્લાયન્ટ એકનું નામ આપે.

કમાન્ડ લાઇન પર --authgroup="Employees" તે પસંદગી આપે છે, અને તેને છોડી દેવાથી સત્ર ડિફોલ્ટ જૂથમાં પડી શકે છે જે ખાતું નકારે છે. પ્રમાણપત્રો સાથે --certificate ક્લાયન્ટ પ્રમાણપત્ર અને કી તરફ નિર્દેશ કરે છે, અને ગેટવે પછી પણ ટોકન માંગી શકે છે. તેની આસપાસ કંઈપણ ઓટોમેટ કરતા પહેલા વિગતવાર આઉટપુટ સાથે આખો ક્રમ એક વાર પરીક્ષણ કરો.

જ્યારે ડેસ્કટોપ ફ્રન્ટએન્ડ પસંદગી વ્યક્ત કરી શકતું નથી

ગ્રાફિકલ ફ્રન્ટએન્ડ પોતાના ફીચર સેટ ધરાવે છે, અને જૂનું પ્લગઇન તમને જોઈતા પ્રોટોકોલ પહેલાંનું હોઈ શકે છે. NetworkManager નું OpenConnect એકીકરણ પસંદગી તેના કનેક્શન ડેટામાં સંગ્રહે છે, તેથી nmcli connection modify "Office VPN" vpn.data "protocol=pulse" એ સેટ કરી શકે છે જે એડિટર બતાવતું નથી. ફેરફાર અમલમાં આવ્યો એમ માનતા પહેલા ચકાસો કે સ્થાપિત પ્લગઇન આવૃત્તિ તે કીને સમર્થન આપે છે.

જો મેનુ ફક્ત PPTP અથવા L2TP આપે છે, તો એક પસંદ કરવાથી Pulse સેવા તે પ્રોટોકોલમાં ન ફેરવાય. મેનુ સંજોગવશાત જે સૂચિબદ્ધ કરે તેના પર જવાને બદલે મંજૂર એકીકરણ સ્થાપિત કરો.

લોગિન હજી નિષ્ફળ જાય ત્યારે શું નોંધવું

ચાર વસ્તુઓ નોંધો: તમે પસંદ કરેલો પ્રોટોકોલ, ક્લાયન્ટ અને પ્લગઇન આવૃત્તિઓ, અપેક્ષિત પ્રમાણીકરણ પ્રવાહ, અને ટાઇમઆઉટને બદલે સ્ટેટસ કોડ સાથે પાછી આવેલી પ્રથમ ભૂલ. આ સમૂહ ખોટા હેન્ડલરને ખૂટતા પ્રમાણપત્ર, નકારેલા auth જૂથ અથવા અવરોધિત અનુપાલન ચકાસણીથી અલગ પાડે છે. વિગતવાર આઉટપુટ એ જ કારણસર રાખવા લાયક છે, કારણ કે તે ફક્ત લક્ષણ નહીં, નિષ્ફળ ગયેલી વિનંતી બતાવે છે.

સફળ થાય ત્યારે કામ કરતો કમાન્ડ અથવા પ્રોફાઇલ ગેટવેના નામ પાસે રાખો. નહીં તો આગળ જોડાતી વ્યક્તિ એ જ બ્રાન્ડ-વિરુદ્ધ-પ્રોટોકોલ અનુમાન પુનરાવર્તિત કરશે.