strongSwan-ൽ നിന്ന് AWS Site-to-Site-ലേക്ക്: Child SA ഒന്നും തിരഞ്ഞെടുക്കാത്തത് എന്തുകൊണ്ട്

IKE ടണൽ ഉയർന്നിരിക്കാം, എന്നാൽ ചൈൽഡ് അസോസിയേഷൻ നിങ്ങളുടെ സബ്നെറ്റുകൾ ഒഴിവാക്കുന്നു. ആദ്യം AWS-ന്റെ ലോക്കൽ, റിമോട്ട് CIDR എന്നിവ leftsubnet, rightsubnet എന്നിവയുമായി താരതമ്യം ചെയ്യുക.

കൺസോൾ up കാണിക്കുന്നു, strongSwan സ്ഥാപിത IKE അസോസിയേഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു, പക്ഷേ പാക്കറ്റുകൾ ഇപ്പോഴും എത്തുന്നില്ല. അടുത്തതായി താരതമ്യം ചെയ്യേണ്ടത് പ്രീ-ഷെയേർഡ് കീയല്ല, മറിച്ച് ഓരോ വശവും ടണൽ സംരക്ഷിക്കുന്നു എന്ന് വിശ്വസിക്കുന്ന പ്രിഫിക്സുകളുടെ ജോഡിയാണ്. ചുവടെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, കാരണം ആദ്യ രണ്ടെണ്ണം ടണലിന് നിങ്ങളുടെ ട്രാഫിക് വഹിക്കാനാകുമോ എന്ന് തീരുമാനിക്കുന്നു.

AWS-ന്റെ പേരുകൾ strongSwan-ന്റെ പദങ്ങളിലേക്ക് വിവർത്തനം ചെയ്യുക

AWS ബന്ധം ഉപഭോക്തൃ വശത്തുനിന്ന് വിവരിക്കുന്നു: കസ്റ്റമർ ഗേറ്റ്വേ വിലാസവും ലോക്കൽ CIDR-ഉം നിങ്ങളുടേതാണ്, റിമോട്ട് CIDR VPC-യുടേതാണ്. strongSwan രണ്ട് അറ്റങ്ങളെ left, right എന്ന് വിളിക്കുന്നു, നിങ്ങളുടെ പ്രിഫിക്സ് leftsubnet-ൽ, VPC-യുടെ പ്രിഫിക്സ് rightsubnet-ൽ. ഒരു ജോഡി മറിച്ചിട്ടാൽ തെറ്റായ ട്രാഫിക് ചർച്ച ചെയ്ത് തിരഞ്ഞെടുക്കുന്ന ടണൽ ഉണ്ടാകും.

AWS ബന്ധത്തിനായി നിർമ്മിക്കുന്ന കോൺഫിഗറേഷൻ ഡൗൺലോഡ് ചെയ്ത് ടണൽ വിലാസങ്ങളും പ്രിഫിക്സുകളും ഉൾപ്പെടെ അതേ ബന്ധത്തിന്റെ റഫറൻസായി കണക്കാക്കുക. നിർമ്മിക്കുമ്പോൾ രണ്ട് CIDR ഫീൽഡുകളും ശൂന്യമായി വിട്ടാൽ സേവനം ഓരോ വശത്തും സ്ഥിരസ്ഥിതി 0.0.0.0/0 ഉപയോഗിക്കുന്നു. ഇടുങ്ങിയ പ്രിഫിക്സോടെ ക്രമീകരിച്ച റൂട്ടർ അപ്പോൾ ഒരിക്കലും പൊരുത്തപ്പെടുകയില്ല, അതിനാൽ ഫീൽഡുകൾ പൂരിപ്പിക്കുക അല്ലെങ്കിൽ സെലക്ടർ ബോധപൂർവം വിശാലമാക്കുക.

ഇവിടത്തെ പൊരുത്തക്കേട് റൂട്ടിംഗ് പരാജയമായി തോന്നുന്നു, അതല്ല.

AWS യഥാർത്ഥത്തിൽ കാണുന്ന വിലാസം ഉറപ്പിക്കുക

NAT-ന് പിന്നിലുള്ള റൂട്ടർ എതിർവശം ഒരിക്കലും അറിയാത്ത ഇന്റർഫേസിൽ നിന്ന് IKE അയക്കാം. AWS-ൽ രേഖപ്പെടുത്തുന്ന ഗേറ്റ്വേ വിലാസം AWS നെറ്റ്വർക്കിൽ കാണുന്നതായിരിക്കണം, കൂടാതെ റൂട്ടർ സ്വന്തം സ്ഥിരസ്ഥിതി റൂട്ട് പിന്തുടരുന്നതിനുപകരം അതേ ലോക്കൽ വിലാസത്തിൽ ഉറപ്പിക്കണം.

conn %default
    local_addrs = 203.0.113.10

strongSwan-ൽ local_addrs IKE-യുടെ ഉറവിട വിലാസം തിരഞ്ഞെടുക്കുന്നു, പഴയ OpenSwan കോൺഫിഗറേഷനുകൾ അതേ ആശയം left എന്ന് എഴുതുന്നു. പൊതു വിലാസമുള്ള ഇന്റർഫേസിലേക്ക് അത് ചൂണ്ടിക്കാണിക്കുക, തുടർന്ന് NAT ഉപകരണത്തിൽ തന്നെ UDP 500, 4500 എന്നിവ ആ ഹോസ്റ്റിൽ എത്തുന്നുവെന്ന് പരിശോധിക്കുക, കാരണം മുൻ റൂട്ടറിൽ നിന്ന് ബാക്കിയായ നിയമം അവയെ നിശ്ശബ്ദമായി ഉപേക്ഷിക്കുന്നു. ശരിയായ സെലക്ടർ ജോഡി തെറ്റായ ഉറവിട വിലാസത്തോടെയും പരാജയപ്പെടും, ലോഗ് നിർദ്ദേശത്തെ കുറ്റപ്പെടുത്തും. ഈ തെറ്റായ വഴികാട്ടലാണ് ഉറവിട വിലാസത്തിന് പ്രത്യേക പരിശോധന വേണ്ടതിന്റെ കാരണം.

ഫോർവേഡിംഗ് നിയമം അനുമാനിക്കുന്നതിനുപകരം സ്ഥിരീകരിക്കുക, കാരണം മുൻ റൂട്ടറിന് ശരിയായിരുന്ന നിയമം പലപ്പോഴും അവശേഷിക്കുന്നു.

ഘട്ടം 1, ഘട്ടം 2 എന്നിവ വെവ്വേറെ കൈകാര്യം ചെയ്യുക

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

വാക്യഘടന നിർവ്വഹണങ്ങൾക്കിടയിൽ സഞ്ചരിക്കുന്നില്ല. OpenSwan-ൽ പ്രവർത്തിക്കുന്ന ജോഡി, ഉദാഹരണത്തിന് phase2alg=aes_gcm എന്നത് ike=aes256-sha1;modp1024-നൊപ്പം, strongSwan-ന്റെ esp=, ike= രൂപത്തിലേക്ക് വിവർത്തനം ചെയ്യണം, അൽഗോരിതം പേരുകളും വ്യത്യസ്തമാണ്. GCM എൻക്രിപ്റ്റ് ചെയ്യുമ്പോൾ തന്നെ പ്രാമാണീകരിക്കുന്നതിനാൽ, SHA-യുമായി ജോടിയാക്കിയ CBC സെറ്റിൽ നിന്ന് വ്യത്യസ്തമായി അതിന് വേറിട്ട സമഗ്രതാ പരിവർത്തനം ആവശ്യമില്ല. ഒരു ഡീമണിൽ നിന്ന് മറ്റൊന്നിലേക്ക് വിവർത്തനമില്ലാതെ ഒട്ടിച്ച ഘട്ടം 2 വരി സെലക്ടർ പൊരുത്തക്കേടായി വായിക്കുന്ന നിരസനം ഉണ്ടാക്കുന്നു.

ടണൽ സൂചകമല്ല, ചൈൽഡ് അസോസിയേഷൻ പരിശോധിക്കുക

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

ipsec statusall

ചൈൽഡ് സുരക്ഷാ അസോസിയേഷൻ കണ്ടെത്തി അതിനരികിൽ അച്ചടിച്ച ട്രാഫിക് സെലക്ടറുകൾ വായിക്കുക, തുടർന്ന് അവ നിർമ്മിച്ച കോൺഫിഗറേഷന്റെ പ്രിഫിക്സുകളുമായി താരതമ്യം ചെയ്യുക.

ലോക്കൽ പ്രിഫിക്സിനുള്ളിലെ ഹോസ്റ്റിൽ നിന്ന് VPC പ്രിഫിക്സിനുള്ളിലെ ഹോസ്റ്റിലേക്ക് പരീക്ഷിക്കുക, തിരിച്ചുവരവ് പാതയും AWS വശത്തെ സുരക്ഷാ ഗ്രൂപ്പോ നെറ്റ്വർക്ക് ACL-ഓ പരിശോധിക്കുക. ശരിയായ സെലക്ടറുകൾ പാക്കറ്റ് പിന്നീട് ഉപേക്ഷിക്കപ്പെടുന്നതിൽ നിന്ന് സംരക്ഷിക്കുന്നില്ല.

സെലക്ടറുകൾ പൊരുത്തപ്പെട്ടതിന് ശേഷവും പരാജയപ്പെടുമ്പോൾ

ഇരുവശത്തുമുള്ള റൂട്ട് ടണലിലേക്കാണെന്ന് സ്ഥിരീകരിക്കുക, തുടർന്ന് NAT ഉപകരണം നയം പ്രതീക്ഷിക്കാത്ത രീതിയിൽ ട്രാഫിക് പുനഃഎഴുതുന്നില്ലെന്ന് സ്ഥിരീകരിക്കുക. നയാധിഷ്ഠിത ടണൽ പാക്കറ്റ് വിലാസങ്ങൾ പൊരുത്തപ്പെടുത്തുന്നു, അതിനാൽ നയ തീരുമാനത്തിന് ശേഷം പ്രയോഗിക്കുന്ന വിവർത്തനം ഫലം മാറ്റുന്നു.

മറ്റൊരു നിർദ്ദേശം മാറ്റുന്നതിന് മുമ്പ് ഓരോ വശത്തും ഒരു ഇൻ, ഒരു ഔട്ട് പാക്കറ്റ് ലോഗ് ചെയ്യുക.

ടിക്കറ്റിൽ സെലക്ടറുകൾ, ഘട്ടം 1, ഘട്ടം 2 നിർദ്ദേശങ്ങൾ, ഉറവിട വിലാസം രേഖപ്പെടുത്തുക. ഈ നാല് മൂല്യങ്ങൾ കോളില്ലാതെ മിക്ക site-to-site പരാജയങ്ങളും വിശദീകരിക്കുന്നു.

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