Android IKEv2 ട്രസ്റ്റ് പിശക്: റൂട്ട് അല്ല, ഇന്റർമീഡിയറ്റ് CA അയയ്ക്കുക
ലഭിച്ച ചെയിൻ നേരത്തെ അവസാനിക്കുന്നതിനാൽ ഫോൺ ഗേറ്റ്‌വേയെ നിരസിക്കുന്നു. ഇന്റർമീഡിയറ്റ് അയയ്ക്കണോ, ഐഡന്റിറ്റി ശരിയാക്കണോ, കീ തരം മാറ്റണോ എന്ന് തീരുമാനിക്കുക.
ഫോൺ ബന്ധിപ്പിക്കാൻ വിസമ്മതിച്ച് No trusted RSA public key found for vpn.example.net പ്രിന്റ് ചെയ്യുന്നു, അതേസമയം അതേ ഗേറ്റ്‌വേ സർട്ടിഫിക്കറ്റ് അതേ നെറ്റ്‌വർക്കിലെ ലാപ്‌ടോപ്പിൽ പ്രവർത്തിക്കുന്നു. സർട്ടിഫിക്കറ്റ് വീണ്ടും ഇഷ്യൂ ചെയ്യുക എന്നത് പ്രലോഭനീയമായ നീക്കമാണ്. അതിന് മുൻപ്, മൂന്ന് പരാജയങ്ങളിൽ ഏതാണ് നിങ്ങൾക്കുള്ളതെന്ന് കണ്ടെത്തുക, കാരണം അവയിൽ ഒന്ന് മാത്രമാണ് സർട്ടിഫിക്കറ്റിന്റെ ഉള്ളടക്കത്തെക്കുറിച്ച്. സന്ദേശം അപൂർണ്ണമായ ചെയിൻ, ഐഡന്റിറ്റി പൊരുത്തക്കേട്, പിന്തുണയ്ക്കാത്ത കീ അല്ലെങ്കിൽ ഒപ്പ് എന്നിവ ഉൾക്കൊള്ളുന്നു, ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരമുണ്ട്.
ഒരു സന്ദേശത്തിന് പിന്നിലെ മൂന്ന് പരാജയങ്ങൾ
Android ഗേറ്റ്‌വേ സർട്ടിഫിക്കറ്റിൽ നിന്ന് VPN പ്രൊഫൈലിൽ തിരഞ്ഞെടുത്ത CA വരെ ഒരു ചെയിൻ നിർമ്മിക്കുന്നു, തുടർന്ന് സർവർ നാമം പ്രൊഫൈലുമായി താരതമ്യം ചെയ്യുന്നു. അറിയിപ്പ് ഘട്ടമല്ല, ഫലമാണ് അറിയിക്കുന്നത്. ട്രസ്റ്റ് പരാജയം എന്നാൽ കൈമാറ്റത്തിൽ നൽകിയ സർട്ടിഫിക്കറ്റുകളിൽ നിന്ന് ചെയിൻ പൂർത്തിയാക്കാൻ കഴിഞ്ഞില്ല എന്നതാണ്; ഐഡന്റിറ്റി പരാജയം എന്നാൽ ചെയിൻ സാധൂകരിച്ചു, പക്ഷേ നാമം പൊരുത്തപ്പെട്ടില്ല എന്നതാണ്; അൽഗോരിതം പരാജയം എന്നാൽ ഉപകരണമോ പ്രൊഫൈലോ കീ തരമോ ഒപ്പോ സ്വീകരിക്കുന്നില്ല എന്നതാണ്.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
പരിഹാരങ്ങൾ ക്രമത്തിൽ പരീക്ഷിക്കുന്നതിനുപകരം തെളിവുകൊണ്ട് തീരുമാനിക്കുക. ഡീമണിനെതിരെ ലോഗ് ലെവൽ 2-ൽ ഒരു ശ്രമം നിങ്ങൾ ഏത് വരിയിലാണെന്ന് പറയും, ഒരിക്കലും തെറ്റായിരുന്നില്ലാത്ത സർട്ടിഫിക്കറ്റ് വീണ്ടും ഇഷ്യൂ ചെയ്യുന്നതിനേക്കാൾ കുറഞ്ഞ ചെലവാണ്.
ആദ്യം തീരുമാനിക്കുക: മുഴുവൻ ചെയിനും എത്തിയോ?
strongSwan ആ കണക്ഷനായി കോൺഫിഗർ ചെയ്ത സർട്ടിഫിക്കറ്റ് അയയ്ക്കുന്നു, ഇന്റർമീഡിയറ്റുകൾ വേറിട്ട ക്രെഡൻഷ്യലുകളാണ്. ഡീമണിന് അവ പേലോഡിൽ ഇടാൻ അവ CA സർട്ടിഫിക്കറ്റുകളായി ലോഡ് ചെയ്യണം, അതിനാൽ സർവർ സർട്ടിഫിക്കറ്റ് ഒരു ഇന്റർമീഡിയറ്റ് ഒപ്പിടുന്നതും, റൂട്ട് ട്രസ്റ്റ് ആങ്കറും, ഇന്റർമീഡിയറ്റ് CA-യുടെ ബിൽഡ് ഡയറക്ടറിയിൽ മാത്രം ജീവിക്കുന്നതുമായ ക്രമീകരണം കൃത്യമായി ഈ പരാജയം ഉണ്ടാക്കുന്നു: വയറിൽ ലീഫ് മാത്രം, ഫോണിൽ ചെയിൻ നേരത്തെ അവസാനിക്കുന്നു.
swanctl വിന്യാസത്തിൽ swanctl --list-certs ഉപയോഗിച്ചോ, പഴയ starter-ൽ ipsec listcerts ഉപയോഗിച്ചോ ഡീമൺ എന്ത് വഹിക്കുന്നുവെന്ന് പരിശോധിക്കുക. ഇന്റർമീഡിയറ്റ് അതിന് മുകളിൽ റൂട്ടുള്ള CA സർട്ടിഫിക്കറ്റായി കാണണം. അത് കാണുന്നില്ലെങ്കിൽ ഒരു ക്ലയന്റ് ഓപ്ഷനും സഹായിക്കില്ല; അത് ഉണ്ടെങ്കിൽ അടുത്ത ചോദ്യത്തിലേക്ക് പോകുക.
തുടർന്ന് അത് അയയ്ക്കുമോ എന്ന് പരിശോധിക്കുക. swanctl.conf റഫറൻസ് send_cert രേഖപ്പെടുത്തുന്നു, അതിന്റെ സ്ഥിരസ്ഥിതി ifasked പിയർ ആവശ്യപ്പെട്ടാൽ മാത്രം സർട്ടിഫിക്കറ്റുകൾ അയയ്ക്കുന്നു; always എപ്പോഴും അയയ്ക്കുന്നു. പഴയ തത്തുല്യം ipsec.conf-ൽ leftsendcert=always ആണ്. ആ ക്രമീകരണം അയയ്ക്കലിനെ നിയന്ത്രിക്കുന്നു, ലഭ്യതയെയല്ല, അതിനാൽ ഡീമൺ ഒരിക്കലും ലോഡ് ചെയ്യാത്ത ഇന്റർമീഡിയറ്റിന് അത് പകരം വയ്ക്കാൻ കഴിയില്ല.
ചെയിൻ ചെറുതാണെങ്കിൽ, ഡീമൺ നോക്കുന്നിടത്ത് ഇന്റർമീഡിയറ്റ് ലോഡ് ചെയ്യുക
ഇന്റർമീഡിയറ്റ് ലീഫിന് അടുത്തല്ല, CA ഡയറക്ടറിയിൽ ഇടുക: ipsec.conf സെറ്റപ്പിന് /etc/ipsec.d/cacerts, swanctl-ന് /etc/swanctl/x509ca, അല്ലെങ്കിൽ നിങ്ങളുടെ പാക്കേജ് മാറ്റിസ്ഥാപിക്കുന്ന പാത. കോൺഫിഗറേഷൻ വീണ്ടും ലോഡ് ചെയ്ത് സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും ലിസ്റ്റ് ചെയ്യുക. ചില പതിപ്പുകൾ ലീഫ് ഫയലിനുള്ളിൽ ചെയിൻ അടങ്ങുന്ന ബണ്ടിലും അയയ്ക്കും, എന്നാൽ CA ഡയറക്ടറി പതിപ്പുകളിലും പാക്കേജുകളിലും കൈമാറാവുന്ന ക്രമീകരണമാണ്.
ക്ലയന്റ് ഭാഗത്തുനിന്നും പരിശോധിക്കുക. ഫോൺ കൈമാറ്റം കൊണ്ടുവന്നത് മാത്രമേ കാണുന്നുള്ളൂ, അതിനാൽ ലോഗ് ലെവൽ 2-ലെ ഡീമൺ ലോഗ് അയച്ച സർട്ടിഫിക്കറ്റുകളിൽ ഇന്റർമീഡിയറ്റ് കാണിക്കണം. ലോഗ് അത് കാണിച്ചിട്ടും ഫോൺ പരാജയപ്പെടുന്നെങ്കിൽ, നിങ്ങൾ പട്ടികയുടെ മറ്റൊരു വരിയിലാണ്, CA ഫയലുകൾ ക്രമീകരിച്ചുകൊണ്ടിരുന്നാൽ ഫലം മാറില്ല.
ചെയിൻ പൂർണ്ണമാണെങ്കിൽ, സർട്ടിഫിക്കറ്റുകൾ തിരുത്തുന്നത് നിർത്തുക
ഐഡന്റിറ്റി പരാജയം എന്നാൽ VPN പ്രൊഫൈലിലെ നാമവും സർട്ടിഫിക്കറ്റിലെ നാമവും തമ്മിലുള്ള പൊരുത്തക്കേടാണ്. Android നിങ്ങൾ കോൺഫിഗർ ചെയ്ത സർവർ ഐഡന്റിറ്റിയെ അത് സാധൂകരിച്ച സർട്ടിഫിക്കറ്റുമായി താരതമ്യം ചെയ്യുന്നു, അതിനാൽ സർട്ടിഫിക്കറ്റ് ഹോസ്റ്റ്നാമം പേരിടുമ്പോൾ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന പ്രൊഫൈൽ, അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് ഉൾക്കൊള്ളാത്ത ഹോസ്റ്റ്നാമം പേരിടുന്ന പ്രൊഫൈൽ, വിജയകരമായ ചെയിൻ സാധൂകരണത്തിന് ശേഷം പരാജയപ്പെടുന്നു. തെറ്റായ വശം ശരിയാക്കുക, ഏതെങ്കിലും മാറുമ്പോൾ പ്രൊഫൈലും സർട്ടിഫിക്കറ്റും ഒത്തുനിർത്തുക.
അൽഗോരിതം പരാജയം സാധുവായ ചെയിനും പൊരുത്തപ്പെടുന്ന നാമവുമായി പ്രത്യക്ഷപ്പെടുന്നു. Android പതിപ്പുകൾ ഏത് കീ തരങ്ങളും ഒപ്പ് സ്കീമകളും സ്വീകരിക്കുന്നു എന്നതിൽ വ്യത്യാസപ്പെടുന്നു, പ്രൊഫൈൽ തരം തന്നെ ഓപ്ഷനുകൾ പരിമിതപ്പെടുത്തുന്നു. ഗേറ്റ്‌വേ പഴയതോ അസാധാരണമായതോ ആയ സംയോജനം ഉപയോഗിക്കുന്നെങ്കിൽ, സർട്ടിഫിക്കറ്റ് കേടായതാണെന്ന് അനുമാനിക്കുന്നതിന് മുൻപ് ഉപകരണം പിന്തുണയ്ക്കുന്നതുമായി താരതമ്യം ചെയ്യുക. ഡീമൺ ലോഗ് ട്രസ്റ്റ് കേസിലേക്കാൾ ഹാൻഡ്‌ഷേക്ക് മുന്നോട്ട് പോകുന്നത് കാണിക്കും, അതാണ് ചെയിൻ ഇനി പ്രശ്നമല്ല എന്ന സൂചന.
ഇന്റർമീഡിയറ്റ് ഫോണിൽ ഉപയോക്തൃ റൂട്ടായി ഇൻസ്റ്റാൾ ചെയ്യരുത്
കാണാത്ത ഇന്റർമീഡിയറ്റ് ഫോണിൽ ഉപയോക്തൃ സർട്ടിഫിക്കറ്റായി ഇൻസ്റ്റാൾ ചെയ്യുന്നത് മുന്നറിയിപ്പ് അപ്രത്യക്ഷമാക്കുകയും ഉപയോക്തൃ-ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾ സ്വീകരിക്കുന്ന എല്ലാ ആപ്പിനും ഫോണിന്റെ ട്രസ്റ്റ് മോഡൽ മാറ്റുകയും ചെയ്യുന്നു. അടുത്ത ക്ലയന്റിനെ ബാധിക്കുന്ന ഡെലിവറി ബഗ്ഗും അത് മറയ്ക്കുന്നു, ഭാവിയിലെ എല്ലാ ഉപകരണങ്ങൾക്കും ഗേറ്റ്‌വേ അപൂർണ്ണ ചെയിൻ അയയ്ക്കാൻ ഇടയാക്കുന്നു. ശാശ്വത പരിഹാരം സർവറിൽ, ഒരിക്കൽ, എല്ലാ ക്ലയന്റുകൾക്കുമാണ്.
മാറ്റ രേഖയിൽ മൂന്ന് തീരുമാനങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക: ഏത് സർട്ടിഫിക്കറ്റുകൾ അയച്ചു, ഏത് ഐഡന്റിറ്റി താരതമ്യം ചെയ്തു, ഏത് അൽഗോരിതം ചർച്ച ചെയ്തു. എപ്പോഴും പൂർണ്ണ ചെയിൻ അയയ്ക്കുന്ന ഗേറ്റ്‌വേ, സർട്ടിഫിക്കറ്റ് ശരിയായി പേരിടുന്ന പ്രൊഫൈൽ, ഫ്ലീറ്റ് പിന്തുണയ്ക്കുന്ന കീ തരം — ഇവ മൂന്ന് ചെറിയ വസ്തുതകളാണ്, ഈ പരാജയം മുഴുവൻ അത്രമാത്രം.