ESP കൃത്യമായി ഡീക്രിപ്റ്റ് ചെയ്യുന്നു, എന്നിട്ടും അകത്തെ പാക്കറ്റ് എങ്ങോട്ടും പോകുന്നില്ല

ESP റിസീവ് കൗണ്ടർ ഉയരുന്നു, ടണൽ ഉയർന്നു തന്നെ നിൽക്കുന്നു, എന്നാൽ ആപ്ലിക്കേഷന് പാക്കറ്റ് ഒരിക്കലും കാണുന്നില്ല. ഡീക്രിപ്ഷൻ നടന്നു, ഇന്റഗ്രിറ്റി പരിശോധന കടന്നു, പിന്നീട് സംരക്ഷിത പേലോഡ് യഥാർത്ഥത്തിൽ എന്താണെന്ന് റിസീവർ തീരുമാനിക്കേണ്ടിവന്നു. ആ അവസാന ഘട്ടത്തിലാണ് ഫോർമാറ്റ് പൊരുത്തക്കേട് പ്രത്യക്ഷപ്പെടുന്നത്, പുറത്തുനിന്ന് നോക്കുമ്പോൾ അത് ഫയർവാൾ പ്രശ്നത്തോട് ഒട്ടും സദൃശ്യമല്ല.

ലേബൽ കള്ളം പറയുമ്പോൾ എന്തു കാണാം

ക്ലയന്റ് ലോഗിൽ ഇതിനെ റൂട്ടിംഗ് കറുത്ത ദ്വാരത്തിൽ നിന്ന് വേർതിരിക്കുന്ന ഒന്നുമില്ല. രണ്ടും ആരോഗ്യമുള്ള ടണലിനൊപ്പം ആപ്ലിക്കേഷൻ സമയപരിധി കവിയൽ സൃഷ്ടിക്കുന്നു, അതുകൊണ്ടാണ് ആദ്യം കൗണ്ടറുകളെ കുറ്റപ്പെടുത്തുന്നത്.

ഉയരുന്ന റിസീവ് കൗണ്ടർ യഥാർത്ഥത്തിൽ നല്ല വാർത്തയാണ്: പാക്കറ്റുകൾ എത്തുന്നു, പ്രാമാണീകരിക്കപ്പെടുന്നു. എന്നാൽ ക്രിപ്റ്റോ പാളിക്ക് മുകളിലുള്ള എന്തിനെങ്കിലും അകത്തെ പാക്കറ്റിന് അർത്ഥമുണ്ടായിരുന്നു എന്നതിന് ഇത് തെളിവല്ല.

തരം ട്രെയിലറിൽ താമസിക്കുന്നു

സാധാരണ IPsec ടണൽ മോഡിൽ, ESP സംരക്ഷിക്കുന്ന പേലോഡിൽ പൂർണ്ണമായ അകത്തെ IP പാക്കറ്റ് ഉണ്ട്. ട്രെയിലറിലെ അടുത്ത ഹെഡർ ഫീൽഡ് ആ പേലോഡ് എന്താണെന്ന് വ്യക്തമാക്കുന്നു, അത് TCP പോർട്ടല്ല, പുറം ഹെഡറിലെ പ്രോട്ടോക്കോൾ നമ്പറല്ല, പ്രാരംഭ SPI, ക്രമ നമ്പർ ഫീൽഡിന്റെ ഭാഗവുമല്ല. RFC 4303 വിഭാഗം 2.6 അതിനെ പേലോഡ്-തരം ഫീൽഡായി നിർവചിക്കുന്നു, കൃത്യമായ ജോലിക്ക് കൃത്യമായ പേര്.

നിങ്ങൾ കാണുന്ന മൂല്യങ്ങൾ ചെറുതാണ്, ഓർത്തിരിക്കാൻ യോഗ്യവുമാണ്: IPv4 എന്നത് 4 (0x04), IPv6 എന്നത് 41 (0x29).

ആ സംഖ്യകൾ പ്രാദേശിക പതിവിൽ നിന്നല്ല, IANA പ്രോട്ടോക്കോൾ നമ്പർ അനുവദനങ്ങളിൽ നിന്നാണ് വരുന്നത്. IPv4 പ്രഖ്യാപിച്ച് IPv6 പാക്കറ്റ് പൊതിയുന്ന അയച്ചയാൾ ഫോർമാറ്റ് പൊരുത്തക്കേട് സൃഷ്ടിച്ചു, സ്വന്തം ലേബലിന് വിരുദ്ധമായ ബൈറ്റുകൾ ഒരു ഫയർവാൾ നിയമവും ശരിയാക്കുന്നില്ല.

സാധാരണ സംശയിതരിൽ നിന്ന് ഇതിനെ എങ്ങനെ വേർതിരിക്കാം

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

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

ആ തെളിവ് ആർക്കും നൽകാനാകുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഫോർമാറ്റ് ബഗ്ഗില്ല. ഒരു സിദ്ധാന്തമുണ്ട്, സെലക്ടറുകൾ തന്നെയാണ് ഇപ്പോഴും മികച്ച പന്തം.

അറ്റക്കുറുക്കം എന്തല്ല

ട്രാഫിക് കടന്നുപോകാൻ ഇന്റഗ്രിറ്റി പരിശോധനകൾ ഓഫ് ചെയ്യരുത്. ഇടനില റൂട്ടറിൽ എൻക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റുകൾ വീണ്ടും എഴുതരുത്, അത് പ്രവർത്തിക്കില്ല, ക്യാപ്ചറിൽ സഹായകമായി തോന്നുമ്പോഴും പ്രവാഹം നശിപ്പിക്കും. പോർട്ട് തടയുന്നു എന്ന സിദ്ധാന്തത്തിൽ ആപ്പിന് വീതിയേറിയ ഫയർവാൾ നിയമം തുറക്കരുത്. ഇവയൊന്നും ലേബൽ പൊരുത്തക്കേടിനെ തൊടുന്നില്ല.

സ്ഥിരീകരിച്ച പൊരുത്തക്കേട് സഹപ്രവർത്തക ഇംപ്ലിമെന്റേഷനിൽ നിന്നാണെങ്കിൽ, ഏറ്റവും ചെറിയ ശുദ്ധീകരിച്ച പുനരാവിഷ്കാരം സൂക്ഷിച്ച് അത് ആ ഇംപ്ലിമെന്റേഷന്റെ പിന്തുണയുള്ള ചാനലിലേക്ക് കൊണ്ടുപോകുക.

പ്രവാഹം പരിശോധിക്കുക, കൗണ്ടർ അല്ല

തിരുത്തലിന് ശേഷം യഥാർത്ഥ IPv6 പ്രവാഹം തുടക്കം മുതൽ അവസാനം വരെ പരീക്ഷിക്കുക: ടണലിലൂടെയുള്ള ആപ്പ് അഭ്യർത്ഥന, അതിന്റെ മറുപടി, ഓരോ വശവും കാണുന്ന വിലാസ ജോടി. ഉയരുന്ന ESP കൗണ്ടർ പാക്കറ്റുകൾ സ്വീകരിക്കപ്പെടുന്നു, പ്രാമാണീകരിക്കപ്പെടുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു. അകത്തെ പാക്കറ്റ് ഉപയോഗയോഗ്യമായിരുന്നോ എന്നതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

രണ്ട് ഫലങ്ങളും ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക. കൗണ്ടറിന്റെ ചലനവും പ്രവർത്തിക്കുന്ന പ്രവാഹവും ഒരുമിച്ചാൽ അത് അറ്റക്കുറുക്കമാണ്; കൗണ്ടറിന്റെ ചലനം മാത്രമാണെങ്കിൽ അത് തുടങ്ങുന്നതിന് മുൻപ് നിങ്ങൾക്കുണ്ടായിരുന്നത് തന്നെയാണ്.