മറുപടി ടണലിൽ നിന്നല്ല, LAN-ൽ നിന്നാണ് പുറത്തുപോകുന്നത്: എന്തുകൊണ്ട്, എങ്ങനെ

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

പുറത്തുപോകുന്ന പാക്കറ്റിനെ യഥാർത്ഥത്തിൽ നിർണ്ണയിക്കുന്നത് എന്താണ്

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

അതിനാൽ ടണലിൽ ലഭിച്ച അഭ്യർത്ഥന ഭൗതിക ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്ന മറുപടി ഉണ്ടാക്കാം, ഒരു ഉപകരണവും പിശക് റിപ്പോർട്ട് ചെയ്യാതെ ഒഴുക്ക് ഏകദിശയാകുന്നു. ടണലിനെക്കുറിച്ച് ഒരു നിഗമനത്തിലെത്തുന്നതിന് മുമ്പ് രണ്ട് ദിശകളും പരിശോധിക്കുക. തെറ്റായ ദിശയിലേക്ക് പോകുന്ന മറുപടി ടണൽ കൗണ്ടറുകളിൽ നിന്ന് അപ്രത്യക്ഷമാകുന്നു, അതുകൊണ്ടാണ് എന്തെങ്കിലും അയച്ചോ എന്നതിൽ രണ്ടറ്റവും യോജിക്കാത്തത്. ഒരു നിയമത്തെ സ്പർശിക്കുന്നതിന് മുമ്പ് ഏത് കൗണ്ടർ മാറിയെന്ന് ശ്രദ്ധിക്കുക.

പ്രാദേശിക സബ്നെറ്റ് എന്തുകൊണ്ട് വിജയിക്കുന്നു

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

ഈ അസമത്വമാണ് രോഗനിർണ്ണയം ആശയക്കുഴപ്പമാക്കുന്നത്. വിശാല ഇന്റർനെറ്റിൽ നിന്നുള്ള വിളിക്കാർ പ്രവർത്തിക്കുന്നു, കാരണം അവർ ഒരു പ്രാദേശിക റൂട്ടുമായും പൊരുത്തപ്പെടുന്നില്ല, അതേസമയം ഓഫീസ് പ്രിഫിക്സ് പങ്കിടുന്ന ഏക വിളിക്കാരൻ പരാജയപ്പെടുന്നു, ആരോ പരിശോധിക്കാൻ ഉപയോഗിക്കുന്നത് അതേ വിളിക്കാരനെയാണ്.

പിയർ കവറേജ് ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾ പോലെയല്ല

ടണൽ ഭാഗത്ത്, ഒരു പിയറിന്റെ അനുവദനീയമായ ശ്രേണികൾ ടണലിലേക്ക് എന്ത് അയക്കാമെന്നും അതിൽ നിന്ന് ഏത് ഉറവിടങ്ങൾ സ്വീകരിക്കുന്നുവെന്നും വിവരിക്കുന്നു. പ്രാദേശിക റൂട്ടിംഗ് പട്ടിക പാക്കറ്റ് എവിടേക്ക് അയക്കും എന്നതിനെക്കുറിച്ച് അവ ഒന്നും പറയുന്നില്ല.

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

ഉറവിട വിലാസം അനുസരിച്ച് പട്ടിക തിരഞ്ഞെടുക്കുക

ഉറവിട അടിസ്ഥാനമാക്കിയ നിയമം സേവന വിലാസത്തിൽ നിന്നുള്ള മറുപടികൾ സ്ഥിരമായി ടണൽ ആയ ഒരു സ്വകാര്യ പട്ടികയിലേക്ക് അയക്കുന്നു, ബാക്കിയെല്ലാം പ്രധാന പട്ടിക തുടർന്നും ഉപയോഗിക്കുന്നു. പ്രാദേശികമായി ഉപയോഗിക്കാത്ത പട്ടികയും മുൻഗണനാ നമ്പറുകളും തിരഞ്ഞെടുക്കുക, എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് നിലവിലുള്ള നിയമങ്ങൾ വായിക്കുക. സംരക്ഷിച്ച ഫയലല്ല, സജീവമായ നിയമങ്ങൾ വായിക്കുക, കാരണം റീബൂട്ടിന് ശേഷം രണ്ടും വ്യത്യാസപ്പെടാം.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

അവസാന വരി ഇല്ലാത്ത റൂട്ടിനെ പ്രാദേശിക ലിങ്കിലേക്ക് പിൻവാങ്ങുന്നതിന് പകരം ദൃശ്യമായി പരാജയപ്പെടുത്തുന്നു. ഉറവിടം യഥാർത്ഥത്തിൽ ഹോസ്റ്റിന് നൽകിയിരിക്കണം, സാധാരണ പ്രാദേശിക, പ്രധാന തിരയലുകൾ അവയുടെ മുൻപിലുള്ള സ്ഥാനങ്ങളിൽ തുടരണം. നിയമം ഉറവിടം അനുസരിച്ച് പട്ടിക തിരഞ്ഞെടുക്കുന്നു; അത് പട്ടികകൾക്കിടയിൽ പ്രിഫിക്സ് നീളങ്ങൾ താരതമ്യം ചെയ്യുന്നില്ല.

വഴി ഉറപ്പാക്കുക, എന്നിട്ട് സേവനം

ക്യാപ്ചറിൽ നിന്ന് ഊഹിക്കുന്നതിന് പകരം കേർണലിനോട് എന്ത് ചെയ്യുമെന്ന് ചോദിക്കുക, സേവന വിലാസം ഉറവിട സെലക്ടറായി ഉപയോഗിച്ച്. ഇവിടെ ശരിയായ ഉത്തരം ഒരു മുഴുവൻ പാക്കറ്റ് ട്രെയ്സ് ലാഭിക്കുന്നു.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

ഔട്ട്പുട്ടിൽ ടണലിന്റെ പേര് ഉണ്ടായിരിക്കണം. തുടർന്ന് നിങ്ങൾ സ്പർശിക്കാത്ത ഒരു ഉറവിടം പരീക്ഷിച്ച് അത് ഇപ്പോഴും പ്രാദേശിക ലിങ്ക് എടുക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, അങ്ങനെ മാറ്റം ഒരു വിലാസത്തിൽ മാത്രമായി നിൽക്കും. കൂടുതൽ വിശാലമായ സെലക്ടർ യഥാർത്ഥ പരാതിയെക്കുറിച്ച് ഒന്നും തെളിയിക്കില്ലായിരുന്നു.

ഇത് എന്താണ് ശരിയാക്കാത്തത്

ഗേറ്റ്വേയിലെ ഫോർവേഡിംഗ്, ഫയർവാൾ നിയമങ്ങൾ, ICMPv6 പെരുമാറ്റം എന്നിവ മുമ്പുണ്ടായിരുന്നതുപോലെ വയ്ക്കുക, കാരണം ഉറവിട റൂട്ട് അവയിലൊന്നും മാറ്റിസ്ഥാപിക്കുന്നില്ല. ഇല്ലാത്ത Packet Too Big സന്ദേശം ഏത് പട്ടിക തിരയലിൽ വിജയിച്ചാലും വലിയ മറുപടികൾ ഇപ്പോഴും തകർക്കുന്നു. റൂട്ടിംഗ് നിയമങ്ങൾ ചേർക്കുന്നതിന് മുമ്പ് അത് ശരിയാക്കുക, അല്ലെങ്കിൽ മാറ്റത്തിന് ശേഷവും ലക്ഷണം നിലനിൽക്കും.

ഇവയൊന്നും പ്രയോഗിക്കുന്നതിന് മുമ്പ് പ്രസിദ്ധീകരണ മാതൃക സ്ഥിരീകരിക്കുക. സ്വന്തം ബാക്കെൻഡ് കണക്ഷൻ തുറക്കുന്ന റിവേഴ്സ് പ്രോക്സി സ്വന്തം ഉറവിടം അവതരിപ്പിക്കുകയും വിളിക്കാരനെ സംരക്ഷിക്കാതിരിക്കുകയും ചെയ്യുന്നു, അതിനാൽ ആ രൂപകൽപ്പനയിൽ ഈ തകരാർ സംഭവിക്കാനാവില്ല. അവിടെ നിയമം പ്രയോഗിച്ചാൽ ഒന്നും പരിഹരിക്കാത്തതും യഥാർത്ഥ കാരണം മറയ്ക്കുന്നതുമായ ഒരു റൂട്ടിംഗ് ഒഴിവ് ചേർക്കും.

അവസാനമായി, നിയമ നമ്പറുകളും പട്ടികയും ഹോസ്റ്റിന്റെ കോൺഫിഗറേഷൻ മാനേജ്മെന്റിൽ എഴുതുക. കൈകൊണ്ട് ചേർത്ത നയനിയമം അടുത്ത പുനർനിർമ്മാണത്തിൽ അപ്രത്യക്ഷമാകും, ഓഫീസ് വിളിക്കാരൻ അതേ പരാതിയുമായി തിരിച്ചുവരും.