"ഓഫീസ് ട്രാഫിക് VPN വഴി പോകുന്നു" എന്ന് പറയുന്ന ഒരു സ്പ്ലിറ്റ്-ടണൽ കുറിപ്പ് ഒരു തീരുമാനം രേഖപ്പെടുത്തുകയും മറ്റ് മൂന്നെണ്ണം സൂചിപ്പിക്കുകയും ചെയ്തിട്ടുണ്ട്. പാക്കറ്റ് പാളിയിൽ ഒരു റൂട്ടിംഗ് പട്ടിക ലക്ഷ്യ വിലാസം കൊണ്ട് ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നു; പേര് പാളിയിൽ ഒരു റിസോൾവർ ചോദ്യം കൊണ്ട് സർവർ തിരഞ്ഞെടുക്കുന്നു, ഈ രണ്ട് തിരഞ്ഞെടുപ്പുകളും സ്വതന്ത്രമായി നടക്കുന്നു. അതുകൊണ്ട് ശരിയായി രേഖപ്പെടുത്തിയ ഒരു പ്രിഫിക്സിന് ഇപ്പോഴും ഒരു ആന്തരിക നാമം പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന, അല്ലെങ്കിൽ റൂട്ട് അനുപമമായി തോന്നുമ്പോൾ ഒന്നും പരിഹരിക്കാത്ത ഒരു യന്ത്രം ഉണ്ടാക്കാനാകും.

രണ്ട് സെലക്ടറുകൾ, ഒരു കണക്ഷൻ ശ്രമം

ഒരു ആപ്ലിക്കേഷൻ files.corp.example എന്നതുമായി ബന്ധിപ്പിക്കുമ്പോൾ, ഒരു പാക്കറ്റ് ഉണ്ടാകുന്നതിന് മുമ്പ് രണ്ട് തിരച്ചിലുകൾ നടക്കുന്നു. ഏത് സർവറിന് ചോദ്യം ലഭിക്കുമെന്ന് റിസോൾവർ തീരുമാനിക്കുന്നു, തിരച്ചിൽ ഡൊമെയ്നുകൾ, ഓരോ ലിങ്കിനുമുള്ള റൂട്ടിംഗ് ഡൊമെയ്നുകൾ അല്ലെങ്കിൽ വ്യക്തമായ പ്രൊഫൈൽ നിയമം ഉപയോഗിച്ച്. തുടർന്ന് റൂട്ടിംഗ് പട്ടിക ലഭിച്ച വിലാസം എങ്ങോട്ട് പോകുമെന്ന് ലക്ഷ്യവുമായുള്ള ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തം ഉപയോഗിച്ച് തീരുമാനിക്കുന്നു.

ആ രണ്ട് തീരുമാനങ്ങളെയും ഒന്നും ബന്ധിപ്പിക്കുന്നില്ല. ഒരു സ്വകാര്യ മേഖലയ്ക്ക് 10.20.4.11 കൊണ്ട് ഉത്തരം നൽകാം, അതേസമയം റൂട്ടിംഗ് പട്ടിക 10.20.0.0/16 ടണലിലേക്ക് അയയ്ക്കുന്നു, കണക്ഷൻ പ്രവർത്തിക്കുന്നു. ഏതെങ്കിലും ഒന്ന് തിരിച്ചിട്ടാൽ അത് മറ്റേതിനെപ്പോലെ തോന്നുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു: ശരിയായ DNS നയവും ഇല്ലാത്ത റൂട്ടും ചേർന്നാൽ പരിഹരിച്ച പേരും സമയപരിധിയും ലഭിക്കും, അതേസമയം ശരിയായ റൂട്ടും പൊതു റിസോൾവറും ചേർന്നാൽ വൃത്തിയായി തെറ്റായ സ്ഥലത്തേക്ക് റൂട്ട് ചെയ്യുന്ന ഒരു വിലാസം ലഭിക്കും.

വിഭജിത ചക്രവാള DNS ഇതിനെ കൂടുതൽ മൂർച്ചയുള്ളതാക്കുന്നു. ഒരേ പേരിന് ആന്തരിക റിസോൾവറിൽ നിന്ന് സ്വകാര്യ വിലാസവും ഇന്റർനെറ്റിലേക്ക് അഭിമുഖമായ റിസോൾവറിൽ നിന്ന് പൊതു വിലാസവും തിരികെ നൽകാം, അതിനാൽ പ്രിഫിക്സ് മാത്രം രേഖപ്പെടുത്തുന്ന ഒരു കുറിപ്പിന് ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് വിലാസം ഉപയോഗിക്കുമെന്ന് പ്രവചിക്കാനാകില്ല. റിസോൾവറിന്റെ പാത എഴുതുക, അല്ലെങ്കിൽ വിലാസം ഒരു ഊഹമാണ്.

റൂട്ട് മാത്രമുള്ള കുറിപ്പ് എന്താണ് വിട്ടുകളയുന്നത്

റൂട്ട് മാത്രമുള്ള ഒരു രേഖ ഏറ്റവും സാധാരണമായ സ്പ്ലിറ്റ്-ടണൽ പരാജയത്തിന് ഉപയോഗശൂന്യമാണ്: പേരുകൾ. ഉപയോക്താവ് ഇന്ട്രാനെറ്റ് ലോഡ് ചെയ്യുന്നില്ല എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു, ടണൽ ഓണാണ്, പ്രിഫിക്സും ഉണ്ട്. ടിക്കറ്റ് ഏറ്റെടുക്കുന്നയാൾക്ക് ഏത് റിസോൾവർ ഉത്തരം നൽകേണ്ടതായിരുന്നു എന്ന രേഖയില്ല, തെറ്റായ തിരച്ചിൽ പ്രത്യയത്തെ തടയപ്പെട്ട സർവറിൽ നിന്ന് വേർതിരിക്കാനുള്ള വഴിയില്ല, താരതമ്യത്തിന് അടിസ്ഥാന രേഖയുമില്ല.

രണ്ടാമത്തെ വിട്ടുകളയൽ അപവാദങ്ങളുടെ പട്ടികയാണ്. സ്പ്ലിറ്റ്-ടണൽ രൂപകൽപ്പന ടണലിന് പുറത്ത് എന്ത് അവശേഷിക്കുന്നു എന്നതുകൊണ്ടും അതിലേക്ക് എന്ത് പ്രവേശിക്കുന്നു എന്നതുകൊണ്ടും ഒരുപോലെ നിർവചിക്കപ്പെടുന്നു, ഒഴിവാക്കിയ ശ്രേണികളാണ് സാധാരണയായി ആദ്യം തകരുന്നത്, കാരണം കൂടുതൽ നിർദ്ദിഷ്ടമായ ഒരു പ്രാദേശിക റൂട്ടോ ക്ലയന്റ് വശത്തെ ഫിൽട്ടറോ പ്രൊഫൈൽ സ്പർശിക്കാതെ ഉദ്ദേശ്യത്തെ മറികടക്കാം.

മൂന്നാമത്തേത് ടണലിന്റെ അകലെയുള്ള വശമാണ്. ഒരു ക്ലയന്റ് റൂട്ട് പാക്കറ്റ് വയറിൽ വയ്ക്കുന്നു മാത്രം; ഗേറ്റ്വേ ഇപ്പോഴും അത് കൈമാറണം, തിരികെയുള്ള വഴിയും വേണം. strongSwan-ന്റെ കൈമാറ്റ ഗൈഡ് ഗേറ്റ്വേയിലെ കൈമാറ്റ, ഫയർവാൾ നിയമങ്ങൾ സവിശേഷതയുടെ ഭാഗമാണെന്നും ഊഹിക്കാവുന്ന പ്ലംബിംഗിന്റെ ഭാഗമല്ലെന്നും ഓർമ്മിപ്പിക്കുന്നു.

കുറിപ്പിനെ പ്രവർത്തനക്ഷമമാക്കുന്ന ഫീൽഡുകൾ

ഓരോ ഫ്ലോയ്ക്കും ഒരു വരി, ഫ്ലോ എന്നത് ലക്ഷ്യവും പേരും ഉടമയും ചേർന്നതാണ്. യഥാർത്ഥ സംഭവത്തോട് ഏറ്റുമുട്ടുമ്പോൾ അതിജീവിക്കുന്ന ഫീൽഡുകൾ ഇവയാണ്:

FieldWhy it has to be written down
Destination prefix and address familyThe route is per family; an IPv4 note says nothing about a AAAA answer
Selected tunnel or direct pathNames the decision, not the symptom
Private namespace and resolverWhich domain, which server, which search suffix
Public name pathConfirms public names do not accidentally use the private resolver
Where the rule livesClient profile, server push, OS policy or management tool
Owner and review dateNamespaces change owner more often than routes change

"അത് എവിടെ താമസിക്കുന്നു" എന്ന വരിയാണ് ആളുകൾ ഒഴിവാക്കുന്നത്. സർവർ തള്ളുന്ന പ്രിഫിക്സ്, ക്ലയന്റ് പ്രൊഫൈൽ ചേർക്കുന്ന റൂട്ട്, ഷെല്ലിൽ ടൈപ്പ് ചെയ്ത റൂട്ട് എന്നിവ ആർക്ക് അവ മാറ്റാമെന്നതിലും വീണ്ടും കണക്റ്റ് ചെയ്യുമ്പോൾ അവ നിലനിൽക്കുമോ എന്നതിലും വ്യത്യസ്തമാണ്. ആ ഫീൽഡ് ഇല്ലെങ്കിൽ അടുത്ത എഞ്ചിനീയർക്ക് മൂന്നിൽ ഏതാണ് കാണുന്നതെന്ന് പറയാനാകില്ല.

ഓരോ നിയമത്തിനും ഒരു പരീക്ഷ, ഓരോ ടണലിനുമല്ല

ഓരോ വരിക്കും രണ്ട് നിരുപദ്രവ പരിശോധനകൾ വേണം: ഒന്ന് റൂട്ട് പരിശീലിപ്പിക്കുന്നു, മറ്റൊന്ന് പേര്. റൂട്ടിനായി, ടണൽ കടക്കേണ്ട എന്തെങ്കിലും ആവശ്യപ്പെടുക, എത്തിച്ചേരാനുള്ള കഴിവിന് പകരം പാത സ്ഥിരീകരിക്കുക, ഉദാഹരണത്തിന് tracert -d 10.20.4.11 Windows-ൽ അല്ലെങ്കിൽ ip route get 10.20.4.11 Linux-ൽ. പേരിനായി, സ്വകാര്യ പേര് ചോദിച്ച് ഏത് സർവർ ഉത്തരം നൽകി എന്ന് രേഖപ്പെടുത്തുക, കുറിപ്പ് പേരിടുന്ന റിസോൾവറിനെതിരെ resolvectl query files.corp.example അല്ലെങ്കിൽ dig files.corp.example ഉപയോഗിച്ച്.

നെഗറ്റീവ് പ്രതീക്ഷയും ചേർക്കുക: ടണൽ ഓഫ് ആയിരിക്കുമ്പോൾ എന്ത് സംഭവിക്കണം. VPN ഇല്ലാതെ ബ്ലോക്ക് സജീവമായ Android അല്ലെങ്കിൽ iOS ഉപകരണത്തിലെ ഒഴിവാക്കപ്പെട്ട ആപ്ലിക്കേഷന് ഒട്ടും കണക്റ്റിവിറ്റി ഉണ്ടായിരിക്കില്ല, ഡെസ്ക്ടോപ്പ് ക്ലയന്റ് ടണൽ വീണ്ടും കണക്റ്റ് ചെയ്യുമ്പോൾ അതേ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കാൻ അനുവദിച്ചേക്കാം. ഉദ്ദേശിച്ച ഉത്തരം രേഖപ്പെടുത്തുന്നത് "VPN എന്റെ ആപ്പ് തകർത്തു" എന്നതിനെ പരിശോധിക്കാവുന്ന പ്രസ്താവനയാക്കി മാറ്റുന്നു.

രേഖ കോൺഫിഗറേഷനോടൊപ്പം സൂക്ഷിക്കുക

കുറിപ്പ് അത് വിവരിക്കുന്ന പ്രൊഫൈലിന് അടുത്ത് സൂക്ഷിക്കുക, ആ പ്രൊഫൈലിനൊപ്പം പതിപ്പ് നൽകുക. ആരും അപ്ഡേറ്റ് ചെയ്യാത്ത വിക്കിയിലെ രേഖ കിംവദന്തിയാണ്; തള്ളിയ റൂട്ടുകളും റിസോൾവർ നയവുമുള്ള അതേ ശേഖരത്തിലെ ഒരു പട്ടിക അതേ മാറ്റത്തിൽ അവലോകനം ചെയ്യാം.

എന്തെങ്കിലും തകരുമ്പോൾ, മറ്റൊരു അപവാദം ചേർക്കുന്നതിന് മുമ്പ് പ്രയോഗിച്ച റൂട്ടും ഫലപ്രദമായ റിസോൾവറും രേഖയുമായി താരതമ്യം ചെയ്യുക. മൂന്ന് സാധാരണ കാരണങ്ങളിൽ രണ്ട് — പഴയ നാമസ്ഥല നിയമവും ആപ്പ് നയത്തിന് പുറത്തുള്ള സഹായ പ്രക്രിയയും — കൃത്യമായി VPN തകരാറിനെപ്പോലെ തോന്നുന്നു, കുറിപ്പ് പ്രിഫിക്സുകൾ മാത്രം പട്ടികപ്പെടുത്തിയാൽ അവ അദൃശ്യമാണ്.

കുറിപ്പ് പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ്, അത് ഇവയ്ക്ക് എഴുത്തിൽ ഉത്തരം നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക: ഏത് പ്രിഫിക്സ്, ഏത് വിലാസ കുടുംബത്തിന്; ഏത് സ്വകാര്യ നാമസ്ഥലം, ഏത് റിസോൾവർ ഉത്തരം നൽകി; ഏത് പേരുകൾ ബോധപൂർവം പൊതുവായി തുടരുന്നു; ഓരോ നിയമവും എവിടെ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു, അതിന്റെ ഉടമ ആര്; കൂടാതെ റൂട്ട് തെളിയിക്കുന്ന ഒരു കമാൻഡും പേര് തെളിയിക്കുന്ന ഒന്നും. ഇവയിൽ ഏതെങ്കിലും കാണാതിരുന്നാൽ, അടുത്ത സംഭവം പൂജ്യത്തിൽ നിന്ന് രോഗനിർണയം ചെയ്യും.

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