SharePoint ലിങ്കുകൾ പ്രസിദ്ധീകരിച്ച URL കാരണം VPN-ൽ മുറിയുന്നു
VPN വഴി ലോഡ് ചെയ്യുന്ന SharePoint പേജിന് നിങ്ങളുടെ ക്ലയന്റിന് പരിഹരിക്കാനാകാത്ത പേരിൽ ഡോക്യുമെന്റ് ലിങ്കുകൾ നൽകാനാകും. DNS, റൂട്ട്, TLS, പ്രസിദ്ധീകരിച്ച URL എന്നിവ പരിശോധിക്കുക.
SharePoint പേജ് VPN വഴി തുറക്കുന്നു, ഒപ്പം ആദ്യ ഡോക്യുമെന്റ് ലിങ്ക് വിലാസ ബാറിൽ ഒരിക്കലും ഉണ്ടായിരുന്നില്ലാത്ത പേരിൽ പരാജയപ്പെടുന്നു. ആ വിടവാണ് മുഴുവൻ പ്രശ്നം: പേജ് ഒരു URL-ൽ നിന്ന് വന്നു, സേവനം അടുത്ത അഭ്യർത്ഥന മറ്റൊന്നിൽ നിന്ന് രൂപപ്പെടുത്തി. പ്രസിദ്ധീകരിച്ച URL സർവർ വശത്തെ തീരുമാനമാണ്, അതിനാൽ അത് ക്ലയന്റിൽ തിരുത്തുന്നത് തെറ്റായ അറ്റമാണ്. DNS അല്ലെങ്കിൽ റൂട്ടുകൾ തൊടുന്നതിന് മുമ്പ് സേവനം ഏത് പേര് നൽകുന്നു എന്ന് പരിശോധിക്കുക.
ആദ്യ പേജും അടുത്ത അഭ്യർത്ഥനയും വ്യത്യസ്ത പേരുകൾ ഉപയോഗിക്കുന്നു
വിലാസത്തിലൂടെ സർവറിൽ എത്തുന്ന ഉപയോക്താവ് പ്രവർത്തിക്കുന്ന ഹോംപേജ് കാണുന്നു. ആ പേജിലെ ഡോക്യുമെന്റ് ലിങ്കുകൾ സേവനം പ്രസിദ്ധീകരിക്കുന്നു എന്ന് കരുതുന്ന URL-ൽ നിന്ന് സൃഷ്ടിക്കപ്പെടുന്നു, ബ്രൗസർ ടൈപ്പ് ചെയ്തതിൽ നിന്നല്ല. അവ വ്യത്യസ്തമാണെങ്കിൽ, അടുത്ത ക്ലിക്ക് ക്ലയന്റ് ഒരിക്കലും പരിഹരിക്കാത്ത പേരിലേക്ക് പോകുന്നു.
വിലാസം ഒരു തവണ നൽകുന്നത് സൃഷ്ടിച്ച എല്ലാ ലിങ്കുകളും ശരിയാക്കുന്നില്ല, വിലാസത്തിലേക്കുള്ള ബുക്ക്മാർക്ക് ഡോക്യുമെന്റ് തുറക്കുന്നതുവരെ പ്രശ്നം മറയ്ക്കുന്നു.
ഈ പരാജയം ടണൽ ഉപയോഗിച്ചതിന് ശേഷം മാത്രം പ്രത്യക്ഷപ്പെടുന്നതിനാൽ VPN പ്രശ്നമായി തെറ്റായി വായിക്കാൻ എളുപ്പമാണ്. യഥാർത്ഥത്തിൽ ടണൽ അതിന്റെ ജോലി ചെയ്യുന്നു: പ്രവർത്തിക്കുന്ന പാതയോ പൊരുത്തപ്പെടുന്ന സർട്ടിഫിക്കറ്റോ ഇല്ലാത്ത പേരിലേക്ക് അത് അഭ്യർത്ഥന കൊണ്ടുപോകുന്നു. ഏതെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ട് ചോദ്യങ്ങൾ വേർതിരിക്കുക. ഒന്ന് പാക്കറ്റ് എവിടേക്ക് പോകുന്നു എന്നതാണ്, മറ്റൊന്ന് സേവനം ഏത് പേര് പ്രസിദ്ധീകരിക്കാൻ തിരഞ്ഞെടുത്തു എന്നതാണ്.
നാല് നിയന്ത്രണങ്ങൾ, ഒരു പേര്
ഓരോ പ്രസിദ്ധീകരിച്ച പേരും നാല് സ്വതന്ത്ര നിയന്ത്രണങ്ങൾ കടക്കണം. DNS അത് യഥാർത്ഥ ക്ലയന്റിനായി പരിഹരിക്കണം, റൂട്ടിംഗും ആക്സസ് നയവും പാത അനുവദിക്കണം, TLS ആ പേര് സാധൂകരിക്കണം, സേവനം അത് പ്രസിദ്ധീകരിക്കാൻ കോൺഫിഗർ ചെയ്തിരിക്കണം.
ഒരു നിയന്ത്രണത്തിലെ മാറ്റം മറ്റുള്ളവ നിർവഹിക്കുന്നില്ല. സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് സ്വീകരിക്കുന്നത് പേര് പരിഹരിക്കലിന്റെ അറ്റകുറ്റപ്പണിയല്ല.
ചുവടെയുള്ള പട്ടിക ചെക്ക്ലിസ്റ്റിന്റെ ക്രമമാണ്. പരാജയപ്പെടുന്ന ആദ്യ വരിയിൽ നിർത്തുക, കാരണം പിന്നീടുള്ള തിരുത്ത് മുൻപത്തെ വിടവ് നികത്താനാവില്ല.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
മാറ്റുന്നതിന് മുമ്പ് പ്രസിദ്ധീകരണ മാതൃക വായിക്കുക
SharePoint Server വിന്യാസങ്ങൾ വ്യത്യസ്തമാണ്. ക്ലാസിക് വെബ് ആപ്ലിക്കേഷനുകൾക്ക് ഇതര ആക്സസ് മാപ്പിംഗുകൾ ഉപയോഗിക്കാം, അവിടെ ആന്തരിക URL എന്നത് സർവർ സ്വീകരിക്കുന്നതാണ്, പൊതു URL എന്നത് ലിങ്കുകൾ രൂപപ്പെടുത്താൻ അത് ഉപയോഗിക്കുന്നതാണ്. ഹോസ്റ്റ്-നാമ സൈറ്റ് ശേഖരങ്ങൾ മറ്റൊരു സമീപനം സ്വീകരിക്കുന്നു, Microsoft-ന്റെ മാർഗ്ഗനിർദ്ദേശപ്രകാരം അവർക്ക് AAM ഉപയോഗിക്കാനാവില്ല.
Microsoft-ന്റെ ആസൂത്രണ മാർഗ്ഗനിർദ്ദേശം AAM സവിശേഷതകളെ കാലഹരണപ്പെട്ടതായി അടയാളപ്പെടുത്തുകയും പുതിയ ആസൂത്രണത്തിന് ഹോസ്റ്റ്-നാമ സൈറ്റ് ശേഖരങ്ങൾ ശുപാർശ ചെയ്യുകയും ചെയ്യുന്നു. അത് വിന്യാസ മാതൃകയെ അതിന്റെ ഉടമയുടെ ചോദ്യമാക്കുന്നു, നിങ്ങൾ പാച്ച് ചെയ്യുന്ന സ്ഥിരമൂല്യമല്ല.
മാപ്പിംഗ് മാറ്റം നിർദ്ദേശിക്കുന്നതിന് മുമ്പ് ഏത് മാതൃകയാണ് ഉപയോഗിക്കുന്നതെന്ന് നിർണ്ണയിക്കുക. ഹോസ്റ്റ്-നാമ വിന്യാസത്തിലേക്ക് AAM എൻട്രി ചേർക്കുന്നത് ഒന്നും ചെയ്യുന്നില്ല, ക്ലാസിക് വിന്യാസത്തിലേക്ക് ഒന്ന് ചേർക്കുന്നത് തിരികെ നൽകുന്ന എല്ലാ ലിങ്കുകളും ഒരുമിച്ച് മാറ്റുന്നു. രണ്ടും വിശാല സ്വാധീനമുള്ള കോൺഫിഗറേഷൻ മാറ്റങ്ങളാണ്, അതിനാൽ അവ ഘട്ടങ്ങളായി തയ്യാറാക്കി റോൾബാക്ക് സൂക്ഷിക്കുക. ഇത് ആധുനിക പരിതസ്ഥിതിയിലേക്ക് പഴയ മാപ്പിംഗുകൾ കൊണ്ടുവരാനുള്ള ശുപാർശയല്ല.
പരാജയപ്പെട്ട പ്രവർത്തനം പിന്തുടരുക, ഹോംപേജല്ല
പരാജയപ്പെട്ട അഭ്യർത്ഥന യഥാർത്ഥത്തിൽ ഉപയോഗിച്ച ലക്ഷ്യം, ക്ലയന്റ് ആപ്ലിക്കേഷൻ, സമയം, പിശക് എന്നിവ രേഖപ്പെടുത്തുക. ഒരു ബ്രൗസറും ഡെസ്ക്ടോപ്പ് ആപ്ലിക്കേഷനും ഒരേ ഡോക്യുമെന്റിലേക്ക് വ്യത്യസ്ത പ്രോക്സി, VPN അല്ലെങ്കിൽ പ്രാമാണീകരണ പാതകൾ സ്വീകരിച്ചേക്കാം.
ബ്രൗസർ വിജയിക്കുമ്പോൾ Office ക്ലയന്റ് പരാജയപ്പെടാം, ആ വ്യത്യാസം ഏത് സന്ദർഭമാണ് പേര് പരിഹരിക്കുന്നതെന്നതിന്റെ സൂചനയാണ്.
URL-ഉം നെറ്റ്വർക്ക് കൈമാറ്റവും രണ്ടും പ്രവർത്തിക്കുകയും സേവനം ഇപ്പോഴും പ്രവർത്തനം നിരസിക്കുകയും ചെയ്താൽ, ബാക്കിയുള്ള പ്രശ്നം ആപ്ലിക്കേഷൻ തലത്തിലാണ്. ഡോക്യുമെന്റ് അനുമതികളും ചെക്ക്-ഔട്ട് അവസ്ഥയും സേവന ഉടമയുടേതാണ്, VPN റൂട്ട് കണക്റ്റിവിറ്റി നൽകുന്നു, അനുമതിയല്ല.
കൈമാറ്റം തുടക്കം മുതൽ അവസാനം വരെ പരിശോധിക്കുക
പരാജയപ്പെടുന്ന ക്ലയന്റിൽ പരിശോധനകൾ ക്രമത്തിൽ പ്രവർത്തിപ്പിക്കുക: പ്രസിദ്ധീകരിച്ച പേര് പരിഹരിക്കുക, ആ പേരിൽ പേജ് അഭ്യർത്ഥിക്കുക, പിന്നീട് പേജ് ഉറവിടത്തിൽ നിന്ന് ഡോക്യുമെന്റിന്റെ URL അഭ്യർത്ഥിക്കുക. ഓരോ ഘട്ടവും ഒരു നിയന്ത്രണം വേർതിരിക്കുന്നു.
മൂന്ന് കമാൻഡുകൾ പരിഹാരം, TLS, ഡോക്യുമെന്റ് പാത എന്നിവ ഉൾക്കൊള്ളുന്നു:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspxപരിഹാരം ടണൽ വഴി മാത്രം പരാജയപ്പെട്ടാൽ, split-DNS നയം സംശയാസ്പദമാണ്. TLS പരാജയപ്പെട്ടാൽ, മുന്നറിയിപ്പിലൂടെ ക്ലിക്ക് ചെയ്യുന്നതിന് പകരം സർട്ടിഫിക്കറ്റിന്റെ പേര് പ്രസിദ്ധീകരിച്ച പേരുമായി താരതമ്യം ചെയ്യുക. രണ്ടും വിജയിക്കുകയും ഡോക്യുമെന്റ് ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, പിശക് ഇനി URL-നെക്കുറിച്ചല്ല.