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 പ്രൊഫൈൽ ഉണ്ടോ എന്നിവ ചോദിക്കുക. ഉണ്ടെങ്കിൽ, ഗ്രൂപ്പ് ഐഡന്റിഫയറും ഗ്രൂപ്പ് രഹസ്യവും വെവ്വേറെ ഇനങ്ങളായി അഭ്യർത്ഥിക്കുക, കാരണം അവ ഉപയോക്തൃ പാസ്‌വേഡല്ല, പരസ്പരം മാറിപ്പോയ ജോടി പരാജയപ്പെട്ട ടണലിന്റെ മറ്റൊരു സാധാരണ കാരണമാണ്. കണക്ഷൻ ഒടുവിൽ വിജയിക്കുമ്പോൾ, ഏത് പ്രോട്ടോക്കോളാണ് ചർച്ച ചെയ്തതെന്ന് രേഖപ്പെടുത്തുക, അടുത്ത വ്യക്തി അതേ ഊഹം ആവർത്തിക്കാതെ വസ്തുതയിൽ നിന്ന് തുടങ്ങാൻ.