strongSwan ESP-in-UDP: കണ്ടെത്താൻ NAT ഇല്ലാത്തപ്പോൾ

NAT കണ്ടെത്തൽ വിലാസ വിവർത്തനം കണ്ടെത്തുന്നു, ഫയർവാൾ നയം അല്ല. NAT ഇല്ലാത്ത സൈറ്റ് കണക്ഷന് ഇപ്പോഴും വ്യക്തമായ ESP-in-UDP തിരഞ്ഞെടുപ്പ് ആവശ്യമായി വന്നേക്കാം.

NAT കണ്ടെത്തൽ ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: വഴിയിൽ വിലാസങ്ങളോ പോർട്ടുകളോ മാറിയോ? ഫയർവാൾ IP പ്രോട്ടോക്കോൾ 50 അനുവദിക്കുന്നുണ്ടോ എന്നതിന് അത് ഉത്തരം നൽകുന്നില്ല. ഒരു വിവർത്തനവുമില്ലാത്ത സൈറ്റ് ഗേറ്റ്‌വേകൾ native ESP ഉപേക്ഷിക്കുന്ന നയത്തിന് പിന്നിൽ ഇപ്പോഴും ആകാം, ആ ആവശ്യകത കണ്ടെത്തുന്നതിന് പകരം കോൺഫിഗർ ചെയ്യണം. സംവിധാനം ESP-in-UDP ആണ്, ഇത് സ്വയം പ്രത്യക്ഷപ്പെടുന്ന ബദലല്ല, ഒരു തീരുമാനമാണ്.

കണ്ടെത്തൽ വിലാസങ്ങളിലെ ഗണിതമാണ്, ഫയർവാൾ പരിശോധനയല്ല

IKEv2 NAT കണ്ടെത്തൽ പേലോഡുകൾ വഹിക്കുന്നു, അവയിൽ ഉറവിട, ലക്ഷ്യ വിലാസങ്ങളുടെയും പോർട്ടുകളുടെയും ഹാഷുകൾ അടങ്ങിയിരിക്കുന്നു. ഓരോ വശവും ലഭിച്ചതിനെ പ്രാദേശികമായി കാണുന്നതുമായി താരതമ്യം ചെയ്യുന്നു, പൊരുത്തക്കേട് ഉണ്ടെങ്കിൽ എന്തോ പാക്കറ്റ് വിവർത്തനം ചെയ്തെന്ന് അതിന് മനസ്സിലാകുന്നു. ആ കൈമാറ്റത്തിൽ നടുവിലെ റൂട്ടർ പ്രോട്ടോക്കോൾ 50 കൈമാറുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്ന ഒന്നുമില്ല.

പ്രായോഗിക പരിണിതി വ്യക്തമായി പറയാൻ യോഗ്യമാണ്. native ESP-യോടെ പ്രവർത്തിച്ച ടണൽ പുതിയ നിയന്ത്രണ ഫയർവാളിനെ സ്വയം കണ്ടെത്തില്ല, IKE വിജയിക്കുന്നതിനിടയിൽ അതിന്റെ അടുത്ത ശ്രമം ഡാറ്റ ഘട്ടത്തിൽ പരാജയപ്പെടും. സ്ഥാപിച്ച IKE സുരക്ഷാ അസോസിയേഷനുകൾ നിങ്ങൾ കാണും, കൂടാതെ സംരക്ഷിത ട്രാഫിക്കില്ല, ഇത് വയറിൽ ക്യാപ്ചർ ചെയ്യുന്നതുവരെ റൂട്ടിംഗ് തകരാറായി തോന്നും.

അതിനാൽ എൻകാപ്സുലേഷൻ നിങ്ങൾ കോൺഫിഗർ ചെയ്യുന്ന കണക്ഷന്റെ സ്വഭാവമാണ്, നെറ്റ്‌വർക്കിന്റെ പെരുമാറ്റത്തിൽ നിന്ന് കക്ഷികൾ ചർച്ച ചെയ്യുന്ന ഫലമല്ല.

encap കൈമാറ്റത്തെ എങ്ങനെ മാറ്റുന്നു

ആധുനിക strongSwan വിന്യാസത്തിൽ, അത് swanctl.conf വഴി നിയന്ത്രിക്കപ്പെടുന്നു, കണക്ഷനിലെ encap = yes ക്രമീകരണം NAT കണ്ടെത്തൽ കൈമാറ്റത്തെ സ്വാധീനിക്കുന്നു, ഇതിനാൽ രണ്ട് കക്ഷികളും ESP-ക്ക് UDP എൻകാപ്സുലേഷൻ ഉപയോഗിക്കുന്നു. സംരക്ഷിത പാക്കറ്റുകൾ പിന്നീട് UDP-യ്ക്കുള്ളിൽ, സാധാരണയായി പോർട്ട് 4500-ൽ സഞ്ചരിക്കുന്നു, രണ്ട് അറ്റങ്ങളും ഈ ക്രമീകരണത്തിന് സമ്മതിക്കണം.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan-ന്റെ NAT-traversal ഗൈഡ് ഈ പെരുമാറ്റം വിവരിക്കുന്നു, MOBIKE ഉപയോഗിക്കുമ്പോൾ പോർട്ട് ഫ്ലോട്ടിംഗുമായുള്ള പരസ്പര പ്രവർത്തനം ഉൾപ്പെടെ.

നിങ്ങളുടെ ബാക്കെൻഡിനുള്ള ക്രമീകരണം ഉപയോഗിക്കുക

strongSwan-ന് രണ്ട് കോൺഫിഗറേഷൻ ബാക്കെൻഡുകളുണ്ട്, കീ അവയ്ക്കിടയിൽ വ്യത്യാസപ്പെടുന്നു. swanctl.conf കണക്ഷൻ encap സ്വീകരിക്കുന്നു, പഴയ ipsec.conf കണക്ഷൻ forceencaps സ്വീകരിക്കുന്നു. ഒരു ബാക്കെൻഡിന്റെ കീവേഡ് മറ്റൊന്നിലേക്ക് ഇടുന്നത് പരാതിയില്ലാതെ ലോഡ് ചെയ്യപ്പെടുന്നതും ഒന്നും മാറ്റാത്തതുമായ കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുന്നു, ഇത് പിശകിനെക്കാൾ മോശമാണ്.

എന്തെങ്കിലും എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ഏത് ഡീമൺ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുവെന്ന് പരിശോധിക്കുക. പല വിതരണങ്ങളിലും രണ്ട് ഫയലുകളും നിലവിലുണ്ട്, ഒന്ന് മുൻ കുടിയേറ്റത്തിന്റെ ശേഷിപ്പാണ്, സജീവമായത് സേവന യൂണിറ്റ് ആരംഭിക്കുന്നതാണ്. ഫയൽ ടൈംസ്റ്റാമ്പുകളിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം ആ യൂണിറ്റ് വായിക്കുക. ഇവിടെ അഞ്ച് സെക്കൻഡ് പരിശോധന ഒന്നും ലോഡ് ചെയ്യാത്ത ക്രമീകരണം മണിക്കൂറുകളോളം പരീക്ഷിക്കുന്നത് തടയുന്നു.

കണക്ഷന്റെ ഉടമ വഴി മാറ്റം പ്രയോഗിക്കുക, നിയന്ത്രിത വിൻഡോയിൽ അസോസിയേഷൻ വീണ്ടും സ്ഥാപിക്കുക. ഇതിനകം ഇൻസ്റ്റാൾ ചെയ്ത child മാറ്റിസ്ഥാപിക്കുന്നതുവരെ അതിന്റെ നിലവിലെ എൻകാപ്സുലേഷൻ നിലനിർത്തുന്നു, അതിനാൽ ഫയൽ എഡിറ്റ് മാത്രം പുതിയ ക്രമീകരണം ഉപയോഗത്തിലുണ്ടെന്ന് തെളിയിക്കുന്നില്ല.

പൊതിഞ്ഞ ഡാറ്റ പരിശോധിക്കുക, പോർട്ട് മാത്രമല്ല

സംരക്ഷിത ട്രാഫിക് ഒഴുകുമ്പോൾ ഗേറ്റ്‌വേയിൽ ക്യാപ്ചർ ചെയ്യുക, തുടർന്ന് strongSwan-ന്റെ സ്വന്തം കാഴ്ചയുമായി താരതമ്യം ചെയ്യുക:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP പ്രോട്ടോക്കോൾ 50 ആയി പ്രത്യക്ഷപ്പെടുന്നു, UDP-യോട് ഒട്ടും സാമ്യമില്ല. പൊതിഞ്ഞ ESP 4500-ൽ UDP ഡാറ്റാഗ്രാമുകളായി പ്രത്യക്ഷപ്പെടുന്നു, അവയുടെ പേലോഡ് IKE അല്ല. അതേ പോർട്ടിലെ IKE ട്രാഫിക് എൻകാപ്സുലേഷന്റെ തെളിവല്ല, കാരണം MOBIKE IKE അവിടേക്ക് നീക്കാം, ഡാറ്റ പാത native ആയി തുടരും, അതിനാൽ പോർട്ട് നമ്പറല്ല, പേലോഡ് വായിക്കുക.

പാതയുടെ MTU-യും ഓർക്കുക. ആവരണം അധിക ചെലവ് ചേർക്കുന്നു, native ESP വഹിച്ച പാത പാക്കറ്റുകൾ വലുതാകുമ്പോൾ ക്രമീകരണങ്ങൾ ആവശ്യമായി വന്നേക്കാം. ആവശ്യമായ ICMP കൈകാര്യം ഇതിനകം രൂപകൽപ്പനയുടെ ഭാഗമായിരിക്കണം; എൻകാപ്സുലേഷൻ ആ ആശ്രിതത്വം നീക്കുന്നില്ല.

ടണലിനുള്ളിലെ പുതിയ ആപ്ലിക്കേഷൻ ട്രാഫിക് രണ്ട് അറ്റങ്ങളിലും പൊതിഞ്ഞ ESP ആയി ക്യാപ്ചറിൽ കാണുകയും, ആന്തരിക സേവനവും അതിന്റെ മടങ്ങിവരവ് പാതയും ഇപ്പോഴും പ്രവർത്തിക്കുകയും ചെയ്യുമ്പോൾ മാറ്റം സ്വീകരിക്കുക. അതിൽ കുറവ് എന്തും ഫയലിൽ ശരിയായി തോന്നുന്ന കോൺഫിഗറേഷനാണ്.

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