OpenVPN route-nopull യഥാർത്ഥത്തിൽ സർവർ എന്ത് തള്ളുന്നത് തടയുന്നു
route-nopull തള്ളിയ മാർഗങ്ങളും DHCP ഓപ്ഷനുകളും ഉപേക്ഷിക്കുന്നു, ഹാൻഡ്ഷേക്ക് അല്ല. അത്, pull-filter അല്ലെങ്കിൽ ഒന്നുമില്ല എന്നിവയിൽ നിന്ന് തിരഞ്ഞെടുത്ത്, പിന്നീട് മാർഗങ്ങൾ സ്വയം ചേർക്കുക.
ടണൽ നിങ്ങളുടെ ഡിഫോൾട്ട് റൂട്ട് വിഴുങ്ങാതിരിക്കാൻ ക്ലയന്റ് പ്രൊഫൈലിൽ route-nopull ഇട്ടു, ഇപ്പോൾ ഓഫീസ് സബ്നെറ്റ് എത്തിപ്പെടാനാകാത്തതാണ്, എന്നാൽ ക്ലയന്റ് ഇപ്പോഴും കണക്ട് ചെയ്തിരിക്കുന്നു എന്ന് പറയുന്നു. രണ്ട് നിരീക്ഷണങ്ങളും ശരിയാണ്, ഒന്നും പരാജയപ്പെട്ടിട്ടില്ല. സർവർ തള്ളുന്ന റൂട്ടുകളും DHCP എൻട്രികളും ഒഴിവാക്കാൻ ഈ ഫ്ലാഗ് ക്ലയന്റിനോട് പറയുന്നു, ഇത് ചേർക്കുമ്പോൾ മിക്ക ആളുകളും പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയ നിർദ്ദേശമാണ്. അവശേഷിക്കുന്നത്, ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ അത് ഉപയോഗിക്കണം എന്നതിനെക്കുറിച്ച് അഭിപ്രായമില്ലാത്ത പ്രവർത്തിക്കുന്ന ടണലാണ്.
ആ വിടവാണ് ഈ ലേഖനത്തിന്റെ വിഷയമായ മുഴുവൻ തീരുമാനം. ഒന്നുകിൽ സർവർ നെറ്റ്വർക്ക് വിവരണം നൽകുന്നു, അല്ലെങ്കിൽ ക്ലയന്റ്, ആ ജോലി നിങ്ങൾക്കുവേണ്ടി ഒന്നും ചെയ്യാതെ ഫ്ലാഗ് ക്ലയന്റിന് നൽകുന്നു.
കണക്ട് ചെയ്യുമ്പോൾ ഫ്ലാഗ് എന്ത് ഓഫ് ചെയ്യുന്നു
വലിക്കുന്ന OpenVPN ക്ലയന്റ് സാധാരണയായി പ്രാമാണീകരണത്തിന് ശേഷം സർവറിൽ നിന്ന് ഒരു കെട്ട് സ്വീകരിക്കുന്നു: റൂട്ടുകൾ, ഡിഫോൾട്ട് ഗേറ്റ്വേയുടെ വീണ്ടും വഴിതിരിച്ചുവിടൽ, DNS സർവറുകൾ, കുറച്ച് ട്യൂണിംഗ് നിർദ്ദേശങ്ങൾ. route-nopull നിലവിലുള്ളപ്പോഴും ക്ലയന്റ് സെഷൻ സ്വീകരിക്കുന്നു, സർട്ടിഫിക്കറ്റുകൾ പരിശോധിക്കുന്നു, സൈഫറുകളും keepalive-ഉം ചർച്ച ചെയ്യുന്നു, ഇന്റർഫേസ് ഉയർത്തുന്നു. ഉപേക്ഷിക്കുന്നത് തള്ളിയ route വരികളുടെയും തള്ളിയ dhcp-option വരികളുടെയും പ്രയോഗമാണ്, DNS ഉൾപ്പെടെ.
ആശയക്കുഴപ്പം മരിച്ച ആപ്പിന് അടുത്തുള്ള പച്ച സൂചകത്തിൽ നിന്ന് വരുന്നു. ടണൽ നിലവിലുണ്ട്; ലക്ഷ്യസ്ഥാനങ്ങളെ ആ ടണലിലേക്ക് മാപ്പ് ചെയ്യുന്നത് ഇല്ല. ക്ലയന്റിന്റെ സ്റ്റാറ്റസ് പാനലിൽ «കണക്ട് ചെയ്ത് റൂട്ട് ചെയ്യുന്നു» എന്നതും «കണക്ട് ചെയ്ത് നിഷ്ക്രിയം» എന്നതും തമ്മിൽ ഒന്നും വേർതിരിക്കുന്നില്ല, കാരണം ടണലിന്റെ വീക്ഷണത്തിൽ രണ്ടും ഒരേ അവസ്ഥയാണ്.
ജീവനുള്ള ടണലിന് എന്തുകൊണ്ട് ഒന്നും റൂട്ട് ചെയ്യാനാകുന്നില്ല
ഇന്റർഫേസ് സ്വന്തം വിലാസത്തോടെ പ്രത്യക്ഷപ്പെടുന്നു, പോയിന്റ്-ടു-പോയിന്റ് ലിങ്കിൽ പലപ്പോഴും പിയറിലേക്കുള്ള ഹോസ്റ്റ് റൂട്ടിനേക്കാൾ കൃത്യമായി ഒന്നുമില്ല. സ്വകാര്യ സബ്നെറ്റ് എത്തിപ്പെടാവുന്നത്, ശരിയായ പ്രിഫിക്സോടെ ഏതെങ്കിലും റൂട്ട് ആ ഇന്റർഫേസിലേക്ക് ചൂണ്ടുമ്പോൾ മാത്രമാണ്, തള്ളൽ ഓഫ് ചെയ്തിരിക്കുമ്പോൾ ആ റൂട്ട് ഒരിക്കലും വരുന്നില്ല. ഡൗൺലോഡ് ചെയ്ത പ്രൊഫൈലും സാധാരണയായി സഹായിക്കാനാകില്ല, കാരണം സർവർ കൃത്യമായി ഈ വിവരം നൽകുമെന്ന അനുമാനത്തിൽ അത് എഴുതപ്പെട്ടതാണ്. അതുകൊണ്ട് ഇന്റർഫേസ് ആരോഗ്യകരമായി തോന്നാം, സബ്നെറ്റ് ഇരുണ്ടതായി തുടരുമ്പോൾ.
അതിനാൽ പ്രൊഫൈൽ വായിക്കുന്നത് വളരെ കുറച്ച് മാത്രമാണ് തെളിയിക്കുന്നത്. പകരം കണക്ട് ചെയ്ത മെഷീനിൽ ഓടുന്ന അവസ്ഥ വായിക്കുക:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10രണ്ടാമത്തെ കമാന്റിൽ സബ്നെറ്റ് റൂട്ട് ഇല്ലാത്ത വിലാസമാണ് ഈ പ്രശ്നത്തിന്റെ ഒപ്പ്. മൂന്നാമത്തെ കമാന്റ് പിന്നീട് ഉപയോക്താക്കൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, കാരണം ഉപയോഗിക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിച്ച പട്ടികയല്ല, നിർദ്ദിഷ്ട ലക്ഷ്യത്തിന് കേർണൽ തിരഞ്ഞെടുക്കുന്ന ഇന്റർഫേസാണ് അത് റിപ്പോർട്ട് ചെയ്യുന്നത്. അത് നിങ്ങളുടെ ഭൗതിക ലിങ്കിലൂടെ ഉത്തരം നൽകുന്നുവെങ്കിൽ, ടണൽ വഴിയിൽ ഒട്ടുമില്ല.
പേര് നിർണ്ണയം വേറിട്ട ഒരു കാരണത്താലല്ല, ബന്ധപ്പെട്ട ഒരു കാരണത്താൽ പരാജയപ്പെടുന്നു. തള്ളിയ dhcp-option DNS എൻട്രികൾ അതേ ഫ്ലാഗ് ഒഴിവാക്കുന്നു, അതിനാൽ ആന്തരിക ഹോസ്റ്റുകൾക്കുള്ള ചോദ്യങ്ങൾ പ്രാദേശിക നെറ്റ്വർക്ക് നൽകിയ ഏത് റിസോൾവറിലേക്കും പോകുന്നു. ആ റിസോൾവറിന് ഓഫീസിന് സോൺ ഇല്ല, അതിനാൽ ചോദ്യം പരാജയപ്പെടുന്നു അല്ലെങ്കിൽ പൊതു ഉത്തരം നൽകുന്നു, പരാജയം സർവർ പ്രശ്നം പോലെ തോന്നുന്നു, യഥാർത്ഥത്തിൽ അത് ക്ലയന്റ് കോൺഫിഗറേഷൻ പ്രശ്നമാണ്. പേരിന് മുമ്പ് വിലാസം പരിശോധിക്കുന്നതാണ് രണ്ടിനെയും വേർതിരിക്കുന്നത്.
ഫ്ലാഗും പ്രിഫിക്സ് ഫിൽട്ടറും തമ്മിലുള്ള തിരഞ്ഞെടുപ്പ്
രണ്ട് ഓപ്ഷനുകളും ഒരേ പരാതിയുടെ വ്യത്യസ്ത രൂപങ്ങൾ പരിഹരിക്കുന്നു, മോശം തിരഞ്ഞെടുപ്പാണ് «കണക്ട് ചെയ്തെങ്കിലും ഉപയോഗശൂന്യം» എന്ന അവസ്ഥ സൃഷ്ടിക്കുന്നത്. ഒന്ന് തള്ളിയ നയം മുഴുവനായി മാറ്റിസ്ഥാപിക്കുന്നു, മറ്റൊന്ന് പ്രിഫിക്സ് അനുസരിച്ച് അത് തിരുത്തുന്നു. പട്ടിക ചെറിയ പതിപ്പ് നൽകുന്നു, അതിന് ശേഷമുള്ള ഖണ്ഡിക ആളുകളെ പിടിക്കുന്ന ഭാഗം ഉൾക്കൊള്ളുന്നു.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter മൂന്ന് ക്രിയകളുള്ള പ്രിഫിക്സ് പൊരുത്തക്കാരനാണ്, അതിനാൽ അത് വരികളുടെ ഒരു കുടുംബം സ്വീകരിക്കാം, നിശബ്ദമായി അവഗണിക്കാം, അല്ലെങ്കിൽ പ്രിഫിക്സ് പ്രത്യക്ഷപ്പെടുമ്പോൾ കണക്ഷൻ പൂർണ്ണമായി നിരസിക്കാം. അറിഞ്ഞിരിക്കേണ്ടത് അവസാന പെരുമാറ്റമാണ്: നിരസിക്കൽ നിയമം നയവ്യത്യാസത്തെ നിശബ്ദ ഒഴിവാക്കലല്ല, പരാജയപ്പെട്ട ഹാൻഡ്ഷേക്കാക്കി മാറ്റുന്നു. OpenVPN 2.6 സഹായി സ്വീകരിക്കുന്ന പ്രിഫിക്സുകളും ഓരോ ക്രിയയുടെയും കൃത്യമായ അർത്ഥവും വിവരിക്കുന്നു.
സാധാരണ മധ്യമാർഗം redirect-gateway മാത്രം നിരസിക്കുകയും ഓഫീസ് റൂട്ടുകളും DNS-ഉം ഉദ്ദേശിച്ചതുപോലെ വരാൻ അനുവദിക്കുകയും ചെയ്യുന്നതാണ്. ഇത് സർവർ നിങ്ങളെക്കാൾ നന്നായി മനസ്സിലാക്കുന്ന ഭാഗങ്ങൾക്ക് തള്ളൽ പ്രവർത്തിക്കുന്നതായി നിലനിർത്തുന്നു, അതേസമയം നിങ്ങളുടെ ഡിഫോൾട്ട് റൂട്ട് ഏറ്റെടുക്കുമായിരുന്ന ആ ഒരു വരി തടയുന്നു.
കൈകൊണ്ട് റൂട്ടുകളും റിസോൾവറും ചേർക്കൽ
ഫ്ലാഗ് നിലനിർത്തുന്നുവെങ്കിൽ, പ്രൊഫൈൽ സർവർ പറയുമായിരുന്നത് പറയണം. ക്ലയന്റ് വശത്തെ route നിർദ്ദേശങ്ങൾ കണക്ഷൻ സ്ഥാപിച്ചതിന് ശേഷം പ്രയോഗിക്കുന്നു, അതിനാൽ അവ ഫ്ലാഗിനൊപ്പം പ്രവർത്തിക്കുന്നു, അത് തടയുന്നില്ല. അവ പ്രൊഫൈലിൽ ഇടുക, സംവേദനാത്മക കമാന്റ് ലൈനിൽ അല്ല, അല്ലെങ്കിൽ അടുത്ത വീണ്ടും കണക്ഷൻ പ്രവർത്തിക്കുന്ന അവസ്ഥ പുനർനിർമ്മിക്കില്ല.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS വരി അസ്വസ്ഥമായ സ്ഥാനത്താണ്: അത് ക്ലയന്റ് വശത്തെ നിർദ്ദേശമാണ്, പക്ഷേ ചില ക്ലയന്റുകൾ അത് പ്ലാറ്റ്ഫോമിന്റെ DNS സംയോജനത്തിലൂടെ മാത്രമാണ് പ്രയോഗിക്കുന്നത്, ലിങ്ക് മാറുമ്പോൾ അത് അതിന് മുകളിൽ എഴുതിയേക്കാം. systemd ഹോസ്റ്റിൽ റിസോൾവർ നേരിട്ട് ടണൽ ഇന്റർഫേസിൽ സജ്ജീകരിക്കുന്നത് ക്ലയന്റ് മുൻഗണനാ മത്സരം ജയിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നതിനേക്കാൾ പ്രവചനീയമാണ്:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comറൂട്ടിംഗ് ഡൊമെയിൻ വിലാസത്തോളം തന്നെ പ്രധാനമാണ്. അതില്ലാതെ പൊതു പേരുകൾക്കുള്ള ചോദ്യങ്ങളും ആന്തരിക റിസോൾവറിലേക്ക് അയക്കാം, ആവർത്തനം നിരസിക്കുന്ന ഏത് ആന്തരിക റിസോൾവറും സ്വകാര്യ സോൺ പ്രവർത്തിപ്പിച്ചുകൊണ്ട് ബ്രൗസിംഗ് തകർക്കും. അതോടെ ആ പ്രത്യയത്തിന് കീഴിലുള്ള പേരുകൾ മാത്രം ടണൽ റിസോൾവറിലേക്ക് റൂട്ട് ചെയ്യപ്പെടുന്നു, ബാക്കിയെല്ലാം ഭൗതിക ലിങ്ക് പിന്തുടരുന്നു.
ഫലം പരിശോധിക്കൽ: വിലാസം, പേര്, പുറം വഴി
മൂന്ന് പരീക്ഷണങ്ങൾ സാധ്യമായ പരാജയങ്ങളെ വേർതിരിക്കുന്നു. ആദ്യം IP വഴി സ്വകാര്യ വിലാസം നേടുക, പിന്നീട് പേര് വഴി അതേ ഹോസ്റ്റ്, പിന്നീട് സാധാരണ പൊതു സൈറ്റ്. പ്രവർത്തിക്കുന്ന IP-യും പരാജയപ്പെടുന്ന പേരും റിസോൾവറിലേക്ക് ചൂണ്ടുന്നു; പരാജയപ്പെടുന്ന IP-യും പ്രവർത്തിക്കുന്ന പേരും റൂട്ടിംഗിലേക്ക് ചൂണ്ടുന്നു; രണ്ടും പരാജയപ്പെട്ടാൽ സാധാരണയായി ടണൽ വഴിയിലില്ല.
പിന്നീട് അകത്തേക്കല്ല, പുറത്തേക്ക് നോക്കുക. ടണലിന്റെ അന്തിമ ബിന്ദുവിന്റെ സ്വന്തം റൂട്ട് മാറ്റത്തെ അതിജീവിക്കണം, ഏത് തടയുന്ന പരാജയവും അന്തിമ ബിന്ദുവിനെ പിടിക്കാതെ ടണലിൽ പരിമിതപ്പെടുത്തണം. ടണൽ വീണതിന് ശേഷവും ബ്രൗസിംഗ് തുടരുന്ന ക്ലയന്റ് റൂട്ടിംഗ് പ്രശ്നമല്ല, നയ പ്രശ്നമാണ്, അത് മുകളിലെ മൂന്ന് പരീക്ഷണങ്ങളിൽ ഒന്നിലും പ്രത്യക്ഷപ്പെടില്ല.
അന്തിമ പട്ടിക പ്രൊഫൈലിന്റെ ഡോക്യുമെന്റേഷനിൽ എഴുതുക: റൂട്ടുകൾ, റിസോൾവർ, ഡൊമെയിനുകൾ, ഓരോന്നും നിലനിൽക്കുന്നതിന്റെ കാരണം. അതേ പട്ടിക പുനർനിർമ്മിക്കുന്ന വീണ്ടും കണക്ഷൻ മാത്രമാണ് പ്രാദേശിക നയം പൂർണ്ണമാണെന്നതിന്റെ ഏക തെളിവ്. ടണൽ ഉയർന്നിരിക്കെയും മൂന്ന് പരീക്ഷണങ്ങളും വിജയിച്ചിട്ടും ആപ്പുകൾ പരാജയപ്പെടുന്നുവെങ്കിൽ, അടുത്ത് നോക്കേണ്ട സ്ഥലം ഇതിനകം പരിശോധിച്ച സർട്ടിഫിക്കറ്റുകളല്ല, «കണക്ട് ചെയ്തെങ്കിലും ഓഫ്ലൈൻ» എന്ന വിഭാഗം പ്രശ്നങ്ങളാണ്.