SharePoint लिंक प्रकाशित URL के कारण VPN पर टूट जाते हैं
VPN से लोड होने वाला SharePoint पृष्ठ अभी भी ऐसे नाम पर दस्तावेज़ लिंक लौटा सकता है जिसे आपका क्लाइंट हल नहीं कर सकता। DNS, रूट, TLS और प्रकाशित URL जाँचें।
VPN से SharePoint पृष्ठ खुलता है, और पहला दस्तावेज़ लिंक ऐसे नाम के साथ विफल हो जाता है जो कभी पता-पट्टी में नहीं था। यही अंतर पूरी समस्या है: पृष्ठ एक URL से आया, और सेवा ने अगला अनुरोध किसी दूसरे 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 के बारे में नहीं है।