फ़ायरवॉल अनुमति सूची में ArcGIS Online को किन डोमेन की ज़रूरत है?
एक मैप पोर्टल, बेसमैप, डेटा और स्टोरेज एंडपॉइंट को छूता है। अनुमति सूची Esri की मौजूदा डोमेन आवश्यकताओं से बनाएँ, किसी एक DNS उत्तर से नहीं।
DNS उत्तर आपको बताता है कि जिस पल आपने पूछा, उस पल एक होस्टनाम किस पते पर हल हुआ। यह नहीं बताता कि पता स्थायी है, और यह उन सब चीज़ों की सूची नहीं देता जिन्हें मैप छूता है। यह अंतर तब सबसे ज़्यादा मायने रखता है जब आउटबाउंड एक छोटी अनुमति सूची तक सीमित हो जिसे किसी ने एक ही खोज से टाइप किया हो। कार्यप्रवाह से शुरू करें, फिर प्रदाता की मौजूदा आवश्यकताओं से सूची निकालें। बार-बार आने वाला उदाहरण एक एंटरप्राइज़ GIS क्लाइंट है जो सीमित VPN आउटबाउंड के ज़रिए ArcGIS Online तक पहुँचता है।
मैप संचालन जिन-जिन घटकों को छूता है, उन सबकी सूची बनाएँ
संचालन को भागों में बाँटें: संगठन का पोर्टल और आइटम पहुँच, बेसमैप टाइलें, होस्ट किए गए फ़ीचर या विश्लेषण सेवाएँ, और कोई भी आइटम डाउनलोड। हर एक अलग एंडपॉइंट के पीछे हो सकता है। बाहरी ArcGIS Enterprise सेवा या OGC एंडपॉइंट का संदर्भ देने वाला मैप ऐसी निर्भरता जोड़ता है जिसके बारे में नेटवर्क टीम ने कभी नहीं सुना। किसी के द्वारा अनुमति सूची का अनुरोध दाखिल करने से पहले यह सब लिख लें। इस सूची में छूटा हुआ घटक बाद में ऐसे विफल होता है जो क्रेडेंशियल की समस्या जैसा दिखता है।
| Component | Example host family | Form | Who owns it |
|---|---|---|---|
| Portal and item access | *.arcgis.com | Wildcard | Esri, under the organization subdomain |
| Basemaps and static tiles | *.arcgisonline.com | Wildcard | Esri |
| Hosted feature and analysis services | *.arcgis.com | Wildcard | Esri, same revision |
| Item downloads and regional storage | storage hosts named in the current revision | Revision-specific | Esri |
| ArcGIS Enterprise service | gis.example.com | FQDN | Your organization |
| OGC or third-party endpoint | provider host | FQDN | The provider |
| Custom domain in front of the portal | maps.example.com | FQDN | Your organization |
The Domain and FQDN Requirements document is where those families come from, and two of them carry most of the workflow: *.arcgis.com covers the organization portal, its items and the hosted services behind them, while *.arcgisonline.com serves basemaps and static tiles. Everything else is organization-specific, because an ArcGIS Enterprise service you host, an OGC endpoint or a custom domain in front of the portal has to be added by name. Take those entries from the same revision you read, since the regional storage hosts change between versions.
पोर्टल में साइन-इन सफल होना कमज़ोर सबूत है। यह साबित करता है कि स्वीकृत पथ से पोर्टल एंडपॉइंट तक पहुँचा जा सकता है, और टाइलों, विश्लेषण या डाउनलोड के बारे में कुछ नहीं।
मौजूदा दस्तावेज़ से wildcard या FQDN चुनें
Esri Domain and FQDN Requirements प्रकाशित करता है, और संशोधन मायने रखता है क्योंकि क्षेत्रीय स्टोरेज प्रविष्टियाँ संस्करणों के बीच बदलती हैं। मौजूदा दस्तावेज़ डोमेन-स्तरीय wildcard दृष्टिकोण और होस्टनाम-स्तरीय अधिक कड़ी सूची, दोनों देता है। यह क्षेत्रीय स्टोरेज होस्ट भी रेखांकित करता है और चेताता है कि बाहरी सिस्टम और कस्टम डोमेन संगठन-विशिष्ट प्रविष्टियाँ जोड़ते हैं। परिवर्तन रिकॉर्ड में वही संशोधन कॉपी करें जो आपने वास्तव में पढ़ा, तारीख सहित।
अधिक कड़ी सूची रखरखाव का समय लेती है; अधिक व्यापक अनुमति सुरक्षा-दायरा लेती है। यह अदला-बदली नेटवर्क मालिक की है, और यह दस्तावेज़ के आधार पर तय होनी चाहिए, किसी के द्वारा एक बार कार्य-सत्र में पकड़े गए पतों के समूह के आधार पर नहीं।
स्थिर बेसमैप विकल्प को संकीर्ण रखें
Esri का फ़ायरवॉल FAQ कहता है कि त्वरित बेसमैप वितरण गतिशील पते लौटा सकता है। वही प्रविष्टि बेसमैप के लिए विशेष रूप से स्थिर IP व्यवस्था का दस्तावेज़ीकरण करती है, जो त्वरण पथ छोड़ देती है और प्रदर्शन घटा सकती है। इनमें से कोई भी कथन पोर्टल, होस्ट किए गए डेटा और स्टोरेज होस्ट को एक स्थिर पते में नहीं बदलता। यदि केवल IP पते की अनुमति देने वाली नीति अनिवार्य है, तो अपने अनुमानित रेंज को चौड़ा करने के बजाय Esri से समर्थित व्यवस्था लें।
पुराना DNS उत्तर समर्थित व्यवस्था नहीं है, और वह सड़ जाएगा।
मार्ग को अनुमति से अलग रखें
VPN मार्ग एक पथ चुनता है; आउटबाउंड नियम तय करते हैं कि वह पथ गंतव्य तक पहुँच सकता है या नहीं। ये अलग नियंत्रण हैं, और स्वस्थ टनल दूसरे के बारे में कुछ नहीं कहता। इसीलिए मैप एक नेटवर्क पर एक उपयोगकर्ता के लिए विफल हो सकता है और उसी खाते पर दूसरे उपयोगकर्ता के लिए काम कर सकता है। सेवा को दोष देने से पहले नियम और मार्ग अलग-अलग जाँचें।
यदि सूची अधूरी है तो कार्यप्रवाह के अब भी विफल रहने पर दोनों सही हो सकते हैं।
घटक-दर-घटक जाँचें, फिर सूची को एक मालिक दें
विफल हो रहे संचालन को दोहराएँ और दर्ज करें कि कौन-सा घटक विफल हुआ: पोर्टल, टाइल, फ़ीचर सेवा, डाउनलोड या बाहरी सेवा। फिर नीति का एक तत्व बदलें और दोहराएँ। टाइलें ठीक करने वाला बदलाव विश्लेषण सेवाओं के बारे में आपको कुछ नहीं बताता। यही घटक-वार रिकॉर्ड अगले क्षेत्रीय अपडेट को अनुमान के एक और दौर के बजाय निर्भरता-परिवर्तन में बदलता है। नैदानिक URL को कहीं भी चिपकाने से पहले उनकी समीक्षा करें, क्योंकि क्वेरी स्ट्रिंग टोकन और आइटम पहचानकर्ता ले जा सकती है।
आवश्यकता सूची को एक मालिक और दस्तावेज़ संशोधन से जुड़ी समीक्षा तिथि दें। जब Esri कोई स्टोरेज क्षेत्र या सेवा होस्ट जोड़ता है, तो वह मालिक घटना के दौरान अंतराल खोजने के बजाय सूची फिर से चलाता है।