PPP യുടെ peer വിലാസമോ VPN അന്ത്യ ബിന്ദുവോ: ഏതാണ് via യിലേക്ക് പോകുന്നത്

PPP ഇന്റർഫേസ് ഒരു സബ്നെറ്റായി വായിക്കുന്നതിനെ അതിന്റെ inet ഉം peer ഉം ഒരു ലിങ്കിന്റെ രണ്ട് അറ്റങ്ങളായി വായിക്കുന്നതുമായി താരതമ്യം ചെയ്ത്, നയ പട്ടിക ഏത് അടുത്ത ഹോപ്പ് സ്വീകരിക്കാമെന്ന് കാണുക.

PPP ഇന്റർഫേസിലെ ഒരു വരി VPN ബോക്സിലെ മിക്ക റൂട്ടിംഗ് തർക്കവും തീർക്കുന്നു: ഉള്ളിലെ വിലാസവും അതിനൊപ്പം അച്ചടിച്ച peer ഉം. ആ ജോടിയെ ചെറിയ സബ്നെറ്റായി വായിക്കൂ, ഇല്ലാത്ത ഗേറ്റ്വേ തിരയും. അതിനെ ഒരു ലിങ്കിന്റെ രണ്ട് അറ്റങ്ങളായി വായിക്കൂ, അടുത്ത ഹോപ്പ് വ്യക്തമാകും. ഇവിടത്തെ താരതമ്യം ആ രണ്ട് വായനകൾക്കിടയിലാണ്, കാരണം പിന്നീട് നിർമ്മിക്കുന്ന ഓരോ പട്ടികയും നിങ്ങൾ തിരഞ്ഞെടുത്തത് തന്നെ പാരമ്പര്യമായി സ്വീകരിക്കുന്നു. പുറത്തെ VPN അന്ത്യ ബിന്ദുവിനെക്കുറിച്ച് രണ്ടും ഒന്നും തീരുമാനിക്കുന്നില്ല.

ഒരു ഇന്റർഫേസ് വരിയുടെ രണ്ട് വായനകൾ

ഇന്റർഫേസ് inet 10.64.3.9 peer 10.64.3.1/32 എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന ഒരു സെഷൻ എടുക്കുക. സബ്നെറ്റ് വായന 10.64.3.9 നെ /32 ദ്വീപിലെ ഏകാന്ത ഹോസ്റ്റായി കണക്കാക്കി, അതിനപ്പുറം എന്തിലും എത്താൻ ഒരു റൂട്ടർ തിരയുന്നു. ലിങ്കിലെ മറ്റേ ഒരേയൊരു വിലാസം peer ആയതിനാൽ, ആ വായന ഒടുവിൽ 10.64.3.9 നെത്തന്നെ ഗേറ്റ്വേയായി നിർദ്ദേശിക്കുന്നു, ഇത് വൃത്താകൃതിയാണ്.

അന്ത്യ ബിന്ദു വായനയാണ് രേഖപ്പെടുത്തിയിട്ടുള്ളത്. പോയിന്റ്-ടു-പോയിന്റ് ഇന്റർഫേസിൽ peer ആ ഒരു ലിങ്കിന്റെ ദൂരെ അറ്റത്തെ പേര് പറയുന്നു, അതിനാൽ 10.64.3.1 ഉപയോഗിക്കാവുന്ന അടുത്ത ഹോപ്പ്, 10.64.3.9 എപ്പോഴും ഉറവിട വിലാസം മാത്രം.

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

സെഷൻ ഇതിനകം എന്ത് ഇൻസ്റ്റാൾ ചെയ്തു

നിങ്ങളുടെ സ്വന്തം പട്ടിക എഴുതുന്നതിന് മുൻപ് ലിങ്കിനൊപ്പം വന്നത് അച്ചടിക്കുക. പിന്തുണയുള്ള PPP സംയോജനം സാധാരണയായി സെഷൻ സജ്ജീകരിക്കുമ്പോൾ ഒരു ഡിവൈസ് പാതയും ഒരു peer പാതയും ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ആ രണ്ട് എൻട്രികളും ശരിയായ വായന ഇതിനകം കോഡ് ചെയ്യുന്നു.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 പോലുള്ള ഡിവൈസ് പാതയിൽ ഗേറ്റ്വേ ഉണ്ടാകില്ല, കാരണം ഇന്റർഫേസ് തന്നെയാണ് പാത. via ഉപയോഗിച്ച് peer നെ പേര് പറയുന്ന പാത വേറെ ആയുസ്സുള്ള വേറെ വസ്തുവാണ്, സെഷൻ വീഴുമ്പോൾ അത് അപ്രത്യക്ഷമാകും. രണ്ട് രൂപങ്ങളിൽ ഒന്ന് വീണ്ടും എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യുന്നു എന്ന് നോക്കാതെ സ്ഥിര പട്ടികയിലേക്ക് പകർത്തുന്നതാണ് പ്രവർത്തിക്കുന്ന ടണൽ വീണ്ടും ബന്ധിപ്പിച്ച ശേഷം അതിന്റെ പാത നഷ്ടപ്പെടുന്നതിന് സാധാരണ കാരണം.

ഓർമ്മയെ വിശ്വസിക്കുന്നതിന് പകരം രണ്ട് പട്ടികകളും താരതമ്യം ചെയ്യുക. main ൽ peer പാത ഉണ്ടെങ്കിലും നിങ്ങളുടെ അധിക പട്ടിക ശൂന്യമാണെങ്കിൽ, വിലാസ വരി ഒരിക്കലും പറയാത്ത ഒന്ന് നിങ്ങൾ പഠിച്ചു.

നിയമവും പട്ടികയും വെവ്വേറെ തീരുമാനങ്ങൾ

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

പകുതി ഡിഫോൾട്ട് പാത ഡിഫോൾട്ട് പാതയല്ല. ഒരു 0.0.0.0/1 IPv4 സ്ഥലത്തിന്റെ താഴത്തെ പകുതി മാത്രം ഉൾക്കൊള്ളുന്നു, അതിനാൽ എല്ലാം പിടിക്കാൻ ഉദ്ദേശിക്കുന്ന നയത്തിന് പൊരുത്തപ്പെടുന്ന 128.0.0.0/1 അല്ലെങ്കിൽ യഥാർത്ഥ default കൂടി വേണം. പ്രവർത്തിക്കുന്ന കോൺഫിഗ് വായിച്ച് രണ്ട് പകുതികളിൽ ഒന്ന് മാത്രം പകർത്തുന്നതാണ് ചില ലക്ഷ്യസ്ഥാനങ്ങളിൽ മാത്രം പൊട്ടുന്ന റൂട്ടിംഗ് ലൂപ്പിൽ ആളുകൾ കുടുങ്ങുന്ന വഴി.

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

തിരച്ചിലിനോട് നിങ്ങളുടെ അപ്ലിക്കേഷൻ ചോദിക്കുന്ന ചോദ്യം തന്നെ ചോദിക്കുക

ip route get ഒരു പാത പരിഹരിക്കുന്നു; ip route show സംഭരിച്ച എൻട്രികൾ ലിസ്റ്റ് ചെയ്യുന്നു, രണ്ടും ഒന്നും തെറ്റാകാതെ വ്യത്യസ്തമാകാം. ഉറവിട സന്ദർഭം ഉൾപ്പെടുത്തുക, കാരണം ഉറവിടാധിഷ്ഠിത നിയമങ്ങൾ തിരച്ചിൽ ഒരു ഉറവിടം കൊണ്ടുപോകുമ്പോൾ മാത്രം പൊരുത്തപ്പെടുന്നു.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

ശരിയായ തിരച്ചിലും ഒരു പാത തിരഞ്ഞെടുത്തു എന്ന് മാത്രം തെളിയിക്കുന്നു. മറുവശം ട്രാഫിക് സ്വീകരിക്കുന്നുണ്ടോ അല്ലെങ്കിൽ ഉത്തരം അതേ യുക്തിയിൽ തിരികെ വരാമോ എന്ന് അത് പറയുന്നില്ല.

താരതമ്യം മറിയുന്നിടം

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

പുറത്തേക്കുള്ള റൂട്ടിംഗ് ശരിയായി കാണപ്പെടുമ്പോൾ ഉത്തരങ്ങൾ അപ്രത്യക്ഷമാകുകയാണെങ്കിൽ, അവ തൊടുന്നതിന് മുൻപ് ഫലപ്രദമായ മൂല്യങ്ങൾ വായിക്കുക, പ്രഖ്യാപിത നയ കാരണമുണ്ടെങ്കിൽ മാത്രം അവ മാറ്റുക.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

രണ്ട് രൂപകൽപ്പനകൾക്കിടയിൽ തെളിവിന്റെ അടിസ്ഥാനത്തിൽ തിരഞ്ഞെടുക്കുക: അപ്ലിക്കേഷൻ PPP വിലാസത്തിൽ ബന്ധിതമാണെങ്കിൽ, ഉറവിട നിയമവും peer പാത പിടിക്കുന്ന പട്ടികയും മതി. ബോക്സ് അതിന്റെ പിന്നിലെ LAN നുവേണ്ടി ഫോർവേഡ് ചെയ്യുന്നുണ്ടെങ്കിൽ, ഇൻബൗണ്ട് സന്ദർഭവും തിരികെ വരുന്ന വഴിയും പൊരുത്തപ്പെടണം. പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, മുഴുവൻ യന്ത്രത്തിനും സാധൂകരണം അയച്ചുകൊടുക്കുന്നതിന് പകരം പാതയുടെ ഉടമസ്ഥത ശരിയാക്കുക.

അനുബന്ധ ലേഖനങ്ങൾ