IPsec ഗേറ്റ്വേയ്ക്കായി WireGuard പ്രൊഫൈൽ: പകരം എന്ത് ചോദിക്കണം

നിശ്ശബ്ദ ഗേറ്റ്വേയുമായുള്ള ഹസ്തദാന കാലഹരണം സാധാരണയായി ഒരിക്കലും കണ്ടുമുട്ടാത്ത രണ്ട് പ്രോട്ടോക്കോളുകളെ അർത്ഥമാക്കുന്നു. WireGuard പിയർ Noise സംസാരിക്കുമ്പോൾ IPsec ഗേറ്റ്വേ IKE കാത്തിരിക്കുന്നു. ശരിയായ വിലാസവും പോർട്ടും അത് മാറ്റുന്നില്ല.

പ്രൊഫൈലിൽ എൻഡ്പോയിന്റ് വീണ്ടും ഉപയോഗിക്കുന്നത് രണ്ടിനെയും ബന്ധിപ്പിക്കുന്നില്ല. അടുത്ത ഘട്ടം ഗേറ്റ്വേ നടത്തുന്നയാളോടുള്ള അഭ്യർത്ഥനയാണ്.

ആദ്യ അഭ്യർത്ഥന: പ്രോട്ടോക്കോൾ പതിപ്പ്

IPsec ഒരു കുടുംബത്തെ സൂചിപ്പിക്കുന്നു, ഒരൊറ്റ പ്രവൃത്തിപഥമല്ല. IKEv2, IKEv1 എന്നിവ അവയുടെ കൈമാറ്റങ്ങൾ, ആധികാരികതാ ഓപ്ഷനുകൾ, നെറ്റ്വർക്ക് മാറുമ്പോഴുള്ള പെരുമാറ്റം എന്നിവയിൽ വ്യത്യസ്തമാണ്. IKEv1 മാത്രം അവസാനിപ്പിക്കുന്ന ഗേറ്റ്വേ IKEv2 വാഗ്ദാനം ചെയ്യുന്ന ഗേറ്റ്വേയിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമായി പ്രവർത്തിക്കും. ക്ലയന്റ് കോൺഫിഗറേഷനും അതിനൊപ്പം മാറുന്നു.

സേവനം ഏത് പതിപ്പ് അവസാനിപ്പിക്കുന്നു, സ്റ്റാൻഡേർഡ് അധിഷ്ഠിത നടപ്പാക്കലാണോ സ്വന്തം ക്ലയന്റുള്ള വിതരണക്കാരൻ്റെ വകഭേദമാണോ എന്ന് ചോദിക്കുക. ഓപ്പറേറ്റിംഗ് സിസ്റ്റം മെനുകൾ ആ ഉത്തരം ഒരു ലേബലിന് പിന്നിൽ മറയ്ക്കാറുണ്ട്. ലേബൽ പ്രോട്ടോക്കോളല്ല.

രണ്ടാമത്തെ അഭ്യർത്ഥന: ക്ലയന്റിന്റെ ആധികാരികതാ രീതി

ആധികാരികതയാണ് യഥാർത്ഥ ജോലിയുടെ ഭൂരിഭാഗവും ഉള്ളത്. ഒരു പ്രത്യേക വിപുലീകൃത കീ ഉപയോഗമുള്ള മെഷീൻ സർട്ടിഫിക്കറ്റ്, ഉപയോക്തൃ സർട്ടിഫിക്കറ്റ്, IKEv2-ന് മുകളിലുള്ള EAP രീതി, അല്ലെങ്കിൽ ഒരു ഐഡന്റിറ്റിയുമായി ബന്ധിച്ച മുൻകൂട്ടി പങ്കിട്ട കീ എന്നിവ സേവനം പ്രതീക്ഷിച്ചേക്കാം. ഏതാണ് ബാധകമെന്നത് ക്ലയന്റിന് എന്ത് വേണമെന്ന് നിർണ്ണയിക്കുന്നു.

WireGuard സ്വകാര്യ കീ അവയിലൊന്നുമല്ല. ഒരു നിർദ്ദിഷ്ട ഹസ്തദാനത്തിൽ ഉപയോഗിക്കുന്ന Curve25519 കീയാണ്. ഒരു പരിവർത്തനവും അതിനെ സർട്ടിഫിക്കറ്റോ EAP ക്രെഡൻഷ്യലോ ആക്കുന്നില്ല. അല്ലെന്ന് അവകാശപ്പെടുന്ന ഉപകരണം ഫയലിന്റെ പേര് മാറ്റുകയോ ബന്ധമില്ലാത്ത എന്തെങ്കിലും സൃഷ്ടിക്കുകയോ ചെയ്യുന്നു.

RFC 7296-ലെ IKEv2 സ്പെസിഫിക്കേഷൻ ആ പതിപ്പിന്റെ നടപ്പാക്കൽ എന്ത് പിന്തുണയ്ക്കണമെന്ന് വിവരിക്കുന്നു. ഓപ്പറേറ്ററുടെ അവ്യക്തമായ ഉത്തരത്തിനുള്ള റഫറൻസാണത്, ക്ലയന്റ് കോൺഫിഗറേഷൻ ഗൈഡല്ല.

മൂന്നാമത്തെ അഭ്യർത്ഥന: വിശ്വസ്ത ഐഡന്റിറ്റിയും ലക്ഷ്യങ്ങളും

ക്ലയന്റ് കാണേണ്ട രീതിയിൽ ഗേറ്റ്വേയുടെ ഐഡന്റിറ്റിയും അത് സാധൂകരിക്കുന്ന വിശ്വാസ ആങ്കറും ചോദിക്കുക. തുടർന്ന് സേവനം തള്ളുന്ന സ്വകാര്യ ശ്രേണികളും റിസോൾവറുകളും ചോദിക്കുക. ആ രണ്ട് ഉത്തരങ്ങൾ ടണൽ യഥാർത്ഥത്തിൽ എന്ത് വഹിക്കുന്നു എന്ന് നിർണ്ണയിക്കുന്നു.

അവയില്ലാതെ പ്രവർത്തിക്കുന്ന കണക്ഷനും ചുമതല പരാജയപ്പെടാം. തള്ളിയ റിസോൾവറില്ലാതെ ഉയരുന്ന ടണൽ ആന്തരിക നാമങ്ങളെ ഉത്തരമില്ലാതെ വിടുന്നു. ഇല്ലാത്ത ട്രാഫിക് സെലക്ടർ ലക്ഷ്യത്തെ ടണലിന് പുറത്ത് വിടുന്നു, ഹസ്തദാനം വിജയിച്ചാലും.

എൻഡ്പോയിന്റ് പരിശോധന ക്ലയന്റ് പിശകിൽ നിന്ന് വ്യത്യസ്തമായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. അസോസിയേഷനില്ലാതെ എത്താവുന്ന പോർട്ട് ആധികാരികതയെ സൂചിപ്പിക്കുന്നു, എത്താനാവാത്ത പോർട്ട് പഥത്തെ.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

ക്ലയന്റിൽ എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ആ പരിശോധന നടത്തുക. പോർട്ടുകൾ ഉത്തരം നൽകിയിട്ടും അസോസിയേഷൻ പരാജയപ്പെടുന്നുവെങ്കിൽ പ്രശ്നം ക്രെഡൻഷ്യലുകളിലോ നയത്തിലോ ആണ്. അവ തീരെ ഉത്തരം നൽകിയില്ലെങ്കിൽ പ്രൊഫൈൽ എഡിറ്റ് സഹായിക്കില്ല.

രണ്ട് പ്രോട്ടോക്കോളുകളും ഒരുമിച്ച് നിൽക്കേണ്ടിവരുമ്പോൾ

രണ്ട് നെറ്റ്വർക്കുകളും കൈകാര്യം ചെയ്യുന്നത് രണ്ട് പ്രോട്ടോക്കോളുകളും നിലനിർത്താനുള്ള ന്യായമായ കാരണമാണ്. സാധാരണ രൂപകൽപ്പന WireGuard, IPsec എന്നിവ വെവ്വേറെ ഇന്റർഫേസുകളിലോ വെവ്വേറെ ഗേറ്റ്വേകളിലോ അവസാനിപ്പിക്കുന്നു. അനുവദിച്ച ട്രാഫിക് പിന്നീട് അവയ്ക്കിടയിൽ റൂട്ട് ചെയ്യുന്നു.

ആ രൂപകൽപ്പന വിശ്വാസത്തിന്റെയും അധികാരത്തിന്റെയും അതിർത്തി കൊണ്ടുവരുന്നു, അത് അങ്ങനെതന്നെ രേഖപ്പെടുത്തണം. ഏത് പിയറുകൾക്ക് കടക്കാം, ഏത് ദിശയിൽ, ആരുടെ നയപ്രകാരം എന്നത് റൂട്ടിംഗ്, ഫയർവാൾ തീരുമാനമാണ്. രണ്ട് പ്രോട്ടോക്കോളുകളിൽ ഒന്നും അത് നൽകുന്നില്ല.

ഇത് അല്ലാത്തത് സുതാര്യമായ പരിവർത്തനമാണ്. WireGuard വഴി എത്തുന്ന ട്രാഫിക് IPsec ടണലിൽ വീണ്ടും സൃഷ്ടിക്കപ്പെടുന്നു, ഇടയിലുള്ള ഓരോ നയവും അതിൽ ബാധകമാണ്.

ആദ്യം സെർവറിന്റെ പ്രോട്ടോക്കോൾ, ആധികാരികതാ ആവശ്യകതകൾ വ്യക്തമാക്കുക. തുടർന്ന് ഓപ്പറേറ്റർ പിന്തുണയ്ക്കുന്ന ക്ലയന്റും രജിസ്ട്രേഷൻ പഥവും ഉപയോഗിക്കുക, അതിനിടയിൽ സ്വകാര്യ കീകൾ വെബ് പരിവർത്തകരിൽ നിന്ന് അകറ്റി നിർത്തുക.