strongSwan EAP: IKE ഐഡന്റിറ്റിയും പ്രതീക്ഷിച്ച AAA നാമവും

IKEv2-ന് മുകളിലുള്ള EAP പ്രാമാണീകരണം ഒരു കണക്ഷനിൽ രണ്ട് വ്യത്യസ്ത സെർവർ നാമങ്ങൾ സാധൂകരിക്കാൻ ക്ലയന്റിനോട് ആവശ്യപ്പെടാം. IKE അവസാനിപ്പിക്കുന്ന ഗേറ്റ്‌വേ ഒരു ഐഡന്റിറ്റി അവതരിപ്പിക്കുന്നു, ആന്തരിക TLS കൈമാറ്റം അവസാനിപ്പിക്കുന്ന EAP ബാക്കെൻഡ് മറ്റൊന്ന് അവതരിപ്പിച്ചേക്കാം. strongSwan-ൽ ഇവ വ്യത്യസ്ത കോൺഫിഗറേഷൻ ബ്ലോക്കുകളിൽ കഴിയുന്നു, തെറ്റായ ബ്ലോക്കിൽ പേര് ഇട്ടാൽ സർട്ടിഫിക്കറ്റ് പ്രശ്നം പോലെ തോന്നുന്ന പരാജയം ഉണ്ടാകും. ഏത് സാധൂകരണമാണ് പരാജയപ്പെട്ടതെന്ന് വായിക്കുന്നതാണ് ഏത് ബ്ലോക്ക് തിരുത്തണമെന്ന് പറയുന്നത്.

ഒരു കണക്ഷൻ, രണ്ട് സെർവർ ഐഡന്റിറ്റികൾ

ആദ്യ ഐഡന്റിറ്റി IKE കൈമാറ്റത്തിന്റേതാണ്. ക്ലയന്റ് ഒരു വിലാസം ഡയൽ ചെയ്യുന്നു, എതിരാളി ഒരു നിർദിഷ്ട ഐഡന്റിറ്റി, സാധാരണയായി ഗേറ്റ്‌വേ സർട്ടിഫിക്കറ്റിലെ പേര്, തെളിയിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു.

രണ്ടാമത്തേത് EAP-ന്റേതാണ്. PEAP അല്ലെങ്കിൽ TTLS-ൽ, ക്ലയന്റ് IKE SA-യ്ക്കുള്ളിൽ പ്രാമാണീകരണ സെർവറിലേക്ക് TLS ടണൽ നിർമ്മിക്കുന്നു, ആ ആന്തരിക സെർവർ സ്വന്തം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു. ബാക്കെൻഡ് വേറിട്ട ഹോസ്റ്റാണെങ്കിൽ, അതിന്റെ പേര് ഗേറ്റ്‌വേയുടെ പേരിൽ നിന്ന് വ്യത്യസ്തമാണ്. ആദ്യ പേര് മാത്രം പരിശോധിക്കുന്ന ക്ലയന്റ് രണ്ടാമത്തേത് പറയുന്നതെല്ലാം സ്വീകരിക്കുന്നു. രണ്ടിടത്തും ഒരേ പേര് കോൺഫിഗർ ചെയ്ത ക്ലയന്റ്, ആ രണ്ടും യഥാർത്ഥത്തിൽ വ്യത്യാസപ്പെടുമ്പോൾ പരാജയപ്പെടുന്നു.

രണ്ട് പേരുകളും ഓപ്പറേറ്ററുടെ കോൺഫിഗറേഷനിൽ നിന്നാണ് വരുന്നത്, പിശക് ഇല്ലാതാക്കുന്ന സർട്ടിഫിക്കറ്റിൽ നിന്നല്ല. ഓപ്പറേറ്ററോട് വിന്യാസ വിശദാംശങ്ങൾ ചോദിക്കുന്നത് രണ്ട് ഹോസ്റ്റ് നാമങ്ങൾ ഊഹിക്കുന്നതിനേക്കാൾ വേഗതയുള്ളതാണ്.

ഏത് ഫീൽഡ് ഏത് പാളിയുടേതാണ്

swanctl-ൽ വിലാസവും IKE ഐഡന്റിറ്റിയും വേറിട്ട ക്രമീകരണങ്ങളാണ്, EAP ഐഡന്റിറ്റി മൂന്നാമത്തേതാണ്.

റിമോട്ട് വിലാസം പാക്കറ്റുകൾ എവിടെ പോകുന്നുവെന്ന് തിരഞ്ഞെടുക്കുന്നു, റിമോട്ട് ഐഡന്റിറ്റി എതിരാളി എന്ത് തെളിയിക്കണമെന്ന് പറയുന്നു. EAP പ്രതീക്ഷ local ബ്ലോക്കിന് താഴെ എഴുതുന്നു, കാരണം അത് എതിരാളിയുടെ IKE സ്വഭാവമല്ല, ഈ ക്ലയന്റിന്റെ EAP കൈമാറ്റമാണ് വിവരിക്കുന്നത്. ഈ സ്ഥാനമാണ് ആളുകൾ തെറ്റായി വായിക്കുന്നത്. പേര് സെർവറിനെ വിവരിക്കുമ്പോൾ ക്ലയന്റിന്റെ കോൺഫിഗറേഷനിൽ നിൽക്കുന്നു, അതുകൊണ്ടാണ് അത് തെറ്റായ സ്ഥലത്ത് എന്ന് തോന്നുന്നത്.

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

ഈ ഭാഗം പൂർണ്ണ കണക്ഷനല്ല; വിശ്വാസ വസ്തുക്കൾ, ക്രെഡൻഷ്യലുകൾ, ചൈൽഡ് കണക്ഷൻ നയങ്ങൾ എന്നിവ ഇപ്പോഴും ഉണ്ടായിരിക്കണം. ഇത് അക്ഷരാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന ഫയലിലേക്ക് പകർത്തിയാൽ നിങ്ങൾക്ക് ഇപ്പോഴും ആവശ്യമായ ക്രമീകരണങ്ങൾ മാറ്റിസ്ഥാപിക്കപ്പെടും.

aaa_id local-ന് കീഴിൽ ജീവിക്കുന്നത് എന്തുകൊണ്ട്

പ്രാമാണീകരണ സമയത്ത് ഈ ഭാഗം എന്ത് ചെയ്യുന്നുവെന്ന് local ബ്ലോക്ക് വിവരിക്കുന്നു, അത് ഉപയോഗിക്കുന്ന രീതിയും ആ രീതിക്കായി മറുഭാഗത്ത് നിന്ന് പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റിയും ഉൾപ്പെടെ. AAA സെർവർ അതേ യന്ത്രത്തിൽ പ്രവർത്തിക്കുന്നു എന്ന് അതിൽ ഒന്നും പറയുന്നില്ല.

സ്ഥിരസ്ഥിതി മൂല്യം കെണി കൂർമ്മമാക്കുന്നു. വ്യക്തമായ മൂല്യം സജ്ജമാക്കിയിട്ടില്ലെങ്കിൽ, പ്രതീക്ഷിച്ച AAA ഐഡന്റിറ്റി റിമോട്ട് ഐഡന്റിറ്റിയെ പിന്തുടരുന്നു, അതിനാൽ ഒരു പേരുള്ള വിന്യാസം പ്രവർത്തിക്കുകയും വ്യത്യാസം മറയ്ക്കുകയും ചെയ്യുന്നു. EAP വിന്യാസം യഥാർത്ഥത്തിൽ മറ്റെവിടെയോ അവസാനിക്കുമ്പോൾ മാത്രമാണ് വ്യക്തമായ മൂല്യത്തിന് പ്രാധാന്യം. ആ കാരണമില്ലാതെ അത് മറ്റൊരു പേരിലേക്ക് സജ്ജമാക്കുന്നത് ഓപ്പറേറ്റർക്ക് പുനർനിർമ്മിക്കാനാകാത്ത പരാജയം സൃഷ്ടിക്കുന്നു. രണ്ടാമത്തെ പേര് കണ്ടുപിടിക്കുന്നതിന് മുമ്പ് വിന്യാസം വായിക്കുക.

ബാക്കെൻഡ് സർട്ടിഫിക്കറ്റ് യഥാർത്ഥത്തിൽ പറയുന്നതിന്, പേരിന്റെ രൂപം ഉൾപ്പെടെ, മൂല്യം സമാനമായി നിലനിർത്തുക. അവസാനത്തെ ബിന്ദുവോ ഹോസ്റ്റ് ഉൾക്കൊള്ളാത്ത വൈൽഡ്കാർഡോ പരിശോധന പരാജയപ്പെടാൻ മതിയാകും.

വിഭജനം പ്രകടിപ്പിക്കാനാകാത്ത ഫ്രണ്ടെൻഡുകൾ

NetworkManager പ്രൊഫൈൽ swanctl-ന്റെ അതേ കോൺഫിഗറേഷൻ ഇന്റർഫേസല്ല. അതിന് പിന്നിലുള്ള പ്ലഗിൻ ഇടുങ്ങിയ ഐഡന്റിറ്റി നിയന്ത്രണങ്ങൾ മാത്രം നൽകുന്നു, ഏവയുണ്ടെന്ന് ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിനെ ആശ്രയിച്ചിരിക്കുന്നു.

വിന്യാസത്തിന് യഥാർത്ഥത്തിൽ രണ്ട് പേരുകൾ വേണ്ടിവരുമ്പോൾ ഇത് പ്രധാനമാണ്. സെർവർ ഐഡന്റിറ്റി എന്ന് ലേബൽ ചെയ്ത ഫീൽഡ് ഒരു പാളി കോൺഫിഗർ ചെയ്തേക്കാം, മറ്റേത് ചെയ്തെന്ന് വരില്ല, അതിനാൽ പ്രൊഫൈൽ ശരിയായി തോന്നിയാലും ആന്തരിക പരിശോധനയിൽ പരാജയപ്പെടാം. പ്രൊഫൈലിന് ഈ ക്രമീകരണം പ്രകടിപ്പിക്കാമെന്ന് കരുതുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പ്ലഗിൻ എന്ത് പിന്തുണയ്ക്കുന്നുവെന്ന് പരിശോധിക്കുക. കഴിയില്ലെങ്കിൽ, തിരഞ്ഞെടുപ്പ് ഓപ്പറേറ്ററുടേതാണ്: വേറെ പ്രൊവിഷനിംഗ് പാതയോ തിരുത്തിയ സെർവർ ഐഡന്റിറ്റി രൂപകൽപ്പനയോ. PEAP ദുർബലമാക്കുന്നതോ ഏത് പേരും സ്വീകരിക്കുന്നതോ പ്രാമാണീകരണ നയം തിരുത്തുന്നതിനുപകരം മാറ്റുന്നു.

ബദൽ ക്ലയന്റിൽ കണ്ടുപിടിക്കേണ്ട ഒന്നല്ല. പിന്തുണയുള്ള ക്രമീകരണം എഴുത്തിൽ ആവശ്യപ്പെടുക, തുടർന്ന് ആ ഉത്തരം പ്രൊഫൈലിനൊപ്പം സൂക്ഷിക്കുക.

ഐഡന്റിറ്റി പൊരുത്തക്കേടിനെ കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റിൽ നിന്ന് വേർതിരിക്കുക

പേരിന്റെ പൊരുത്തക്കേടും കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റും വ്യത്യസ്ത പരാജയങ്ങളാണ്, ലോഗ് അവയെ വേർതിരിക്കുന്നു. ഏത് ഫീൽഡ് മാറ്റണമെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് സന്ദേശം വായിക്കുക.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

ഉദ്ദേശിച്ച AAA ഐഡന്റിറ്റി സജ്ജമാക്കുന്നത് സർട്ടിഫിക്കറ്റ് പുതുക്കുന്നില്ല, അതിന്റെ ഇഷ്യൂവറിൽ വിശ്വാസം സ്ഥാപിക്കുന്നുമില്ല, സർട്ടിഫിക്കറ്റ് പുതുക്കുന്നത് തെറ്റായ പ്രതീക്ഷിത പേര് തിരുത്തുന്നുമില്ല. മറ്റൊരു ഐഡന്റിറ്റി ഫീൽഡ് തിരുത്തുന്നതിന് മുമ്പ് ഏത് സാധൂകരണമാണ് പരാജയപ്പെട്ടതെന്ന് വായിക്കുക. തുടർന്ന് കോൺഫിഗറേഷൻ വീണ്ടും ലോഡ് ചെയ്ത്, ലോഡ് ചെയ്ത കണക്ഷൻ നിങ്ങൾ സജ്ജമാക്കിയ മൂല്യം കാണിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, കാരണം ഒരിക്കലും ലോഡ് ചെയ്യാത്ത തിരുത്തിയ ഫയൽ ഒന്നും മാറ്റുന്നില്ല. രണ്ട് പേരുകളും അവയുടെ പാളികളും വിന്യാസ കുറിപ്പുകളിൽ എഴുതുക.