ഹോസ്റ്റ് ബിറ്റുകൾ കാരണം റൂട്ട് നിരസിക്കപ്പെട്ടോ? ഉദ്ദേശിച്ച പ്രിഫിക്സ് കണ്ടെത്തുക
നിരസിക്കപ്പെട്ട റൂട്ട് വരി സാധാരണയായി ഹോസ്റ്റ് ബിറ്റുകൾ കാരണമാണ്, ഫോർവേഡിംഗ് പ്രശ്നമല്ല. മാസ്ക് വിശാലമാക്കുന്നതിനുപകരം ഉദ്ദേശിച്ച പ്രിഫിക്സ് നിർണ്ണയിക്കുക.
നിങ്ങളുടെ റൂട്ട് വരി നിരസിക്കപ്പെട്ട് തിരികെ വരുന്നു, കണ്ടെത്തുന്ന ഉപദേശം IP ഫോർവേഡിംഗ് പ്രവർത്തനക്ഷമമാക്കാൻ പറയുന്നു. ഈ രണ്ട് കാര്യങ്ങളും പ്രശ്നത്തിന്റെ വ്യത്യസ്ത ഘട്ടങ്ങളിലാണ്. ഫോർവേഡിംഗ് ഹോസ്റ്റിന് ഇന്റർഫേസുകൾക്കിടയിൽ പാക്കറ്റുകൾ നീക്കാനാകുമോ എന്ന് തീരുമാനിക്കുന്നു; നിങ്ങൾ ടൈപ്പ് ചെയ്ത ലക്ഷ്യസ്ഥാനം സാധുവായ നെറ്റ്വർക്കാണോ എന്നതിനെക്കുറിച്ച് അതിന് അഭിപ്രായമില്ല. ആദ്യം പ്രിഫിക്സ് ശരിയാക്കുക, കാരണം പൊരുത്തപ്പെടാത്ത വിലാസവും മാസ്കും ഫോർവേഡിംഗ് രക്ഷിക്കില്ല.
പാർസർ യഥാർത്ഥത്തിൽ എന്തിനാണ് പരാതിപ്പെടുന്നത്
വിലാസവും മാസ്കും ചേർത്ത് എഴുതിയ ലക്ഷ്യസ്ഥാനം ഒരു നെറ്റ്വർക്കിനെ വിവരിക്കണം, നെറ്റ്വർക്ക് പൂജ്യമാക്കിയ ഹോസ്റ്റ് ബിറ്റുകളിൽ തുടങ്ങുന്നു. നൽകിയ വിലാസത്തിൽ ഇപ്പോഴും ഹോസ്റ്റ് ഭാഗത്ത് മൂല്യമുണ്ടെങ്കിൽ, ജോടി ആന്തരികമായി പൊരുത്തക്കേടുള്ളതാണ്: 172.20.130.0 പൂജ്യത്തിൽ അവസാനിക്കുന്നതിനാൽ വൃത്തിയായി തോന്നുന്നു, പക്ഷേ നാലാമത്തെ ഓക്ടെറ്റിലെ പൂജ്യം മാത്രമല്ല പ്രധാനം. ഇവിടെ വിട്ടുപോയ ബിറ്റുകൾ ഉള്ളത് മൂന്നാമത്തെ ഓക്ടെറ്റിലാണ്.
ഈ പൊരുത്തക്കേട് ഉപകരണങ്ങൾ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു. കർശനമായ പാർസറുകൾ വരി നിരസിച്ച് ഹോസ്റ്റ് ബിറ്റുകൾ പേരിടുന്നു. അയഞ്ഞ പാർസറുകൾ വിലാസം മാസ്ക് ചെയ്ത് നിങ്ങൾ ആവശ്യപ്പെടാത്ത എന്തോ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അത് മോശമാണ്, കാരണം കോൺഫിഗറേഷൻ ഇപ്പോൾ നിങ്ങൾ ഒരിക്കലും ഉദ്ദേശിക്കാത്ത ഒരു ശ്രേണി റൂട്ട് ചെയ്യുന്നു. Python-ന്റെ ipaddress മൊഡ്യൂൾ തിരഞ്ഞെടുപ്പ് നേരിട്ട് കാണിക്കുന്നു: കർശനമായ നെറ്റ്വർക്ക് പാർസിംഗ് പിശക് ഉയർത്തുന്നു, strict=False ഹോസ്റ്റ് ബിറ്റുകൾ മാസ്ക് ചെയ്യുന്നു. നിങ്ങളുടെ ക്ലയന്റ് പതിപ്പുകൾക്കിടയിൽ കർശനമോ അയഞ്ഞതോ പൊരുത്തക്കേടുള്ളതോ ആകാം, അതിനാൽ ശീലത്തിൽ വിശ്വസിക്കുന്നതിനുപകരം സന്ദേശം വായിക്കുക.
ഉദാഹരണം കൈകൊണ്ട് ചെയ്യുക
172.20.130.0-ൽ /20 മാസ്ക് ഉപയോഗിച്ച് എത്തേണ്ട ഒരു ടണൽ എടുക്കുക. /20 മൂന്നാമത്തെ ഓക്ടെറ്റിൽ നിന്ന് നാല് ബിറ്റുകൾ കടം വാങ്ങുന്നു, അതിനാൽ ആ ഓക്ടെറ്റ് 16-ന്റെ ഘട്ടങ്ങളിൽ മാത്രമേ കണക്കാക്കൂ: 0, 16, 32, തുടർന്ന് 240 വരെ. 130 എന്ന മൂല്യം 128-നും 143-നും ഇടയിലാണ്, അതായത് ചുറ്റുമുള്ള നെറ്റ്വർക്ക് 172.20.128.0-ൽ തുടങ്ങുന്നു, അവസാന ഓക്ടെറ്റ് പൂജ്യമാക്കിയ 172.20.130.0-ൽ നിന്നല്ല.
എഴുതുമ്പോൾ, ബ്ലോക്ക് 172.20.128.0 മുതൽ 172.20.143.255 വരെ നീളുന്നു, 4,096 വിലാസങ്ങൾ ഉൾക്കൊള്ളുന്നു. അതേ മൂല്യങ്ങൾ കർശനമല്ലാത്ത പാർസറിന് നൽകിയാൽ അത് നിങ്ങൾക്കുവേണ്ടി വരുത്തുന്ന മാറ്റം കാണിക്കുന്നു:
$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096യഥാർത്ഥത്തിൽ ഏത് ലക്ഷ്യസ്ഥാനമാണ് ഉദ്ദേശിച്ചതെന്ന് തീരുമാനിക്കുക
നിരസിക്കപ്പെട്ട വരി സാധാരണയായി മൂന്ന് ഉദ്ദേശങ്ങളിൽ ഒന്ന് മറയ്ക്കുന്നു, തിരഞ്ഞെടുക്കാൻ നിങ്ങൾക്ക് മാത്രമേ കഴിയൂ. ടണലിന് മുഴുവൻ ബ്ലോക്കും വേണമെങ്കിൽ, കാനോനിക്കൽ നെറ്റ്വർക്ക് വിലാസമായ 172.20.128.0/20 എഴുതുക. ടണലിന് 130 സെഗ്മെന്റ് മാത്രം വേണമെങ്കിൽ, മാസ്ക് തെറ്റായിരുന്നു, 172.20.130.0/24 ആണ് സത്യസന്ധമായ രൂപം. ഒരു യന്ത്രം മാത്രമാണ് ലക്ഷ്യമെങ്കിൽ, IPv4 ഹോസ്റ്റ് റൂട്ട് /32 ആണ് മാസ്ക് അങ്കഗണിതം ഉൾപ്പെടുന്നില്ല.
ഓരോന്നും വ്യത്യസ്ത അളവിലുള്ള ട്രാഫിക്ക് അനുവദിക്കുന്നു, പരാതി നിലയ്ക്കുന്നതുവരെ മാസ്ക് വിശാലമാക്കാതിരിക്കാനുള്ള യഥാർത്ഥ കാരണം അതാണ്. /16 മിക്കവാറും എല്ലായിടത്തും വരി സ്വീകരിക്കുന്നു, ടണലിലൂടെ റൂട്ട് ചെയ്യാൻ നിങ്ങൾ ഒരിക്കലും ഉദ്ദേശിക്കാത്ത ലക്ഷ്യസ്ഥാനങ്ങളിലേക്ക് ട്രാഫിക് അയയ്ക്കുന്നു. ഉദ്ദേശവുമായി പൊരുത്തപ്പെടുന്ന ഏറ്റവും ഇടുങ്ങിയ പ്രിഫിക്സ് എഴുതുക, തുടർന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന അടുത്ത ഹോപ്പിനെതിരെ അത് സ്ഥിരീകരിക്കുക, പാർസറിന്റെ നിശ്ശബ്ദതയ്ക്കെതിരെയല്ല.
ഫോർവേഡിംഗ് ഒരിക്കലും പരിഹാരമായിരുന്നില്ലാത്തത് എന്തുകൊണ്ട്
നിരസിക്കപ്പെട്ട റൂട്ട് ഒരിക്കലും ഫോർവേഡിംഗ് പാതയിലെത്തുന്നില്ല, അതിനാൽ net.ipv4.ip_forward മാറ്റുന്നത് ഫലം മാറ്റാൻ കഴിയില്ല. ആ ക്രമീകരണം പിന്നീട് പ്രധാനമാണ്, ഹോസ്റ്റിന് ഇന്റർഫേസുകൾക്കിടയിൽ പാക്കറ്റുകൾ കൈമാറേണ്ടിവരുമ്പോൾ, ടേബിൾ ശരിയാകുന്നതിന് മുമ്പ് അത് ഓണാക്കുന്നത് അടുത്തതായി ഏത് ഘട്ടം പരാജയപ്പെടുമെന്ന് മാത്രം മാറ്റുന്നു.
അതേ ബിന്ദുവിൽ മറ്റ് രണ്ട് കാര്യങ്ങളും പലപ്പോഴും കുറ്റപ്പെടുത്തപ്പെടുന്നു. റൂട്ട് സ്വീകരിക്കപ്പെട്ടാലും കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടിനോട് തോൽക്കാം, ശരിയായ തിരയലിന് ശേഷം ഫയർവാൾ നിയമം ട്രാഫിക് ഉപേക്ഷിച്ചേക്കാം. ഘട്ടങ്ങൾ വേർതിരിച്ച് നിർത്തുക: വാക്യഘടന, ഇൻസ്റ്റലേഷൻ, തിരഞ്ഞെടുപ്പ്, ഫിൽട്ടറിംഗ്. തെറ്റായ ഘട്ടത്തിൽ പ്രവർത്തിക്കുന്നത് ഉൽപ്പാദനക്ഷമമായി തോന്നുന്നു, കാരണം ഓരോ മാറ്റവും എന്തെങ്കിലും പുനരാരംഭിക്കുന്നു.
ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടും അത് നേടുന്ന പാതയും പരിശോധിക്കുക
ക്ലയന്റ് വരി സ്വീകരിച്ചാൽ, അത് എന്ത് ഇൻസ്റ്റാൾ ചെയ്തു, ബ്ലോക്കിനുള്ളിലെ പ്രതിനിധി വിലാസത്തിന് കേർണൽ ഏത് റൂട്ട് തിരഞ്ഞെടുക്കുന്നു എന്ന് നോക്കുക. ഇൻസ്റ്റാൾ ചെയ്ത പ്രിഫിക്സ് നിങ്ങൾ എഴുതിയതിൽ നിന്ന് വ്യത്യസ്തമാണെങ്കിൽ, ഒരു നോർമലൈസർ നിങ്ങൾക്കുവേണ്ടി പ്രവർത്തിച്ചു.
ബ്ലോക്കിനുള്ളിലെ ഒരു അംഗ വിലാസവും പുറത്തുള്ള ഒന്നും ചോദിക്കുക, താരതമ്യം ഒരു ആശ്വാസവരിയല്ലാതെ അർത്ഥവത്താകാൻ:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10നിങ്ങളുടെ പ്രിഫിക്സ് ശരിയാണെങ്കിൽ മൂന്നാമത്തെ ചോദ്യം ടണലിന് പുറത്ത് വീഴണം, വീഴുന്നില്ലെങ്കിൽ നിങ്ങൾ നിർമ്മിച്ച റൂട്ട് നിങ്ങൾ കരുതുന്നതിനേക്കാൾ വിശാലമാണ്. അടുത്ത ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് പ്രിഫിക്സ് എന്ത് ഉൾക്കൊള്ളേണ്ടതായിരുന്നു എന്ന് രേഖപ്പെടുത്തുക, കാരണം പാർസ് ചെയ്യുന്ന റൂട്ടും പ്രവർത്തിക്കുന്ന പാതയും വേറിട്ട നിരീക്ഷണങ്ങളായി തുടരുന്നു.