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 बद्दल नाही।