Android-ൽ നിലവാരമില്ലാത്ത UDP പോർട്ടിൽ IKEv2 എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

ഗേറ്റ്‌വേ ഏതോ കാരണത്താൽ UDP 4443-ൽ IKEv2-നോട് പ്രതികരിക്കുന്നു, പ്രൊഫൈലിൽ Server എന്ന പേരിലുള്ള ഒരു ഫീൽഡുണ്ട്, നിങ്ങൾ ഹോസ്റ്റ്നാമും പോർട്ടും ടൈപ്പ് ചെയ്യുന്നു, എന്നാൽ ഫോൺ സർവറിലെത്താൻ കഴിയില്ലെന്നോ വിലാസം പരിഹരിക്കാൻ കഴിയില്ലെന്നോ റിപ്പോർട്ട് ചെയ്യുന്നു. ഒന്നും തടയപ്പെടുന്നില്ല. Android-ന്റെ സ്വദേശീയ ഫോം ഒരു ഹോസ്റ്റ് പ്രതീക്ഷിക്കുന്നു, Windows-ലും അതുതന്നെ ശരിയാണ്. ഇഷ്ടാനുസൃത പോർട്ട് സർവർ ക്രമീകരണമാകുന്നതിന് മുമ്പ് ക്ലയന്റിന്റെ കഴിവാണ്, കുറച്ച് ക്ലയന്റുകൾ മാത്രമാണ് അത് പ്രകടിപ്പിക്കാൻ അനുവദിക്കുന്നത്. മൂന്ന് ഭാഗങ്ങൾ ക്രമത്തിൽ പരിശോധിക്കുക: ക്ലയന്റ് എന്ത് പറയാം, സർവർ എന്ത് ശ്രവിക്കുന്നു, രണ്ട് അറ്റങ്ങളും ഒരേ രീതിയിൽ പാക്കറ്റുകൾ ഫ്രെയിം ചെയ്യുന്നുണ്ടോ എന്നതും.

ഫോൺ യഥാർത്ഥത്തിൽ അയച്ചത്

ഒരു പേരിനായി ഉദ്ദേശിച്ച ഫീൽഡിലെ host:port സ്ട്രിംഗ് ഒരു പേരായി പരിഹരിക്കപ്പെടുന്നു. റിസോൾവർ vpn.example.net:4443-ന് ഒന്നും തിരികെ നൽകുന്നില്ല, നിങ്ങൾ കാണുന്ന പിശക് പോർട്ടിലെ സമയപരിധി കഴിയലല്ല, പേര് പരിഹരിക്കൽ അല്ലെങ്കിൽ എത്തിച്ചേരാനാകായ്മയുടെ പരാജയമാണ്. ആ വ്യത്യാസം പ്രധാനമാണ്, കാരണം ചെറിയ പേരോ മറ്റൊരു നെറ്റ്‌വർക്കോ ഉപയോഗിച്ച് വീണ്ടും ശ്രമിച്ചാലും ഫോമിന് പാഴ്‌സ് ചെയ്യാൻ കഴിയാത്ത സ്ട്രിംഗ് ഒരിക്കലും ശരിയാകില്ല.

Android-ലെ സ്വദേശീയ IKEv2 പ്രൊഫൈൽ, Windows-ന്റെ ഉൾനിർമ്മിത VPN ക്ലയന്റ് പോലെ, സ്റ്റാൻഡേർഡ് IKE പോർട്ടുകളിൽ ഉറപ്പിച്ചിരിക്കുന്നു. ഒന്നും ഒരു പോർട്ട് ഫീൽഡ് കാണിക്കുന്നില്ല, പ്രൊഫൈൽ എഡിറ്റ് ചെയ്ത് ഒന്നും ചേർക്കാനാവില്ല. ഓപ്പറേറ്ററുടെ ശ്രോതാവ് യഥാർത്ഥത്തിൽ 4443-ൽ ആണെങ്കിൽ, ഉൾനിർമ്മിത ക്ലയന്റ് തെറ്റായി കോൺഫിഗർ ചെയ്തതല്ല, തെറ്റായ ഉപകരണമാണ്.

പോർട്ട് കാണിക്കുന്ന ക്ലയന്റ് ഉപയോഗിക്കുക

strongSwan-ന്റെ Android ക്ലയന്റ് വിപുലീകൃത പ്രൊഫൈൽ ക്രമീകരണങ്ങളിൽ കോൺഫിഗർ ചെയ്യാവുന്ന സർവർ പോർട്ട് രേഖപ്പെടുത്തുന്നു, അതുകൊണ്ടാണ് ഈ രൂപകൽപ്പനയ്ക്ക് പ്രവർത്തിക്കുന്ന മിക്കവാറും എല്ലാ നിർദ്ദേശങ്ങളിലും ഇത് കാണുന്നത്. ആ പിന്തുണ ആ ക്ലയന്റിന്റേതാണ്: മറ്റൊരു IKEv2 ആപ്പോ അതേ ആപ്പിന്റെ വെണ്ടർ ഫോർക്കോ അടിസ്ഥാന strongSwan ഡീമൺ പിന്തുണച്ചാലും അതേ ഫീൽഡ് കാണിച്ചെന്ന് വരില്ല.

ഓപ്പറേറ്ററിൽ നിന്ന് മുഴുവൻ സെറ്റും ഒരുമിച്ച് ആവശ്യപ്പെടുക: ഗേറ്റ്‌വേ പേര്, UDP പോർട്ട്, പ്രാമാണീകരണ രീതി, ക്ലയന്റ് പ്രതീക്ഷിക്കേണ്ട സർവർ ഐഡന്റിറ്റി. ഇഷ്ടാനുസൃത പോർട്ട് സർട്ടിഫിക്കറ്റ് പരിശോധന ഓഫ് ചെയ്യാനോ പ്രോട്ടോക്കോളുകൾ മാറ്റാനോ ഉള്ള കാരണമല്ല. ഇൻസ്റ്റാൾ ചെയ്ത ക്ലയന്റ് പോർട്ട് പ്രതീക്ഷിക്കുന്നിടത്ത് അത് നൽകുക, ആ ക്ലയന്റിൽ അത്തരം ഫീൽഡ് ഇല്ലെങ്കിൽ, ഉത്തരം ഊഹിച്ച ഒരു പരിഹാരമല്ല, മറ്റൊരു അംഗീകൃത ക്ലയന്റാണ്.

സർവറിന് രണ്ട് പോർട്ടുകളുണ്ട്, രണ്ടും ഒത്തുചേരണം

IKE UDP 500-ൽ ആരംഭിക്കുന്നു, NAT ട്രാവേഴ്സൽ സാധാരണയായി IKE-യും എൻകാപ്സുലേറ്റ് ചെയ്ത ESP-യും UDP 4500-ലേക്ക് നീക്കുന്നു. ഇവ strongSwan-ൽ വെവ്വേറെ ക്രമീകരണങ്ങളാണ്, അതിനാൽ ഒരു ഇഷ്ടാനുസൃത പോർട്ടിലേക്ക് മാറ്റിയ സർവർ രണ്ടും ഒരേ മൂല്യത്തിലേക്ക് മാറ്റണം:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

ഒരു പോർട്ട് രണ്ട് റോളുകൾക്കും സേവിക്കുമ്പോൾ, ഡീമൺ അതേ സോക്കറ്റിൽ IKE-യെ ESP-in-UDP-യിൽ നിന്ന് വേർതിരിക്കണം, IKE സന്ദേശത്തിന് മുമ്പ് വരുന്ന നാല് ബൈറ്റ് ESP-അല്ലാത്ത മാർക്കർ ഉപയോഗിച്ചാണ് അത് ചെയ്യുന്നത്. അതിനാൽ ക്ലയന്റിന് ഇഷ്ടാനുസൃത പോർട്ടിൽ ചർച്ച ചെയ്ത് പിന്നീട് 4500-ൽ നിശ്ശബ്ദമായി തുടരാനാവില്ല, അതുകൊണ്ടാണ് “പോർട്ട് മാറ്റുക മാത്രം” എന്ന വാക്യം ഫ്രെയിമിംഗ് ആവശ്യകത മറയ്ക്കുന്നത്.

ഫോർവേഡിംഗ് ശ്രോതാവല്ല

4443 ഒരു സാധാരണ IKE ശ്രോതാവിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നത് മിക്കവാറും വിജയിച്ചതായി തോന്നുന്ന പരാജയ മാതൃകയാണ്. ആദ്യ കൈമാറ്റം എത്തുന്നു, സർവർ മറുപടി നൽകുന്നു, പിന്നീട് കണക്ഷൻ നിലയ്ക്കുന്നു അല്ലെങ്കിൽ കീകൾ ഒന്നുമില്ലാത്തതിലേക്ക് പുനഃസൃഷ്ടിക്കുന്നു, കാരണം മറുപടി മറ്റൊരു പോർട്ടിൽ നിന്ന് പുറപ്പെടുന്നു, തുടർന്നുള്ള എൻകാപ്സുലേറ്റ് ചെയ്ത ട്രാഫിക് രണ്ട് അറ്റങ്ങൾ സൃഷ്ടിച്ച അവസ്ഥയുമായി ഒരിക്കലും ഒത്തുചേരുന്നില്ല. ശ്രോതാവിനെ നീക്കാതെ ലക്ഷ്യ പോർട്ട് വീണ്ടും എഴുതുന്ന നിയമം കൃത്യമായി ഈ പകുതി-തുറന്ന ഫലം നൽകുന്നു.

പാത UDP-യും അറ്റം മുതൽ അറ്റം വരെ അനുവദിക്കണം. TCP 443 ഒരു ഹോട്ടൽ അല്ലെങ്കിൽ ഓപ്പറേറ്റർ നെറ്റ്‌വർക്കിലൂടെ കടന്നുപോകുന്നത് UDP പോർട്ടിലെ IKEv2-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതേ നമ്പർ ആണെങ്കിലും. TCP 443 മാത്രം അനുവദിക്കുന്നിടത്ത്, ഇഷ്ടാനുസൃത UDP പോർട്ട് IKEv2-യെ HTTPS ആക്കുന്നില്ല, ശരിയായ ഉത്തരം മറ്റൊരു പോർട്ട് പരീക്ഷണമല്ല, മറ്റൊരു പ്രവേശന പാതയായിരിക്കാം.

പരീക്ഷിക്കുമ്പോൾ മൂന്ന് ഘട്ടങ്ങൾ വേർതിരിക്കുക

ക്ലയന്റ് ഒരിക്കൽ ശ്രമിക്കുമ്പോൾ സർവറിൽ ക്യാപ്ചർ ചെയ്യുക. ഒരിക്കലും എത്താത്ത അഭ്യർത്ഥന അറ്റം അല്ലെങ്കിൽ ഫയർവാൾ ചോദ്യമാണ്; മറുപടിയില്ലാതെ എത്തുന്ന അഭ്യർത്ഥന ശ്രോതാവ് അല്ലെങ്കിൽ നയ ചോദ്യമാണ്; മൗനം പിന്തുടരുന്ന മറുപടി ഫ്രെയിമിംഗ് അല്ലെങ്കിൽ ഐഡന്റിറ്റി ചോദ്യമാണ്.

tcpdump -ni eth0 -vv udp port 4443

തുടർന്ന് ക്ലയന്റിന്റെ കറങ്ങുന്ന സൂചകമല്ല, അതിന്റെ സന്ദേശം വായിക്കുക. നിർദ്ദേശ പിശക് അർത്ഥമാക്കുന്നത് അൽഗോരിതങ്ങൾ ഒത്തുചേരുന്നില്ല എന്നാണ്, പ്രാമാണീകരണ പരാജയം അർത്ഥമാക്കുന്നത് ഐഡന്റിറ്റികളോ സർട്ടിഫിക്കറ്റുകളോ ഒത്തുചേരുന്നില്ല എന്നാണ്, മറുപടിയില്ലാത്ത ആവർത്തിച്ചുള്ള പുനഃസംപ്രേഷണം അർത്ഥമാക്കുന്നത് ആ പോർട്ടിൽ ഒന്നും പ്രതികരിക്കുന്നില്ല എന്നാണ്. ഒരിക്കൽ ഒരു ഘട്ടം പരീക്ഷിക്കുക, ശ്രമങ്ങൾക്കിടയിൽ ഒരു ഫീൽഡ് മാറ്റുക; NAT ട്രാവേഴ്സൽ സംബന്ധിച്ച strongSwan രേഖകൾ ക്യാപ്ചർ കാണിക്കുന്ന മാർക്കറും പോർട്ട് സ്വഭാവവും വിവരിക്കുന്നു.