Mac VPN-നുള്ള സ്ഥിരമായ റൂട്ടുകൾ: networksetup അതോ കണക്റ്റ് ഹുക്കോ?

ഓരോ കണക്ഷനും ശേഷം ടൈപ്പ് ചെയ്യുന്ന റൂട്ട് നിമിഷത്തെ പരിഹരിക്കുന്നു, ആഴ്ചയെയല്ല. macOS-ൽ, സ്ഥിരമായ തിരഞ്ഞെടുപ്പ് സാധാരണയായി VPN സേവനത്തോടൊപ്പം സൂക്ഷിക്കുന്ന പ്രിഫിക്സാണ്, കാരണം സേവനം അത് ഓരോ കണക്ഷനിലും വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുകയും സേവനം നിലയ്ക്കുമ്പോൾ നീക്കം ചെയ്യുകയും ചെയ്യുന്നു. പകരമുള്ളവ പരിശോധനയ്ക്കുള്ള താൽക്കാലിക route add ഉം ചർച്ചയ്ക്ക് ശേഷം മാത്രം അറിയുന്ന വിലാസങ്ങൾക്കുള്ള കണക്റ്റ് ഹുക്കും ആണ്.

റൂട്ട് സേവനത്തിന്റേതാണോ സെഷന്റേതാണോ എന്ന് തീരുമാനിക്കുക

പ്രിഫിക്സ് എന്തിനെ ആശ്രയിച്ചിരിക്കുന്നു എന്ന് ചോദിക്കുക. അത് സ്വദേശീയ VPN സേവനത്തിന് പിന്നിലുള്ള സ്ഥിരമായ സ്വകാര്യ നെറ്റ്വർക്ക് ആണെങ്കിൽ, റൂട്ട് ആ സേവനത്തിന്റേതാണ്. അത് ഓരോ കണക്ഷനിലും മാറുന്ന പിയർ വിലാസത്തെ ആശ്രയിക്കുന്നെങ്കിൽ, ഹുക്കോ അവസ്ഥയാൽ നയിക്കപ്പെടുന്ന ജോലിയോ മികച്ച ഉടമയായേക്കാം. അടുത്ത അഞ്ച് മിനിറ്റിന് മാത്രം ഒരു പാത പരിശോധിക്കുകയാണെങ്കിൽ, താൽക്കാലിക റൂട്ട് മതി.

സേവനത്തോട് ബന്ധിപ്പിച്ച റൂട്ടിനാണ് ഏറ്റവും ശുദ്ധമായ ജീവിതചക്രം. അത് സേവനത്തോടൊപ്പം പ്രത്യക്ഷപ്പെടുന്നു, സേവനം ബന്ധിപ്പിച്ചിട്ടില്ലാത്തപ്പോൾ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ അത് ചൂണ്ടുന്ന ടണലിനെക്കാൾ കൂടുതൽ ജീവിക്കാൻ കഴിയില്ല. ആ ഗുണം ഒരു വരി കമാൻഡിന്റെ സൗകര്യത്തെക്കാൾ വിലയുള്ളതാണ്.

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

നിലവിലെ റൂട്ടും സേവന അവസ്ഥയും വായിക്കുക

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

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

ആ തിരയൽ ഈ നിമിഷത്തിൽ ഈ വിലാസത്തിന് കേർണൽ ഏത് ഗേറ്റ്വേയും ഇന്റർഫേസും തിരഞ്ഞെടുക്കുമെന്ന് കാണിക്കുന്നു. അത് ഇതിനകം ടണൽ തിരഞ്ഞെടുക്കുന്നെങ്കിൽ, പ്രിഫിക്സ് മൂടപ്പെട്ടിരിക്കുന്നു, പുതിയ റൂട്ട് അനാവശ്യമാകും. അത് പ്രാദേശിക റൂട്ടർ തിരഞ്ഞെടുക്കുന്നെങ്കിൽ, ടണലിൽ ആ പ്രിഫിക്സ് ഇല്ല.

ബന്ധിപ്പിച്ചിരിക്കുമ്പോൾ പിയർ വിലാസം ശ്രദ്ധിക്കുക. അത് സേവനത്തോട് ബന്ധിപ്പിച്ച റൂട്ടിലെ ഗേറ്റ്വേ മൂല്യമാകുന്നു, സാധാരണയായി netstat -rn-ൽ ടണലിന്റെ സ്ഥിരസ്ഥിതി റൂട്ടിനായി കാണിക്കുന്ന ലക്ഷ്യസ്ഥാനം അതാണ്.

networksetup ഉപയോഗിച്ച് പ്രിഫിക്സ് സൂക്ഷിക്കുക

networksetup ഉപകരണം ഒരു നെറ്റ്വർക്ക് സേവനത്തിലേക്ക് അധിക റൂട്ടുകൾ ചേർക്കുന്നു. OfficeVPN എന്ന സേവനത്തിനും ടണൽ പിയർ വഴി എത്തുന്ന സ്വകാര്യ പ്രിഫിക്സിനും, രൂപം ഇതാണ്:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

സേവന നാമത്തിന് ശേഷമുള്ള ഓരോ ത്രയവും ഒരു ലക്ഷ്യസ്ഥാനം, അതിന്റെ നെറ്റ്മാസ്ക്, ഗേറ്റ്വേയായി ടണൽ പിയർ എന്നിവ നൽകുന്നു. ഒരു കോൾ നിരവധി പ്രിഫിക്സുകൾ വഹിക്കാം, ശൂന്യമായ കോൾ സൂക്ഷിച്ച ലിസ്റ്റ് മായ്ക്കുന്നു. വായനക്കാരൻ പരിശോധനാ ഘട്ടമാണ്; ലിസ്റ്റ് ശൂന്യമാണെങ്കിൽ, നിങ്ങൾ കരുതുന്ന സേവനത്തിൽ ക്രമീകരണം പ്രയോഗിച്ചിട്ടില്ല.

ഗേറ്റ്വേ ടണൽ പിയർ ആയിരിക്കണം, ഭൗതിക റൂട്ടർ അല്ല. പ്രാദേശിക ഗേറ്റ്വേയെ പേരിടുന്ന റൂട്ട് സ്വകാര്യ പ്രിഫിക്സിനെ ഭൗതിക ഇന്റർഫേസിലൂടെ പുറത്തേക്ക് അയയ്ക്കുന്നു, ഇത് അധിക ഘട്ടങ്ങളോടുകൂടിയ യഥാർത്ഥ പരാജയമാണ്. പഴയ പിയർ ആണ് ശരിയായി തോന്നുന്ന റൂട്ട് ഒരിക്കലും ട്രാഫിക് വഹിക്കാത്തതിന്റെ ഏറ്റവും സാധാരണ കാരണം. പഴയ കുറിപ്പിൽ നിന്ന് വിലാസം പകർത്തുന്നതിനുപകരം ബന്ധിപ്പിച്ച അവസ്ഥയിൽ നിന്ന് പിയർ വീണ്ടും വായിക്കുക.

route add പരിശോധനയ്ക്ക് മാത്രം ഉപയോഗിക്കുക

നേരിട്ടുള്ള റൂട്ട് പ്രിഫിക്സ് സ്ഥിരമാക്കുന്നതിന് മുമ്പ് അത് പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കാൻ ഉപകാരപ്രദമാണ്. ഇന്റർഫേസ് രൂപം ഗേറ്റ്വേ തിരയൽ ഒഴിവാക്കുന്നു:

sudo route -n add -net 10.20.0.0/16 -interface utun4

റൂട്ട് അടുത്ത വീണ്ടും കണക്ഷനിൽ അപ്രത്യക്ഷമാകുന്നു, ഇന്ന് നിലവിലുള്ള ഇന്റർഫേസ് നമ്പറിനെ ആശ്രയിച്ചിരിക്കുന്നു. അത് ഇതിനെ ഒരു ഡയഗ്നോസ്റ്റിക് ആക്കുന്നു, വിന്യാസമല്ല. പരിശോധന പ്രവർത്തിക്കുകയും സേവനത്തോട് ബന്ധിപ്പിച്ച റൂട്ട് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, ആദ്യം ഗേറ്റ്വേ മൂല്യം താരതമ്യം ചെയ്യുക; അതാണ് ഏറ്റവും കൂടുതൽ തെറ്റാകുന്ന ഫീൽഡ്.

വിഭജന സ്വഭാവം നിർബന്ധിക്കാൻ VPN-ന്റെ സ്ഥിരസ്ഥിതി റൂട്ട് മാറ്റിസ്ഥാപിക്കുന്ന ഉപദേശങ്ങളിൽ ശ്രദ്ധിക്കുക. പൂർണ്ണ ടണൽ നിർബന്ധിക്കുന്ന ക്ലയന്റ് വീണ്ടും കണക്ഷനോ നയ പുതുക്കലിനോ ശേഷം അതിന്റെ റൂട്ടുകൾ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്തേക്കാം, അതിനാൽ കൈകൊണ്ടുള്ള മാറ്റം നിശബ്ദമായി റദ്ദാകുന്നു. കുറച്ച് സ്വകാര്യ പ്രിഫിക്സുകൾ ഒരു റൗട്ടിംഗ് പ്രശ്നമാണ്; പൂർണ്ണ-ടണൽ നയത്തിനെതിരെ എല്ലാ ഇന്റർനെറ്റ് ട്രാഫിക്കും പ്രാദേശികമായി നിർത്തുന്നത് സെർവർ വശത്തെ തീരുമാനമാണ്.

വിലാസം ചർച്ച ചെയ്യപ്പെടുമ്പോൾ മാത്രം ഹുക്ക് തിരഞ്ഞെടുക്കുക

PPP അടിസ്ഥാനമാക്കിയ ലിങ്കുകൾക്ക്, ഉദാഹരണത്തിന് L2TP, macOS ലിങ്ക് സ്ഥാപിച്ചാൽ /etc/ppp/ip-up പ്രവർത്തിപ്പിക്കുന്നു. സ്ക്രിപ്റ്റിന് ഇന്റർഫേസ് പേരും ചർച്ച ചെയ്ത പ്രാദേശിക, ദൂര വിലാസങ്ങളും ലഭിക്കുന്നു, അതിനാൽ സെർവർ അനുവദിച്ച പിയറിനെ ആശ്രയിക്കുന്ന ഒരു റൂട്ട് ചേർക്കാം. സ്ഥിരമായ സേവന റൂട്ടിന് പ്രകടിപ്പിക്കാൻ കഴിയാത്ത അവസ്ഥ കൃത്യമായി ഇതാണ്.

IKEv2 ഉം വെണ്ടർ ക്ലയന്റുകളും ആ PPP പാത ഒട്ടും ഉപയോഗിച്ചേക്കില്ല, അതായത് സ്ക്രിപ്റ്റിന് മുഴുവൻ സെഷനിലും നിശബ്ദമായിരിക്കാം. അങ്ങനെ സംഭവിക്കുമ്പോൾ, scutil --nc status ചോദിച്ച് അവസ്ഥാ മാറ്റത്തിന് പ്രതികരിക്കുന്ന launchd ജോലിയാണ് തത്തുല്യമായ സംവിധാനം, ചെറിയ കാലതാമസത്തോടെ.

നിങ്ങൾ ഏത് ഹുക്ക് ഉപയോഗിച്ചാലും, അതിനെ ഐഡംപോട്ടന്റ് ആക്കുക, അത് സ്വയം സൃഷ്ടിച്ച റൂട്ടുകൾ മാത്രം നീക്കം ചെയ്യട്ടെ. ടണലിനെ പരാമർശിക്കുന്ന എല്ലാ റൂട്ടും മായ്ക്കുന്ന സ്ക്രിപ്റ്റ് ഒടുവിൽ VPN സെർവറിനെ എത്തിച്ചേരാവുന്നതായി നിലനിർത്തുന്ന റൂട്ടും മായ്ക്കും, കണക്ഷൻ വിജയിക്കുന്ന ക്ഷണത്തിൽ തന്നെ വീഴും.

സ്വകാര്യ ലക്ഷ്യസ്ഥാനം, സാധാരണ ബ്രൗസിംഗ്, വീണ്ടും കണക്ഷൻ അല്ലെങ്കിൽ ഉറക്ക ചക്രം എന്നിവ പരിശോധിച്ച് അവസാനിപ്പിക്കുക. തുടർന്ന് scutil --dns പരിശോധിക്കുക, കാരണം പേര് നിർണ്ണയം വേറിട്ട നയമാണ്, പ്രവർത്തിക്കുന്ന റൂട്ട് സ്വകാര്യ പേരുകൾ പരിഹരിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല.