route-gateway എന്നത് redirect-gateway അല്ല: യഥാർത്ഥത്തിൽ എന്താണ് മാറുന്നത്
ഈ ഓപ്ഷൻ OpenVPN ഇൻസ്റ്റാൾ ചെയ്യുന്ന റൂട്ടുകൾക്ക് അടുത്ത ഹോപ്പ് മാത്രം നൽകുന്നു. അത് നീക്കം ചെയ്യുന്നത് തള്ളിയ പൂർണ്ണ ടണൽ ഓഫ് ചെയ്യുന്നില്ല, തിരുത്തൽ റീഡയറക്ഷനിലാണ്.
നിങ്ങളുടെ ടണൽ ഉയരുന്നു, സ്വകാര്യ സബ്നെറ്റ് പ്രതികരിക്കുന്നു, ആരോ പ്രൊഫൈലിൽ നിന്ന് ഗേറ്റ്വേ വരി ഇല്ലാതാക്കിയിട്ടും സാധാരണ ബ്രൗസിംഗ് ഇപ്പോഴും VPN-നുള്ളിൽ അപ്രത്യക്ഷമാകുന്നു. ആ സംയോജനമാണ് തെറ്റായ നിർദ്ദേശം എഡിറ്റ് ചെയ്തതിന്റെ വിരലടയാളം. നീക്കം ചെയ്തത് ക്ലൈന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്ന റൂട്ടുകൾക്ക് അടുത്ത ഹോപ്പ് നൽകി; ട്രാഫിക് പിടിക്കുന്നത് തുടർന്നത് വേറെ എവിടെനിന്നോ വന്ന് സെർവർ തള്ളിയതാണ്. കവറേജും അടുത്ത ഹോപ്പും വെവ്വേറെ ജോലികളാണ്, അവയിൽ ഒന്ന് മാത്രമാണ് പൊതു ലക്ഷ്യങ്ങൾ ടണൽ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്നത്.
നിങ്ങൾ നീക്കിയ വരി അടുത്ത ഹോപ്പായിരുന്നു, പോളിസി സ്വിച്ചല്ല
ക്ലൈന്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഓരോ റൂട്ടിനും ചൂണ്ടിക്കാണിക്കാൻ ഒരു ഗേറ്റ്വേ വിലാസം വേണം, റൂട്ട് തന്നെ ഒന്നും പേരിട്ട് പറയാത്തപ്പോൾ ഗേറ്റ്വേ നിർദ്ദേശമാണ് ആ വിലാസത്തിന്റെ ഉറവിടം. അത് ഇല്ലാതാക്കിയാൽ ആ റൂട്ടുകൾക്ക് തൂങ്ങാൻ ഇടമില്ല, അതിനാൽ അവ ഇൻസ്റ്റാൾ ആകാതിരിക്കുകയോ എങ്ങും എത്താത്ത വഴിയിൽ വീഴുകയോ ചെയ്യും. സ്വകാര്യ സബ്നെറ്റ് അത്തരം ഒരു റൂട്ട് കൊണ്ടുനടന്നത് തന്നെയാണ്.
അതേസമയം അതിജീവിച്ച പെരുമാറ്റത്തിന് മറ്റൊരു രചയിതാവുണ്ട്: തള്ളിയ ബ്ലോക്കിലെ റീഡയറക്ഷൻ ഓപ്ഷൻ, അത് അതിന്റെ ഫ്ലാഗുകൾക്കനുസരിച്ച് സാധാരണ പുറത്തേക്കുള്ള ട്രാഫിക് ടണലിലേക്ക് നീക്കുന്നു. ഗേറ്റ്വേ നീക്കം ചെയ്യുന്നത് അതിനെ ഓഫ് ചെയ്യുന്നുമില്ല, ദുർബലമാക്കുന്നുമില്ല. ഫലം രണ്ട് അവസ്ഥകളിൽ ഏറ്റവും മോശമാണ്, പൊതു ട്രാഫിക് ഇപ്പോഴും പിടിച്ചെടുക്കപ്പെടുന്നു, ടണലിനെ ന്യായീകരിച്ച സ്വകാര്യ ലക്ഷ്യം ഇപ്പോൾ എത്തിച്ചേരാനാകാത്തതുമാണ്. അതുകൊണ്ടാണ് അതേ മനോഭാവത്തിൽ ചെയ്ത രണ്ടാമത്തെ എഡിറ്റും ഒന്നും മാറ്റാത്തത്.
നാല് ലിവറുകൾ, നാല് വ്യത്യസ്ത ജോലികൾ
ഈ ചർച്ചയിൽ നാല് നിർദ്ദേശങ്ങൾ പരസ്പരം മാറി ഉദ്ധരിക്കപ്പെടുന്നു, അവയിൽ ഒന്ന് മാത്രമാണ് കവറേജ് നിയന്ത്രിക്കുന്നത്, അതായത് ഏത് ലക്ഷ്യങ്ങളാണ് ടണലിലൂടെ പോകുന്നത്. രണ്ടാമത്തേത് റൂട്ടുകൾ ഉപയോഗിക്കുന്ന അടുത്ത ഹോപ്പ് നിശ്ചയിക്കുന്നു, മൂന്നാമത്തേത് ഒരു പ്രിഫിക്സ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു, നാലാമത്തേത് സെർവർ തള്ളിയ എല്ലാം എറിയുന്നു, വിന്യാസത്തിന് ആവശ്യമായ സ്വകാര്യ റൂട്ടുകൾ ഉൾപ്പെടെ. പട്ടിക അവയെ പേരിനനുസരിച്ചല്ല, അഡ്മിനിസ്ട്രേറ്റർ എന്ത് മാറ്റാൻ ശ്രമിക്കുന്നു എന്നതനുസരിച്ചാണ് ക്രമീകരിക്കുന്നത്, കാരണം ആശയക്കുഴപ്പം ഉണ്ടാക്കുന്നത് പേരുകളാണ്. അവയെ നാല് വ്യത്യസ്ത തീരുമാനങ്ങളായി കാണുക, യഥാർത്ഥത്തിൽ മാറ്റാൻ ആഗ്രഹിക്കുന്നത് തിരഞ്ഞെടുക്കുക.
പ്രായോഗികമായി നാലും പലപ്പോഴും ഒരേ തള്ളിയ ബ്ലോക്കിൽ, വരി വരിയായി എത്തുന്നു, ഇത് അവയെ ഒരു ക്രമീകരണത്തിന്റെ ഭാഗങ്ങളായി തോന്നിപ്പിക്കുന്നു. അങ്ങനെയല്ല, OpenVPN റെഫറൻസ് അവയെ വ്യത്യസ്ത മെക്കാനിസങ്ങളായി രേഖപ്പെടുത്തുന്നത് അതുകൊണ്ടാണ്. ഏത് തീരുമാനമാണ് മാറ്റുന്നതെന്ന് കണ്ടെത്തുക എന്നതാണ് ജോലി; എഡിറ്റ് ഒരു വരിയാണ്.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
തള്ളിയ വരി ഫിൽട്ടർ ചെയ്യുക, അടുത്ത ഹോപ്പ് നിലനിർത്തുക
നിങ്ങൾ എതിർക്കുന്ന കവറേജ് തള്ളിയ ഓപ്ഷനായി വന്നാൽ, ഇടുങ്ങിയ പ്രതികരണം ആ ഓപ്ഷനെ പേരെടുത്ത് അവഗണിച്ച് തള്ളിയ ബ്ലോക്കിന്റെ ബാക്കി അസ്പൃശ്യമായി വിടുക എന്നതാണ്. ഫിൽട്ടറായി എഴുതിയാൽ അത് താഴെയുള്ള വരി പോലെ കാണാം, അതിന്റെ സ്ഥാനം ബാധിക്കപ്പെട്ട ക്ലൈന്റിന്റെ പ്രൊഫൈലിലാണ്, സെർവർ കോൺഫിഗറേഷനിലല്ല.
pull-filter ignore "redirect-gateway"ഇടുങ്ങിയതാണ് കാര്യം. ഫിൽട്ടർ ഒരു ടെക്സ്റ്റ് പ്രിഫിക്സ് താരതമ്യം ചെയ്യുന്നതിനാൽ, ചെറിയ പാറ്റേൺ അടുത്ത ഹോപ്പ് നിർദ്ദേശത്തിനും യോജിക്കും, അത് സ്വകാര്യ റൂട്ടുകൾ ആശ്രയിക്കുന്ന വിവരം കൃത്യമായി അടർത്തിക്കളഞ്ഞ് യഥാർത്ഥ പിഴവ് പുതിയ വേഷത്തിൽ ആവർത്തിക്കുന്നു. ഫിൽട്ടർ തള്ളിയ ഓപ്ഷനുകളിൽ മാത്രമേ പ്രവർത്തിക്കൂ, അതിനാൽ പ്രാദേശികമായി എഴുതിയതോ നെറ്റ്വർക്ക് മാനേജർ അടിച്ചേൽപ്പിച്ചതോ ആയ തുല്യമായ വരിയെ ഒരിക്കലും തൊടുന്നില്ല. അതിന് ശേഷം വീണ്ടും കണക്ട് ചെയ്യുക, കാരണം ജീവനുള്ള സെഷൻ സെർവർ തള്ളിയത് വീണ്ടും വിലയിരുത്തുന്നില്ല.
പട്ടികയല്ല, തിരയൽ വായിക്കുക
പ്രൊഫൈൽ വീണ്ടും ലോഡ് ചെയ്ത ശേഷം രണ്ട് ലക്ഷ്യങ്ങൾ യഥാർത്ഥത്തിൽ എവിടെ പോകുമെന്ന് കേർണലിനോട് ചോദിക്കുക: ഒന്ന് സ്വകാര്യ പ്രിഫിക്സിനുള്ളിൽ, ഒന്ന് പൊതു ഇന്റർനെറ്റിൽ. പ്രധാന പട്ടികയുടെ മുഴുവൻ ഡംപ് വായിക്കാൻ ബുദ്ധിമുട്ടും തെറ്റായി വായിക്കാൻ എളുപ്പവുമാണ്, കാരണം ഒരു റൂട്ട് നിലനിൽക്കുകയും എന്നിട്ടും കൂടുതൽ നിർദ്ദിഷ്ട പൊരുത്തത്തിനോട് തോൽക്കുകയും ചെയ്യാം. പോളിസി അടിസ്ഥാന റൂട്ടിംഗിൽ നിയമം, പട്ടിക, ഉറവിട വിലാസം എന്നിവയും പരിശോധനയുടെ ഭാഗമാണ്.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 ഭാവം അറിയേണ്ടതാണ്, കാരണം അത് പഴയ ഡിഫോൾട്ട് എൻട്രി കാണാവുന്നതായി നിർത്തുമ്പോൾ അർദ്ധ-ഡിഫോൾട്ടുകളുടെ ഒരു ജോടി തിരയൽ നേടുന്നു. അതിനാൽ ഔട്ട്പുട്ടിലെ 0.0.0.0/0 വരി സ്വയം ഒന്നും തെളിയിക്കുന്നില്ല. പട്ടിക ഉത്തരം നൽകുന്നതായി തോന്നുന്ന ചോദ്യത്തിന് തിരയൽ ഉത്തരം നൽകുന്നു.
DNS, IPv6, സ്വകാര്യ റൂട്ട് എന്നിവ ഇപ്പോഴും പ്രവർത്തിക്കണം
ഒരു IPv4 റീഡയറക്ഷൻ നിരസിക്കുന്നത് റിസോൾവറിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ തള്ളിയ DNS ഓപ്ഷൻ റൂട്ടുകൾ ശരിയായി കാണുമ്പോഴും ചോദ്യങ്ങൾ ടണലിലേക്ക് അയയ്ക്കുന്നത് തുടരാം. IPv6 ഡിഫോൾട്ട് IPv4 പരിശോധന ഒരിക്കലും തൊടാത്ത ഒരു വിലാസ കുടുംബത്തിന് അതേ കാര്യം ചെയ്യാം. രണ്ടിനും അനുമാനത്തിന് പകരം വ്യക്തമായ തീരുമാനം വേണം. അതിന് ശേഷം സ്വകാര്യ സേവനം ഇപ്പോഴും പ്രതികരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം സ്വകാര്യ റൂട്ട് നഷ്ടപ്പെട്ട വിഭജിത ടണൽ വിഭജിത ടണലല്ല, അത് തകർന്നതാണ്.
ഒരു വിശാലമായ ഉപകരണം മുന്നറിയിപ്പിന് അർഹമാണ്: route-nopull ഓരോ തള്ളിയ റൂട്ടും ഓരോ തള്ളിയ DNS ഓപ്ഷനും എറിയുന്നു, അത് പൂർണ്ണ ടണൽ ഉറപ്പായും നിർത്തുകയും വിന്യാസം ആശ്രയിക്കുന്ന സ്വകാര്യ റൂട്ടുകൾ അത്രതന്നെ ഉറപ്പായും തകർക്കുകയും ചെയ്യുന്നു, അതിനാൽ ഒരു ഓപ്ഷനെ ലക്ഷ്യമിട്ട പേര് ഫിൽട്ടറിനെക്കാൾ വളരെ വലിയ ചുറ്റികയാണ് അത്. ഏത് മാറ്റത്തിനും ശേഷം സ്വകാര്യ ലക്ഷ്യം, പൊതു ലക്ഷ്യം, റിസോൾവർ എന്നിവ പരിശോധിക്കുക, പൂർത്തിയായ ഹാൻഡ്ഷേക്കിനെ ഹാൻഡ്ഷേക്കല്ലാതെ മറ്റൊന്നിന്റെയും തെളിവായി കാണരുത്.