RADIUS VPN ഉപയോക്തൃനാമത്തിന് പകരം IP വിലാസം കാണുന്നത് എന്തുകൊണ്ട്

ഏതൊരു EAP കൈമാറ്റത്തിനും മുമ്പ് strongSwan IKE ഐഡന്റിറ്റി RADIUS User-Name-ൽ ഇടാം. അക്കൗണ്ട് ഐഡന്റിറ്റി ആര് ആവശ്യപ്പെടുന്നുവെന്ന് തീരുമാനിച്ച്, പിന്നീട് ഒരു ശ്രമം പരസ്പരം ബന്ധിപ്പിക്കുക.

Windows IKEv2 ക്ലൈന്റ് കണക്ട് ചെയ്യുന്നു, RADIUS അഭ്യർത്ഥന അക്കൗണ്ട് നാമം ഉണ്ടായിരിക്കേണ്ടിടത്ത് ഒരു വിലാസവുമായി എത്തുന്നു. ഇതുവരെ ഒന്നും പരാജയപ്പെട്ടിട്ടില്ല, സംഭ്രമിപ്പിക്കുന്ന ഭാഗം അതാണ്: ഗേറ്റ്വേ ക്ലൈന്റ് IKE പാളിയിൽ അവതരിപ്പിച്ച ഐഡന്റിറ്റി റിപ്പോർട്ട് ചെയ്യുന്നു. നിങ്ങളുടെ ബാക്കെൻഡിന് വേണ്ട ഉപയോക്തൃനാമം ഇതുവരെ സംഭവിക്കാത്ത ഒരു പ്രത്യേക EAP കൈമാറ്റത്തിൽ നിന്ന് വന്നേക്കാം. അക്കൗണ്ട് മാറ്റുന്നതിന് മുമ്പ് അത് ആര് ആവശ്യപ്പെടുമെന്ന് തീരുമാനിക്കുക.

ഒരു കണക്ഷനിൽ രണ്ട് ഐഡന്റിറ്റികൾ സഞ്ചരിക്കുന്നു

ഒരു കണക്ഷനിൽ രണ്ട് പേരുകൾ പ്രത്യക്ഷപ്പെടാം. IKE ഐഡന്റിറ്റി ടണൽ സെറ്റപ്പ് സമയത്ത് പീയറിനെ തിരിച്ചറിയുന്നു, eap-radius പ്ലഗിൻ ആദ്യം അത് RADIUS User-Name-ലേക്ക് പകർത്തുന്നു. EAP ഐഡന്റിറ്റി ഉപയോക്തൃ പ്രാമാണീകരണത്തിന് ഉപയോഗിക്കുന്ന മറ്റൊരു മൂല്യമാണ്, ആരും ആവശ്യപ്പെട്ടില്ലെങ്കിൽ അത് ഒരിക്കലും അയക്കണമെന്നില്ല.

അതുകൊണ്ടാണ് അക്കൗണ്ട് നിലവിലുണ്ടെന്നും പാസ്വേഡ് ശരിയാണെന്നും ഉള്ളപ്പോഴും RADIUS ലോഗിൽ ഒരു വിലാസം കാണാവുന്നത്. ബാക്കെൻഡിനോട് തെറ്റായ പാളിയെക്കുറിച്ചാണ് ചോദിക്കുന്നത്. RADIUS ആട്രിബ്യൂട്ട് തിരഞ്ഞെടുത്ത പേരിനുള്ള വാഹകൻ മാത്രമാണ്.

EAP ഐഡന്റിറ്റി ആവശ്യപ്പെടാൻ ഗേറ്റ്വേയോട് പറയുക

പിന്തുണയുള്ള ഒരു ക്രമീകരണത്തിൽ പ്രാമാണീകരണം RADIUS-ന് കൈമാറുന്നതിന് മുമ്പ് ഗേറ്റ്വേ EAP ഐഡന്റിറ്റി ആവശ്യപ്പെടുന്നു. കണക്ഷന്റെ ദൂര പ്രാമാണീകരണ വിഭാഗത്തിൽ രീതി eap-radius ആക്കി സെറ്റ് ചെയ്ത് EAP ഐഡന്റിറ്റി വ്യക്തമായി ആവശ്യപ്പെടുക. താഴെയുള്ള ഭാഗം സ്വന്തം ഫയലിലല്ല, നിലവിലുള്ള ഒരു കണക്ഷൻ ബ്ലോക്കിനുള്ളിൽ വരുന്നു. മറ്റൊരു വിന്യാസത്തിൽ നിന്ന് സിന്തക്സ് പകർത്തുന്നതിന് മുമ്പ് കണക്ഷനും കോൺഫിഗറേഷൻ ബാക്കെൻഡും സ്ഥിരീകരിക്കുക.

remote {
    auth = eap-radius
    eap_id = %any
}

അതോടെ IKE വിലാസത്തിന് പകരം ക്ലൈന്റ് EAP കൈമാറ്റത്തിൽ നൽകുന്ന ഐഡന്റിറ്റി ബാക്കെൻഡിന് ലഭിക്കുന്നു. കണക്ഷനിൽ മറ്റൊന്നും മാറുന്നില്ല.

അല്ലെങ്കിൽ RADIUS EAP കൈമാറ്റം ആരംഭിക്കട്ടെ

മറ്റേ ക്രമീകരണം ആദ്യ നീക്കം RADIUS വശത്ത് ഇടുന്നു. പ്രാരംഭ ഐഡന്റിറ്റി പ്രതികരണത്തിനായി കാത്തിരിക്കുന്നതിന് പകരം പ്ലഗിൻ EAP-Start സൂചന അയക്കാം, ഇത് സെർവറിന് കൈമാറ്റം നയിക്കാൻ അനുവദിക്കുന്നു. ഇത് പ്ലഗിൻ തലത്തിലുള്ള കോൺഫിഗറേഷനാണ്, അതിനാൽ പ്ലഗിൻ ഉപയോഗിക്കുന്ന ഓരോ കണക്ഷനെയും ബാധിക്കുന്നു.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

രണ്ടും പ്രവർത്തനക്ഷമമാക്കി പ്രതീക്ഷിക്കുന്നതിന് പകരം RADIUS ഓപ്പറേറ്ററുമായി ഒരു ക്രമീകരണം തിരഞ്ഞെടുക്കുക. അവ വ്യത്യസ്ത വർക്ക്ഫ്ലോകൾ വിവരിക്കുന്നു, ആരംഭിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന സെർവർ സംഭാഷണം തുടങ്ങുന്ന ഗേറ്റ്വേയെ നിർബന്ധമായും കൈകാര്യം ചെയ്യണമെന്നില്ല. പ്ലഗിൻ ഡോക്യുമെന്റേഷൻ രണ്ടും വിവരിക്കുന്നു, ഓരോ ഘട്ടവും ഏത് ഐഡന്റിറ്റി വഹിക്കുന്നുവെന്നത് ഉൾപ്പെടെ.

ഒരു ശ്രമം രണ്ട് ലോഗുകളിലും പിന്തുടരുക

ഒരു ശ്രമം രണ്ട് ലോഗുകളിലും പരസ്പരം ബന്ധിപ്പിക്കുക. IKE ഐഡന്റിറ്റി നോക്കുക, പിന്നീട് EAP-Identity കൈമാറ്റം നടക്കുന്നുണ്ടോയെന്ന്, പിന്നീട് പ്രാമാണീകരണ ഘട്ടത്തിന് ഏത് പേര് ലഭിക്കുന്നുവെന്ന്. EAP കൈമാറ്റത്തിന് മുമ്പ് വിലാസം നിരസിക്കുന്ന ബാക്കെൻഡിന് നിങ്ങളുടെ ഉദ്ദേശിച്ച ഐഡന്റിറ്റി ഒരിക്കലും കാണുന്നതിന് മുമ്പ് പ്രക്രിയ നിർത്താം.

journalctl -u strongswan -f

ഐഡന്റിറ്റി സിസ്റ്റം പ്രതീക്ഷിക്കുന്ന കൃത്യമായ ഉപയോക്തൃനാമ ഫോർമാറ്റ് ഡൊമെയ്ൻ പ്രിഫിക്സ് ഉൾപ്പെടെ നിലനിർത്തുക. വിലാസ രൂപത്തിലുള്ള മൂല്യത്തിൽ നിന്ന് ഒരിക്കലും അക്കൗണ്ട് ഉണ്ടാക്കരുത്, നയ നിയമം പാലിക്കാൻ ഒരിക്കലും പ്രാമാണീകരണം ഓഫ് ചെയ്യരുത്. EAP ഐഡന്റിറ്റി പ്രഖ്യാപിത നാമമാണ്, രീതി ഇപ്പോഴും അത് തെളിയിക്കണം. ഫലമായ പേര് പരീക്ഷണ രേഖയിൽ എഴുതുക, അടുത്ത ശ്രമം അറിയപ്പെടുന്ന അവസ്ഥയിൽ നിന്ന് തുടങ്ങാൻ.

തിരുത്തിയ പ്രവാഹം ശരിയായ അക്കൗണ്ടിൽ എത്തിയിട്ടും നിരസിക്കപ്പെട്ടാൽ, അടുത്ത തെളിവ് ഐഡന്റിറ്റിയല്ല, EAP രീതിയും ബാക്കെൻഡ് നയവുമാണ്. പാസ്വേഡ് റീസെറ്റ് ആവർത്തിക്കുന്നത് മുൻ പ്രോട്ടോക്കോൾ പാളിയിൽ തിരഞ്ഞെടുത്ത മൂല്യം പരിഹരിക്കാൻ കഴിയില്ല.

അനുബന്ധ ലേഖനങ്ങൾ