ആപ്പിന്റെ സബ്നെറ്റ് റൂട്ട് ചെയ്യുന്നത് സ്പ്ലിറ്റ് ടണലിന്റെ വ്യക്തമായ ഭാഗമാണ്, അത് മുഴുവൻ ജോലിയുമല്ല. റിസോൾവർ സാധാരണയായി താൻ സേവിക്കുന്ന ആപ്പിൽ നിന്ന് വ്യത്യസ്ത വിലാസത്തിലാണ് ഇരിക്കുന്നത്, അതിനാൽ പ്രവർത്തിക്കുന്ന ടണലിനും തിരയലിനെ അതിന് പുറത്ത് വിടാം. 10.80.0.0/16 മാത്രം വഹിക്കുന്ന പ്രൊഫൈൽ 10.90.0.53 എന്നതിനുള്ള ചോദ്യം പ്രാദേശിക ഇന്റർഫേസിലൂടെ അയയ്ക്കുന്നു, അവിടെ സ്വകാര്യ മേഖലയില്ല. റിസോൾവറിന്റെ പാത ചേർക്കുക, പിന്നെ പ്രശ്നത്തിന്റെ രണ്ടാം പകുതി നോക്കുക: ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് സർവർ തിരഞ്ഞെടുക്കുന്നു.

മിത്ത്: ഒരു റൂട്ട് മുഴുവൻ സേവനത്തെയും ഉൾക്കൊള്ളുന്നു

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

റിസോൾവറിന് ചുറ്റുമുള്ള സബ്നെറ്റും സ്വയമേവ ഉൾക്കൊള്ളുന്നില്ല. ഒരു വിലാസത്തിലേക്കുള്ള ഹോസ്റ്റ് റൂട്ട് ആ റിസോൾവറിന് മതിയാകും, അതിന്റെ അയൽക്കാരെ തുറക്കുന്നില്ല. ഹോസ്റ്റ് റൂട്ടിന്റെ അർത്ഥം അതാണ്: രൂപകൽപ്പനയിൽ ഇടുങ്ങിയത്, അടുത്ത സേവനം അതേ സബ്നെറ്റിൽ പ്രത്യക്ഷപ്പെടുമ്പോൾ മറക്കാൻ എളുപ്പം.

തിരയൽ പ്രവർത്തിക്കാൻ മൂന്ന് കാര്യങ്ങൾ ശരിയാകണം: ക്ലയന്റ് റിസോൾവറിന്റെ വിലാസം ടണലിലൂടെ റൂട്ട് ചെയ്യുന്നു, ഗേറ്റ്വേ ആ അഭ്യർത്ഥന സ്വീകരിച്ച് കൈമാറുന്നു, റിസോൾവർ ലഭിക്കുന്ന ഉറവിടം സ്വീകരിക്കുന്നു. മറുപടിയും സമ്മതിച്ച പാതയിലൂടെ തിരികെ വരണം. ഇവയിലൊന്ന് ഇല്ലെങ്കിൽ ലക്ഷണം ഒന്നുതന്നെയാണ്, അതിനാൽ കോൺഫിഗറേഷനിൽ തൊടുന്നതിന് മുമ്പ് വിലാസ പട്ടിക എഴുതിവയ്ക്കുന്നത് ഉചിതമാണ്.

പ്രൊഫൈൽ ഏത് വിലാസങ്ങൾ വഹിക്കണമെന്ന് നിർണ്ണയിക്കുക

ലക്ഷ്യസ്ഥാനങ്ങൾ ക്രമത്തിൽ പട്ടികപ്പെടുത്തുക: ആപ്പ് നെറ്റ്വർക്ക്, റിസോൾവറിന്റെ വിലാസം, ടണൽ തന്നെ അവസാനിപ്പിക്കുന്ന പൊതു എൻഡ്പോയിന്റ്. മൂന്നാമത്തേത് ഒരിക്കലും ടണലിലേക്ക് റൂട്ട് ചെയ്യരുത്, കാരണം പുറം കണക്ഷന് ടണലിന് മുമ്പ് നിലനിൽക്കുന്ന ഒരു പാത വേണം.

DestinationCoverage this example needs
Application network10.80.0.0/16 through the VPN
Private resolver10.90.0.53/32 through the VPN
Public VPN endpointNormal internet path, outside the tunnel

DNS-ന് UDP-യും TCP-യും രണ്ടും ഉൾപ്പെടുത്തുക, കാരണം നടപ്പാക്കലുകൾ UDP-യോടൊപ്പം TCP-യും പിന്തുണയ്ക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു, തടയപ്പെട്ട TCP പാത വൃത്തിയായ പരാജയങ്ങൾക്ക് പകരം സാവധാനവും ഭാഗികവുമായ പരാജയങ്ങൾ നൽകുന്നു. സ്വകാര്യ മേഖല IPv6 വഴിയും സേവിക്കുന്നുവെങ്കിൽ, തത്തുല്യമായ ഹോസ്റ്റ് ഒഴിവാക്കൽ IPv6 വിലാസവും പ്രിഫിക്സും ഉപയോഗിക്കുന്നു, അത് പ്രത്യേക എൻട്രിയാണ്.

എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് പ്രൊഫൈൽ ഇതിനകം എന്ത് ഉൾക്കൊള്ളുന്നുവെന്ന് രേഖപ്പെടുത്തുക. തനിപ്പകർപ്പ് റൂട്ട് നിരുപദ്രവകരമാണ്, പക്ഷേ അപ്രതീക്ഷിതമായ നിലവിലുള്ള റൂട്ട് നിങ്ങൾക്ക് ലഭിച്ചതിൽ നിന്ന് വ്യത്യസ്തമായ വിലാസ പദ്ധതിക്കാണ് പ്രൊഫൈൽ രൂപകൽപ്പന ചെയ്തതെന്ന് പറയുന്നു.

കണക്ഷന്റെ ഉടമയിലൂടെ ഹോസ്റ്റ് റൂട്ട് ചേർക്കുക

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

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

ആദ്യ കമാൻഡ് ഒന്നും ഇൻസ്റ്റാൾ ചെയ്യാതെ മാറ്റം പ്രിവ്യൂ ചെയ്യുന്നു, രണ്ടാമത്തേത് പ്രൊഫൈൽ ഇപ്പോൾ വഹിക്കുന്ന റൂട്ടുകൾ പട്ടികപ്പെടുത്തുന്നു. Microsoft-ന്റെ Add-VpnConnectionRoute റഫറൻസ് ഓരോ ഉപയോക്താവിനും എല്ലാ ഉപയോക്താക്കൾക്കുമുള്ള പരിധികൾ രേഖപ്പെടുത്തുന്നു; എല്ലാ ഉപയോക്താക്കളുടെയും പ്രൊഫൈലിന് സ്വന്തം പരിധി പാരാമീറ്റർ വേണം, എല്ലാ ഉപയോക്താക്കളുടെയും പ്രൊഫൈലിനെതിരായ ഓരോ ഉപയോക്താവിന്റെയും കമാൻഡ് പരാജയപ്പെടുകയോ തെറ്റായ സ്ഥലത്ത് എത്തുകയോ ചെയ്യുന്നു.

പ്രൊഫൈൽ നിയന്ത്രിക്കപ്പെടുന്നതോ വിൽപ്പനക്കാരന്റെ ക്ലയന്റിൽ നിന്ന് വരുന്നതോ ആണെങ്കിൽ, മാറ്റം ആ ഉടമയുടേതാണ്. സ്ഥിരമായ ഒരു സിസ്റ്റം റൂട്ട് കണക്ഷൻ നയത്തിന് മുകളിൽ കൂട്ടിവയ്ക്കുന്നത് നയം വീണ്ടും പ്രയോഗിക്കപ്പെടുകയും റൂട്ട് അപ്രത്യക്ഷമാകുകയും ചെയ്യുന്നതുവരെ പ്രവർത്തിക്കുന്നു, അത് സാധാരണയായി പരിശോധനയ്ക്കിടയിലല്ല, പിന്തുണാ കോളിനിടയിലാണ് സംഭവിക്കുന്നത്. ആ പരാജയം നിശ്ശബ്ദമാണ്: റൂട്ട് മാഞ്ഞുപോകുന്നു, പേര് പരിഹരിക്കുന്നത് നിലയ്ക്കുന്നു, ആരും രണ്ട് സംഭവങ്ങളെയും ബന്ധിപ്പിക്കുന്നില്ല. മാറ്റം ഉടമയുടെ സ്വന്തം രേഖയിൽ വയ്ക്കുക, അടുത്ത വീണ്ടും പ്രയോഗം അത് മായ്ക്കുന്നതിന് പകരം വഹിക്കും.

പ്രയോഗിച്ച ശേഷം റൂട്ട് പ്രാബല്യത്തിൽ വന്നുവെന്ന് അനുമാനിക്കുന്നതിന് പകരം പ്രൊഫൈൽ വീണ്ടും ബന്ധിപ്പിക്കുക. ജീവനുള്ള കണക്ഷനിലെ റൂട്ട് മാറ്റങ്ങൾ എപ്പോഴും എടുക്കപ്പെടുന്നില്ല, വീണ്ടും ബന്ധിപ്പിക്കുന്നത് നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് യഥാർത്ഥത്തിൽ ഉണ്ടാകുന്ന അവസ്ഥയും പുനഃസൃഷ്ടിക്കുന്നു.

ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് റിസോൾവർ ഉപയോഗിച്ചുവെന്ന് പരിശോധിക്കുക

റൂട്ട് റിസോൾവറിലേക്ക് അഡ്രസ് ചെയ്ത പാക്കറ്റുകൾ നിയന്ത്രിക്കുന്നു. ഏത് പേരുകൾ അങ്ങോട്ട് അയയ്ക്കണമെന്ന് അത് തീരുമാനിക്കുന്നില്ല, ആ തിരഞ്ഞെടുപ്പ് പ്രത്യേക സംവിധാനമാണ്. Windows ൽ ഫലപ്രദമായ നാമസ്ഥല നിയമങ്ങൾക്ക് ഡൊമെയിനിന് റിസോൾവർ തിരഞ്ഞെടുക്കാം, പ്രൊഫൈലിന്റെ DNS ക്രമീകരണങ്ങൾ സ്ഥിരമായ ഒന്ന് നൽകുന്നു. ഈ രണ്ട് പാളികൾ ഒരു പിശകും സൃഷ്ടിക്കാതെ വിയോജിക്കാം, അതിനാൽ നേരിട്ടുള്ള ചോദ്യം പകുതി തെളിവ് മാത്രമാണ്.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

ആദ്യ കമാൻഡ് നിലവിലുള്ള നാമസ്ഥല നയം പ്രിന്റ് ചെയ്യുന്നു, രണ്ടാമത്തേത് സ്വകാര്യ റിസോൾവറിനോട് ആപ്പിന്റെ പേര് നേരിട്ട് ചോദിക്കുന്നു. നേരിട്ടുള്ള മറുപടി പാതയും റിസോൾവറും പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നു; ആപ്പിന്റെ സ്വന്തം തിരയൽ ആ സർവർ തിരഞ്ഞെടുത്തുവെന്ന് തെളിയിക്കുന്നില്ല. അത് അതേ പേരിന്റെ സാധാരണ തിരയലുമായും ആപ്പിന് ലഭിക്കുന്ന മറുപടിയുമായും താരതമ്യം ചെയ്യുക.

കാഷുകളും ബ്രൗസർ തലത്തിലുള്ള സുരക്ഷിത DNS ഉം കണക്കിലെടുക്കുക, അത് ഉപയോക്താവ് ടൈപ്പ് ചെയ്ത പേരുകൾക്ക് സിസ്റ്റം റിസോൾവറിനെ പൂർണ്ണമായും ഒഴിവാക്കാം. തിരയൽ പ്രത്യയം മറ്റൊരു തെറ്റായ സൂചനയാണ്: അത് ചെറിയ പേരിനെ പൂർണ്ണമായി യോഗ്യതയുള്ള പേരാക്കി വികസിപ്പിക്കുന്നു, ഏത് സർവർ മറുപടി നൽകുന്നു എന്നതുമായി യാതൊരു ബന്ധവുമില്ല.

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

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