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 को बारेमा होइन।