Check Point કે Nortel સામે vpnc: તે કેમ અટકી જાય છે

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

પ્રોફાઇલનું બીજું ક્ષેત્ર સંપાદિત કરતા પહેલા ઉત્પાદન ઓળખો.

નિષ્ફળતા ખોટા ઓળખપત્ર જેવી લાગે છે

vpnc UDP 500 પર IKE મોકલીને શરૂ કરે છે અને, જો NAT ટ્રાવર્સલ ઓફર થાય તો, UDP 4500 પર. જે ગેટવે IPsecને બદલે SSL સમાપ્ત કરે છે તે બંનેમાંથી કોઈને જવાબ આપતું નથી, તેથી ક્લાઇન્ટ ફરી પ્રયાસ કરે છે અને અંતે સામાન્ય ભૂલ સાથે હાર માની લે છે. જો એ જ ખાતું નાની સહાયક એપ્લિકેશન લોડ કરતા બ્રાઉઝર પોર્ટલ દ્વારા કામ કરે, તો તે મજબૂત સંકેત છે કે ટનલ SSL આધારિત છે અને ક્લાઇન્ટ ખોટો પ્રશ્ન પૂછી રહ્યું છે.

અહીં નિષ્ફળ પ્રયાસ વપરાશકર્તા ખાતા વિશે કંઈ કહેતું નથી, કારણ કે ગેટવે સમક્ષ કોઈ ઓળખપત્ર રજૂ કરવામાં આવ્યું જ નથી.

ગેટવે કયો પ્રોટોકોલ ઓફર કરે છે તે તપાસો

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

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

લોગિન પૃષ્ઠ પર રીડાયરેક્ટ સાથે ખુલ્લું 443 અને 500 તથા 4500 પર સન્નાટો SSL VPN તરફ ઇશારો કરે છે. 443 પર સર્વ કરાયેલા પ્રમાણપત્ર સાથે 500 અને 4500 ખુલ્લા હોય તો તે IPsec ગેટવે સૂચવે છે જે વેબ ફ્રન્ટએન્ડ પણ ચલાવે છે, અને vpnc તે જ કિસ્સા માટે બનાવાયું હતું.

Check Pointનું SSL Network Extender અને Nortelનું Aventail ક્લાઇન્ટ બંને બીજી શ્રેણીમાં આવે છે, અને બંન્નેમાંથી કોઈ IKEv1 જૂથ રહસ્ય સ્વીકારતું નથી.

vpnc પ્રોફાઇલ શું વ્યક્ત કરી શકે છે અને શું નહીં

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

તેથી સાઇફર યાદી પહોળી કરવી કે પ્રમાણપત્ર તપાસ બંધ કરવી આ પ્રકારની નિષ્ફળતા ક્યારેય સુધારતી નથી. એ ફેરફારો એવી વાટાઘાટને નબળી પાડે છે જે ગેટવે સાંભળતું નથી.

ગેટવે સાથે મેળ ખાતું ક્લાઇન્ટ પસંદ કરવું

Check Point ગેટવે માટે તે ગેટવે આવૃત્તિ માટે બનેલું SNX પેકેજ વાપરો, જે વેન્ડર તેના રિમોટ એક્સેસ દસ્તાવેજીકરણ સાથે પ્રકાશિત કરે છે. જૂની SNX બિલ્ડ વર્તમાન ડિસ્ટ્રિબ્યુશન પર વારંવાર નિષ્ફળ જાય છે કારણ કે તે 32-bit લાઇબ્રેરી ધારે છે જે હવે ઇન્સ્ટોલ નથી, અને ત્યજેલા પેકેજને પેચ કરવું સામાન્ય રીતે સમર્થિત પ્લેટફોર્મ પર સમર્થિત ક્લાઇન્ટ ચલાવવા કરતાં ખરાબ છે.

Aventail ક્લાઇન્ટે ઘણા સમય પહેલા સમર્થન ગુમાવ્યું હતું. જ્યાં આવું ગેટવે હજી સેવામાં છે, ત્યાં વાસ્તવિક વિકલ્પો સંસ્થા સક્ષમ કરે તો બ્રાઉઝર પોર્ટલ, અથવા સમર્થિત ઓપરેટિંગ સિસ્ટમ પર વેન્ડરનું સમર્થિત ક્લાઇન્ટ છે.

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