Que dominios necesita ArcGIS Online nunha lista de permitidos da devasa?
Un mapa toca puntos de conexión de portal, mapa base, datos e almacenamento. Construíde a lista a partir dos requisitos actuais de dominios de Esri, non dunha soa resposta DNS.
Unha resposta DNS diche a que enderezo se resolveu un nome de host no momento en que preguntas. Non di que o enderezo sexa permanente nin enumera todo o que toca o mapa. Ese matiz importa máis cando a saída está restrinxida a unha lista curta que alguén escribiu a partir dunha única consulta. Comezade polo fluxo de traballo e despois derivade a lista a partir dos requisitos actuais do provedor. O exemplo recorrente é un cliente GIS empresarial que chega a ArcGIS Online a través dunha saída VPN restrinxida.
Enumerade cada compoñente que toca a operación do mapa
Dividide a operación en partes: o portal da organización e o acceso a elementos, as teselas do mapa base, os servizos aloxados de entidades ou de análise e calquera descarga de elementos. Cada un pode estar detrás dun punto de conexión distinto. Un mapa que fai referencia a un servizo externo de ArcGIS Enterprise ou a un punto de conexión OGC engade unha dependencia da que o equipo de rede nunca oíu falar. Anotade todo iso antes de que alguén presente unha solicitude de lista de permitidos. Un compoñente que falte nese inventario falla máis tarde dun xeito que parece un problema de credenciais.
| 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.
Que o inicio de sesión no portal funcione é unha proba feble. Demostra que se pode chegar ao punto de conexión do portal desde o camiño aprobado, e nada sobre teselas, análise ou descargas.
Escollede wildcard ou FQDN no documento actual
Esri publica Domain and FQDN Requirements, e a revisión importa porque as entradas de almacenamento rexional cambian entre versións. O documento actual ofrece tanto un enfoque de wildcard a nivel de dominio como un inventario máis estrito a nivel de nome de host. Tamén sinala os hosts de almacenamento rexional e advirte de que os sistemas externos e os dominios personalizados engaden entradas específicas da organización. Copiade no rexistro de cambios a revisión que realmente liches, coa data incluída.
Unha lista máis estrita custa tempo de mantemento; un permiso máis amplo custa alcance de seguridade. Ese intercambio pertence ao propietario da rede, e debería decidirse contra o documento e non contra un conxunto de enderezos que alguén capturou unha vez durante unha sesión de traballo.
Mantede estreita a opción de mapa base estático
As preguntas frecuentes da devasa de Esri indican que a entrega acelerada de mapas base pode devolver enderezos dinámicos. A mesma entrada documenta un arranxo de IP estática especificamente para mapas base, que abandona o camiño de aceleración e pode reducir o rendemento. Ningunha das dúas afirmacións converte o portal, os datos aloxados e os hosts de almacenamento nun único enderezo estático. Se unha política que só permite enderezos IP é obrigatoria, obtide de Esri o arranxo compatible en lugar de ampliar un rango que adiviñastes.
Unha resposta DNS antiga non é un arranxo compatible, e vaise podrecer.
Separade a ruta do permiso
Unha ruta VPN selecciona un camiño; as regras de saída deciden se ese camiño pode chegar ao destino. Son controis distintos, e un túnel san non di nada sobre o segundo. Por iso un mapa pode fallar para un usuario nunha rede e funcionar para outro usuario na mesma conta. Comprobade a regra e a ruta por separado antes de culpar o servizo.
Ambos poden ser correctos mentres o fluxo de traballo segue fallando, se o inventario está incompleto.
Comprobade compoñente por compoñente e despois dade á lista un propietario
Reproducide a operación que falla e rexistrade que compoñente fallou: portal, tesela, servizo de entidades, descarga ou un servizo externo. Despois cambiade un elemento da política e repetide. Un cambio que arranxa as teselas non vos di nada sobre os servizos de análise. Ese rexistro por compoñente é tamén o que converte a seguinte actualización rexional nun cambio de dependencia en lugar de noutra rolda de conxecturas. Revisade as URL de diagnóstico antes de pegalas en calquera sitio, porque a cadea de consulta pode levar tokens e identificadores de elementos.
Dade á lista de requisitos un propietario e unha data de revisión ligada á revisión do documento. Cando Esri engade unha rexión de almacenamento ou un host de servizo, ese propietario volve executar o inventario en lugar de descubrir o oco durante un incidente.