SharePoint இணைப்புகள் வெளியிடப்பட்ட URL காரணமாக VPN-ல் உடைகின்றன
VPN வழியாக ஏற்றப்படும் SharePoint பக்கம் உங்கள் கிளையண்ட் தீர்க்க முடியாத பெயரில் ஆவண இணைப்புகளைத் திருப்பித் தரக்கூடும். DNS, பாதை, TLS மற்றும் வெளியிடப்பட்ட URL ஆகியவற்றைச் சரிபார்க்கவும்.
VPN வழியாக SharePoint பக்கம் திறக்கிறது, முதல் ஆவண இணைப்பு முகவரிப் பட்டியில் ஒருபோதும் இல்லாத பெயரில் தோல்வியடைகிறது. அந்த இடைவெளியே முழுப் பிரச்சினை: பக்கம் ஒரு 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 பற்றியது அல்ல.