VPN സഹപ്രവർത്തകൻ മറ്റ് ഇന്റർഫേസുകളിലേക്ക് പിംഗ് ചെയ്യുന്നത് അവ ലോക്കൽ ആയതിനാലാണ്

ഒരു WireGuard ക്ലൈന്റ് കണക്ട് ചെയ്ത് തികച്ചും വേറിട്ട ഒരു ഇന്റർഫേസിലുള്ള വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യുന്നു, മറുപടി എത്തുന്നു. ക്യാപ്ചറുകൾ കാണിക്കുന്നത് അഭ്യർത്ഥന ടണലിൽ മാത്രമാണെന്നാണ്. ഒന്നും തകർന്നിട്ടില്ല, സൂക്ഷ്മതയോടെ അപ്രാപ്തമാക്കിയ ഫോർവേഡിംഗ് ക്രമീകരണത്തിന് ഇതുമായി യാതൊരു ബന്ധവുമില്ല. ഡയഗ്രാമിൽ സമാനമായി തോന്നുന്ന, എന്നാൽ കേർണലിൽ തികച്ചും വ്യത്യസ്തമായ രണ്ട് പാതകളുടെ താരതമ്യമാണിത്.

ഒരു പാത മറ്റൊരാൾക്കുവേണ്ടി പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യുന്നു; മറ്റേത് അവ ഹോസ്റ്റിനുതന്നെ എത്തിക്കുന്നു.

ഹോസ്റ്റിനെ ലക്ഷ്യമിടുന്ന പാക്കറ്റ് ഹോസ്റ്റിൽത്തന്നെ തുടരുന്നു

വിദൂര ക്ലൈന്റ് ഹോസ്റ്റിനുള്ള ഒരു വിലാസത്തിലേക്ക് IP പാക്കറ്റ് അയയ്ക്കുന്നു. റൂട്ടിംഗ് ആ പാക്കറ്റിനെക്കുറിച്ച് ഒരു ചോദ്യം ചോദിക്കുന്നു: ഈ ലക്ഷ്യസ്ഥാനം ലോക്കൽ ആണോ? ഹോസ്റ്റിനുള്ള ഓരോ വിലാസവും ലോക്കൽ റൂട്ടിംഗ് പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നു, കൂടാതെ ആ പട്ടിക പ്രധാന പട്ടികയ്ക്ക് മുമ്പ് പരിശോധിക്കുന്നു, അതിനാൽ പാക്കറ്റ് മറ്റൊരു ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നതിനുപകരം ഹോസ്റ്റിന്റെ സ്വന്തം സ്റ്റാക്കിലേക്ക് പോകുന്നു. മറുപടി ലോക്കലായി സൃഷ്ടിക്കപ്പെടുന്നു, അന്വേഷണം അവിടെനിന്നാണ് വന്നത് എന്നതിനാൽ അത് ടണലിലൂടെ തിരികെ വരുന്നു.

ഇതാണ് മുഴുവൻ സംവിധാനം. ഫോർവേഡിംഗ് നടക്കുന്നില്ല, ഇന്റർഫേസ് അവസ്ഥയിലെ മാറ്റം ഉൾപ്പെടുന്നില്ല, കൂടാതെ പരാമർശിച്ച വിലാസം മറ്റെവിടെനിന്നും എത്താവുന്നതായിരിക്കണമെന്നില്ല.

ip_forward ബാധകമാകാത്തത് എന്തുകൊണ്ട്

വന്ന ഇന്റർഫേസിൽനിന്ന് വ്യത്യസ്തമായ ഒരു ഇന്റർഫേസിലൂടെ പുറത്തുപോകേണ്ട പാക്കറ്റുകളെയാണ് ഫോർവേഡിംഗ് നിയന്ത്രിക്കുന്നത്. ഹോസ്റ്റിനോടുതന്നെയുള്ള പിംഗ് ആ പാത ഒരിക്കലും സ്വീകരിക്കുന്നില്ല: പാക്കറ്റ് ലോക്കലായി ഉപയോഗിക്കപ്പെടുന്നു, മറുപടി ലോക്കലായി സൃഷ്ടിക്കപ്പെടുന്നു. അതിനാൽ net.ipv4.ip_forward=0 സജ്ജമാക്കുന്നത് ഇവിടെ ഒന്നും മാറ്റുന്നില്ല, ഫോർവേഡ് ചെയിനിലെ ഒരു നിയമവും ആ ട്രാഫിക് ഒരിക്കലും കാണുന്നില്ല. ശരിയായ നിയന്ത്രണം ഇൻപുട്ട് പാതയിലാണ്, വരുന്ന ഇന്റർഫേസ് അല്ലെങ്കിൽ ഉറവിടം കൊണ്ട് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

അതുകൊണ്ടാണ് ഫോർവേഡിംഗ് ഓഫാക്കി ഹോസ്റ്റ് ഒറ്റപ്പെട്ടതാണെന്ന് കരുതുന്നത് സുരക്ഷയുടെ തെറ്റായ തോന്നൽ ഉണ്ടാക്കുന്നത്.

തീരുമാനിച്ച ലോക്കൽ പട്ടിക വായിക്കുക

ip rule show സാധാരണയായി പൂജ്യം മുൻഗണനയുള്ള ഒരു നിയമം റിപ്പോർട്ട് ചെയ്യുന്നു, അത് എല്ലാ തിരച്ചിലുകളും ആദ്യം ലോക്കൽ പട്ടികയിലേക്ക് അയയ്ക്കുന്നു, ip route show table local ഹോസ്റ്റിന്റെ സ്വന്തം വിലാസങ്ങൾ ലോക്കൽ പരിധിയോടെ പട്ടികപ്പെടുത്തുന്നു. ആ പട്ടികയിൽ ഭരണപരമായി ഓഫാക്കിയെങ്കിലും ഇപ്പോഴും കോൺഫിഗർ ചെയ്ത ഇന്റർഫേസുകളിലെ വിലാസങ്ങളും ഉൾപ്പെടുന്നു. സ്ഥിരമായി അനുവദിച്ച IPv4 വിലാസങ്ങൾ സാധാരണയായി ലിങ്ക് വിച്ഛേദനത്തെ അതിജീവിക്കുന്നു, അങ്ങനെയാണ് ഓഫാക്കിയ ബ്രിഡ്ജിലേക്കുള്ള പിംഗ് ഇപ്പോഴും വിജയിച്ച് ഓപ്പറേറ്ററെ അത്ഭുതപ്പെടുത്തുന്നത്.

IPv6 കൃത്യമായി ഈ വിഷയത്തിൽ വ്യത്യസ്തമാണ്. ലിങ്ക് വീഴുമ്പോൾ അതിന്റെ വിലാസങ്ങൾ സാധാരണയായി പിൻവലിക്കുന്നു, keep_addr_on_down സജ്ജമാക്കിയിട്ടില്ലെങ്കിൽ. ഒരു നിയമം രണ്ടിനെയും ഉൾക്കൊള്ളുന്നു എന്ന് കരുതുന്നതിനുപകരം കുടുംബങ്ങളെ താരതമ്യം ചെയ്യുക.

ഒരു സഹപ്രവർത്തകൻ യഥാർത്ഥത്തിൽ എത്തുന്നത് എവിടെവരെ

ഒരു സെഗ്മെന്റിൽ റൂട്ടറിന്റെ സ്വന്തം വിലാസത്തിൽനിന്നുള്ള മറുപടി ആ സെഗ്മെന്റിന് പിന്നിലെ യന്ത്രങ്ങളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. സഹപ്രവർത്തകന് ഈ പാതയിലൂടെ മറ്റേ ഇന്റർഫേസിന് പിന്നിലുള്ള ഹോസ്റ്റിൽ എത്താൻ കഴിയില്ല; റൂട്ടർ സ്വയം കൈവശം വയ്ക്കുന്ന വിലാസങ്ങളിൽ മാത്രമേ എത്തുന്നുള്ളൂ. റൂട്ടറിന്റെ വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യുന്നതിനുപകരം വേറിട്ട ഒരു LAN ഹോസ്റ്റിൽ സേവനം പരീക്ഷിക്കുന്നതാണ് ഫോർവേഡിംഗ് ഒട്ടേറെ അനുവദനീയമാണോ എന്ന് നിർണ്ണയിക്കുന്നത്.

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

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