മറുപടിയില്ലാത്ത പുറത്തേക്കുള്ള ESP എന്നത് VPN പ്രവർത്തിക്കുന്നില്ല എന്ന് അർത്ഥമാക്കുന്നില്ല
ESP ഓരോ അസോസിയേഷനിലും ഒരു ദിശ സംരക്ഷിക്കുന്നു, ഒന്നും സ്ഥിരീകരിക്കുന്നുമില്ല. സർവറിനെ പ്രതികരിക്കുന്നില്ല എന്ന് വിളിക്കും മുൻപ് ആന്തരിക സംഭാഷണവും ഇൻബൗണ്ട് SA-യും ഒത്തുനോക്കുക.
നിങ്ങൾ IPsec ഹോസ്റ്റിൽ ട്രാഫിക് ക്യാപ്ചർ ചെയ്തു, ESP പാക്കറ്റുകൾ പുറത്തേക്ക് പോകുന്നത് കണ്ടു, ഒന്നും തിരികെ വരുന്നില്ലെന്ന് കണ്ടു, ദൂരെയുള്ള വശം കേടായിരിക്കുന്നു എന്ന് അനുമാനിച്ചു. ആ അനുമാനത്തെ ക്യാപ്ചർ പിന്തുണയ്ക്കുന്നില്ല. ESP ഒരു സംഭാഷണത്തിന്റെ ഒരു ദിശ മാത്രം സംരക്ഷിക്കുന്നു, IP പാളിയിൽ ഒന്നും സ്ഥിരീകരിക്കുന്നുമില്ല, അതിനാൽ തിരികെ വരുന്ന ESP ഇല്ലാത്തത് ആപ്പിന് പറയാൻ ഒന്നുമില്ലായിരുന്നു എന്നും ടണൽ കേടായി എന്നും ഒരുപോലെ അർത്ഥമാക്കാം. ഏതെങ്കിലും വശത്തെ കുറ്റപ്പെടുത്തും മുൻപ് ആന്തരിക കൈമാറ്റവും സ്വീകരണ വശത്തിന്റെ അവസ്ഥയും വായിക്കുക.
കെട്ടുകഥ: സംരക്ഷിതമായ ഓരോ പാക്കറ്റും ഒരു മറുപടി നേടുന്നു
ESP ഒരു അഭ്യർത്ഥന-പ്രതികരണ പ്രോട്ടോക്കോൾ അല്ല. പോളിസി തിരഞ്ഞെടുക്കുന്നതെല്ലാം അത് എൻക്രിപ്റ്റ് ചെയ്ത് ആധികാരികമാക്കുന്നു, സ്വീകർത്താവ് ആ ആന്തരിക പാക്കറ്റ് സാധൂകരിച്ച് ഡീക്രിപ്റ്റ് ചെയ്ത് എത്തിക്കുന്നു, സ്വന്തമായി ഒരു പാക്കറ്റും സൃഷ്ടിക്കുന്നില്ല. ലക്ഷ്യസ്ഥാനം അവഗണിക്കുന്ന UDP ചോദ്യമോ ഇൻബൗണ്ട് പോളിസി ഉപേക്ഷിക്കുന്ന ICMP എക്കോയോ ഇരു ദിശകളിലും നിശ്ശബ്ദതയാണ് ശരിയായ ഫലമായി ഉണ്ടാക്കുന്നത്. ആ നിശ്ശബ്ദതയെ ഗതാഗത പരാജയമായി കാണുന്നത് ഒരിക്കലും ഉണ്ടായിരുന്നില്ലാത്ത ഒരു നെറ്റ്വർക്ക് തകരാറിനെ തേടി നിങ്ങളെ അയക്കുന്നു.
ഒരു ദിശയിലുള്ള ക്യാപ്ചർ യഥാർത്ഥത്തിൽ തെളിയിക്കുന്നത്, ആ നിരീക്ഷണ പോയിന്റിൽ അയച്ചയാളുടെ സ്റ്റാക്ക് എന്തോ എൻക്രിപ്റ്റ് ചെയ്തു എന്നു മാത്രമാണ്. എത്തിച്ചേരലിനെക്കുറിച്ച് ഒന്നുമില്ല, മറുപടി നൽകാനുള്ള ഉദ്ദേശ്യത്തെക്കുറിച്ചും ഒന്നുമില്ല. ഉപയോഗപ്രദമായ ചോദ്യം „എന്തുകൊണ്ട് മറുപടിയില്ല“ എന്നല്ല, „ആന്തരിക സംഭാഷണം എന്ത് ഉൽപ്പാദിപ്പിക്കേണ്ടിയിരുന്നു“ എന്നതാണ്.
രണ്ട് SA, രണ്ട് SPI, ഒരു സംഭാഷണം
IPsec സുരക്ഷാ അസോസിയേഷനുകൾ ഏകദിശയാണ്, അതിനാൽ സാധാരണ സംരക്ഷിത കൈമാറ്റം വെവ്വേറെ ഐഡന്റിഫയറുകളും സ്വതന്ത്ര അവസ്ഥയുമുള്ള ഒരു ഇൻബൗണ്ട് അസോസിയേഷനും ഒരു ഔട്ട്ബൗണ്ട് അസോസിയേഷനും ഉപയോഗിക്കുന്നു. ഔട്ട്ബൗണ്ട് പാക്കറ്റിന്റെ SPI-ക്കായി തിരികെ വരുന്ന ട്രാഫിക് തിരയുന്നത് അതിനാൽ ഒരു വിഭാഗീയ പിശകാണ്, കാരണം ഏതൊരു മറുപടിയും എതിർവശത്തിന്റെ സ്വന്തം ഔട്ട്ബൗണ്ട് SA-യ്ക്ക് കീഴിൽ അതിന്റെ സ്വന്തം SPI-യോടെയാണ് സഞ്ചരിക്കുന്നത്. പകരം ട്രാഫിക് സെലക്ടറുകളും എതിർവശത്തിന്റെ വിലാസങ്ങളും അനുസരിച്ച് ജോടി ചേർക്കുക.
കീ പുനഃസൃഷ്ടി ഒരു നിമിഷത്തേക്ക് ചിത്രം സങ്കീർണമാക്കുന്നു, കാരണം പഴയതും പകരക്കാരനുമായ അവസ്ഥ ഒന്നിച്ചു നിൽക്കാം. ലക്ഷണം ഒരു കീ മാറ്റത്തിന് ചുറ്റും തുടങ്ങിയതാണെങ്കിൽ, കണക്ഷന്റെ പേര് മാത്രമല്ല, അസോസിയേഷൻ ഐഡന്റിഫയറുകളും സമയമുദ്രകളും ഒരുമിച്ച് ശേഖരിക്കുക.
എന്തെങ്കിലും മറുപടി നൽകുന്നതിന് മുൻപ് സ്വീകർത്താവ് ചെയ്യേണ്ടത്
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ഓരോ വരിയും സ്വതന്ത്രമായി പരാജയപ്പെടുന്നു, ഓരോ പരാജയത്തിനും വ്യത്യസ്ത ഉടമയുണ്ട്, അതിനാൽ ഒരു ക്യാപ്ചറിന് അവയെ വേർതിരിക്കാനാവില്ല. ഇൻബൗണ്ട് കൗണ്ടർ മാത്രമാണ് എത്തിച്ചേരലിന്റെ നേരിട്ടുള്ള തെളിവ്, കാരണം ആധികാരികതയോ ആവർത്തന പരിശോധനയോ പരാജയപ്പെടുന്ന പാക്കറ്റ് ഒരു മറുപടിയുമില്ലാതെ ഉപേക്ഷിക്കപ്പെടുന്നു. അതിനാൽ ഇൻബൗണ്ട് കൗണ്ടർ അനങ്ങാത്ത എതിർവശം തങ്ങളുടെ പോളിസിയെക്കുറിച്ച് ഒരു വിവരവും നിങ്ങൾക്ക് നൽകുന്നില്ല.
ഡീക്രിപ്ഷനിൽ നിന്ന് വേറിട്ട ഒരു ഘട്ടമാണ് എത്തിക്കൽ. അവസ്ഥ സാധുവായിരിക്കാം, എന്നിട്ടും പാക്കറ്റ് പിന്നീട് ഇൻബൗണ്ട് പോളിസിയോ ആന്തരിക ലക്ഷ്യസ്ഥാനം ഉൾപ്പെടാത്ത ഒരു റൂട്ടോ ഉപേക്ഷിക്കാം, അതിനാൽ വൃത്തിയുള്ള കൗണ്ടർ എന്നാൽ പാക്കറ്റ് നിങ്ങൾ ആഗ്രഹിച്ചിടത്ത് പോയി എന്ന് അനുമാനിക്കാതെ ലക്ഷ്യ ഹോസ്റ്റ് പ്ലെയിൻടെക്സ്റ്റ് കണ്ടോ എന്ന് പരിശോധിക്കുക.
നേറ്റീവ് ESP UDP അല്ല
നേറ്റീവ് ESP IP പ്രോട്ടോക്കോൾ 50 ആണ്, അത് TCP-യോ UDP-യോ അല്ല, പോർട്ടുകൾ ഒട്ടുമില്ല. അതിനാൽ UDP 500-ൽ IKE അനുവദിക്കുന്ന ഒരു ഫയർവാൾ നിയമം ഡാറ്റാ പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, പോർട്ടുകൾക്ക് ചുറ്റും എഴുതിയ ഒരു ഫിൽട്ടർ ടണലിനെ ചർച്ച ചെയ്യാൻ അനുവദിച്ച് അതിനുള്ളിൽ കൊണ്ടുപോകുന്നതെല്ലാം ഉപേക്ഷിക്കാം. ഡാറ്റാ പാത നിങ്ങൾ യഥാർത്ഥത്തിൽ നിരീക്ഷിച്ച മോഡിൽ വെവ്വേറെ പരിശോധിക്കുക.
NAT-ന് പിന്നിൽ ചിത്രം മാറുന്നു: സംരക്ഷിത പേലോഡ് UDP-യ്ക്കുള്ളിൽ സഞ്ചരിക്കുന്നു, സാധാരണയായി 4500 പോർട്ടിൽ, RFC 3948 നിർവചിക്കുന്നതുപോലെ. ഏതെങ്കിലും നിയമം എഴുതും മുൻപ് സജീവ മോഡ് രേഖപ്പെടുത്തുക, കാരണം പാതയിലെ ഒരു ഉപകരണം നേറ്റീവ് ESP-യെയും UDP-യിൽ ഉൾക്കൊള്ളിച്ച ESP-യെയും തികച്ചും വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യാം, ചില മധ്യ ഉപകരണങ്ങൾ ഒന്ന് അനുവദിച്ച് മറ്റൊന്ന് ഉപേക്ഷിക്കുന്നു.
ഈ സംഭവത്തിന് ബാധകമായ കൗണ്ടറുകൾ വായിക്കുക
strongSwan ഹോസ്റ്റിൽ swanctl --list-sas ഇരു ദിശകളിലും ഓരോ അസോസിയേഷന്റെയും പാക്കറ്റ്, ബൈറ്റ് കൗണ്ടറുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, „ഒരിക്കലും എത്തിയില്ല“ എന്നതിൽ നിന്ന് „എത്തി, മറുപടി നൽകിയില്ല“ എന്നത് വേർതിരിക്കാൻ അത് മതിയാകും. Linux-ൽ /proc/net/xfrm_stat കാണാത്ത അവസ്ഥ, കാണാത്ത പോളിസി, പ്രോട്ടോക്കോൾ പിശകുകൾ തുടങ്ങിയ സംയോജിത പരാജയങ്ങൾ കണക്കാക്കുന്നു. ആ ആകെത്തുകകൾ ബൂട്ടിൽ നിന്ന് ശേഖരിക്കപ്പെടുന്നു, ഒരു നെറ്റ്വർക്ക് നെയിംസ്പേസിന് മാത്രം ബാധകമാണ്, അതിനാൽ വലിയ സംഖ്യ ഒരു ആരോപണമല്ല.
ശരിയായ നെയിംസ്പേസിൽ സംഭവത്തിന്റെ ജാലകത്തിന് ചുറ്റും രണ്ട് വായനകൾ എടുത്ത് വ്യത്യാസങ്ങൾ താരതമ്യം ചെയ്യുക, അല്ലാത്തപക്ഷം കഴിഞ്ഞ ആഴ്ചയിലെ പിശകുകൾ ഇന്ന് ഉച്ചയ്ക്കുശേഷമുള്ള ടിക്കറ്റിൽ ചേർക്കും. നെയിംസ്പേസും രണ്ട് സമയമുദ്രകളും ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക, അടുത്ത വായനക്കാരന് ആകെത്തുകയിൽ വിശ്വസിക്കാതെ താരതമ്യം വീണ്ടും നടത്താൻ കഴിയണം.
ഘട്ടത്തിന് പേരിടുക, സംശയിതനല്ല
ഉപയോഗപ്രദമായ ഒരു നിഗമനം പാക്കറ്റ് എവിടെ നിന്നു എന്ന് പറയുന്നു: ഒരിക്കലും ലഭിച്ചില്ല, ലഭിച്ച് ഉപേക്ഷിക്കപ്പെട്ടു, എത്തിച്ചു പക്ഷേ മറുപടിയില്ല, അല്ലെങ്കിൽ മറുപടി നൽകി തിരികെ വരും വഴി നഷ്ടപ്പെട്ടു. അവയിൽ ഓരോന്നും വ്യത്യസ്ത ഉടമയെയും വ്യത്യസ്ത അടുത്ത കമാൻഡിനെയും സൂചിപ്പിക്കുന്നു. „VPN സർവറിൽ നിന്ന് മറുപടിയില്ല“ എന്നത് നാല് വ്യത്യസ്ത തകരാറുകളെ ക്യാപ്ചർ ഒരിക്കലും ന്യായീകരിക്കാത്ത ഒരു വാക്യത്തിലേക്ക് ചുരുക്കുന്നു.
ക്യാപ്ചറുകൾ ഇടുങ്ങിയതായി സൂക്ഷിക്കുക, കെർണൽ യഥാർത്ഥ അവസ്ഥ ടിക്കറ്റുകളിൽ ഇടരുത്, കാരണം അതിൽ ഹോസ്റ്റ് വിടാൻ പാടില്ലാത്ത കീ മെറ്റീരിയൽ ഉണ്ടാകാം. കൗണ്ടർ വ്യത്യാസങ്ങളും സമയമുദ്രകളുമാണ് അടുത്ത ആളെ ഏൽപ്പിക്കാൻ യോഗ്യമായ ഭാഗങ്ങൾ.