Inleiding
Dit artikel behandelt een basisgebruikssituatie zoals u die zou kunnen hebben in een pre-productieomgeving. Alle ArcGIS Enterprise-componenten (Portal, Server en Data Store) bevinden zich op één machine in een intern netwerk. De BIG-IP reverse proxy maakt het mogelijk om het systeem aan een ander netwerk te presenteren (dit kan een intern clientnetwerk of een openbaar netwerk zijn) waarbij al het clientverkeer via het BIG-IP-apparaat wordt geleid.
Dit artikel is verdeeld in drie hoofdsecties. De eerste sectie is bedoeld voor de ArcGIS Enterprise-beheerders en richt zich op hun taken in de taal en termen die zij begrijpen. De tweede sectie is bedoeld voor de BIG-IP-beheerder, hopelijk in de taal en termen die zij begrijpen. De laatste sectie behandelt aanvullende opties en details die geschikt zijn voor beide groepen beheerders.
Het doel van dit artikel is om ArcGIS- en F5-beheerders te helpen samenwerken door een bewezen reeks procedures te beschrijven rond welke ze kunnen samenwerken. Dit artikel beoogt niet om ArcGIS-beheerders in staat te stellen F5 zelf te configureren (of andersom). Er wordt aangenomen dat ArcGIS-beheerders experts zijn in ArcGIS en vertrouwen op Esri-documentatie voor details. Evenzo wordt aangenomen dat F5-beheerders experts zijn in BIG-IP en vertrouwen op F5-documentatie voor details.
Hoewel de use case "basic" is, is de onderneming niet "simpel". Succes vereist het integreren van technologie en kennis uit verschillende gespecialiseerde domeinen (Esri-technologie, F5-technologie, netwerken, certificaten, enz.). Als de procedures in dit artikel niet duidelijk genoeg zijn voor actie binnen uw organisatiecontext, kan dit een indicatie zijn dat externe adviesondersteuning nuttig zou zijn.
Dit artikel is gebaseerd op de volgende use case-specificaties:
- Gebruik van F5's BIG-IP als een "OSI Layer 7" of "full proxy"
- Gebruik van ArcGIS Enterprise waarbij de Web Adaptor wordt ingezet met IIS op het Windows-besturingssysteem
Instructies voor ArcGIS-beheerder
De focus van de ArcGIS-beheerder is om ArcGIS Enterprise zo te implementeren dat het klaar is om geproxied te worden door de F5 BIG-IP reverse proxy. Het implementatiedoel wordt weergegeven in het onderstaande diagram.
Afhankelijk van de specifieke vereisten is het mogelijk niet nodig om Web Adaptors te implementeren bij gebruik van een reverse proxy. Het wordt echter aanbevolen om dit wel te doen om de volgende redenen:
- Het gebruik van Web Adaptors vermindert de configuratiecomplexiteit in de BIG-IP reverse proxy.
- Web Adaptors stellen u in staat om de correctheid van het ArcGIS Enterprise-systeem onafhankelijk van de reverse proxy te valideren; dit kan zeer waardevol zijn bij probleemoplossing.
- Hoewel Web Adaptors kunnen worden ingezet op Linux-gebaseerde systemen met behulp van een Java Web Server, is de frequentie van implementatie op Windows met IIS de reden waarom deze eerste gids zich op dat patroon richt.
Stap één: Ontwerpbeslissingen en communicatie met F5-beheerders
In deze configuratie zullen clients ArcGIS Enterprise benaderen via de reverse proxy. De reverse proxy presenteert een CNAME ("DNS-alias", weergegeven in groen in het onderstaande diagram) die de HTTPS-sessies van de clients beëindigt. Vervolgens start het nieuwe HTTPS-sessies vanaf zichzelf naar de webserver die de web adaptors host. De webserver presenteert meestal een certificaat met de subjectnaam van het A-record (de hostnaam, weergegeven in rood in het diagram) die de inkomende HTTPS-sessies van de BIG-IP reverse proxy beëindigt.
Voordat u uw systeem implementeert, moet u de volgende beslissingen nemen:
- Wat is de CNAME ("DNS Alias") waaronder de reverse proxy het ArcGIS Enterprise-systeem zal vertegenwoordigen?
- Wat zijn de "contexten" ("Web Adaptor-namen", weergegeven in blauw in het diagram) voor Portal for ArcGIS en ArcGIS Server Sites?
U zult waarschijnlijk moeten samenwerken met uw F5-beheerders om overeenstemming te bereiken over de CNAME en ervoor te zorgen dat zij beschikken over een TLS-certificaat dat geschikt is om HTTPS-communicatie op die CNAME te beëindigen. Tegelijkertijd kunt u aan de F5-beheerders de naam (het A RECORD) van de machine delen waarop uw webserver zal draaien en waarnaar verzoeken moeten worden doorgestuurd.
Stap twee: Implementeer een webserver met TLS-certificaat
Het is nuttig om uw webserver te implementeren en deze te configureren met een TLS-certificaat voor HTTPS-verkeer voordat u iets direct met ArcGIS Enterprise doet. Dit stelt u in staat om ervoor te zorgen dat HTTPS werkt met uw webserver, en stelt F5-beheerders in staat om vroegtijdig de reverse proxy voor de webserver te configureren. Dit maakt vroege validatie van het TLS-certificaat en HTTPS-paden mogelijk.
Configureer HTTPS op uw webserver
Configuratiestappen om HTTPS met webservers mogelijk te maken variëren per merk webserver. Omdat IIS een zeer veelgebruikte webserver is, heeft Esri instructies gegeven over hoe deze te configureren voor HTTPS als onderdeel van haar Web Adaptor-installatiehandleiding: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-https-on-your-web-server-server-.htm.
Wanneer u HTTPS inschakelt op uw webserver, moet u een TLS-certificaat verstrekken. Certificaten hebben onder andere Subjects en Subject Alternative Names (SAN's). Het Subject van het certificaat moet overeenkomen met de naam die de BIG-IP reverse proxy zal gebruiken om naar de webserver te verwijzen. Dit is vaak het A RECORD (machine1.domain.local in het diagram). De SAN is een lijst met alternatieve namen. Een goede praktijk voor SAN's is om op te nemen:
- De Subjectnaam (bijv. machine1.domain.local)
- De korte versie van de subjectnaam (bijv. machine1)
- De CNAME die door de reverse proxy wordt gepresenteerd (bijv. gis.domain.com), indien mogelijk
Afhankelijk van het certificeringsorgaan en beleid binnen uw organisatie kunt u mogelijk wel of niet de CNAME opnemen in de SAN. Het voordeel hiervan is dat u zo meer mogelijkheden heeft om ArcGIS Enterprise onafhankelijk van de reverse proxy te valideren.
Valideer
Zodra uw webserver is geconfigureerd voor HTTPS, moet u uw configuratie valideren. Eerst moet u valideren door rechtstreeks naar uw webserver te navigeren via een browser met behulp van het HTTPS-protocol. Ten tweede, als uw F5-beheerders de BIG-IP reverse proxy hebben geconfigureerd om verkeer naar uw webserver door te sturen, kunt u vervolgens navigeren naar het virtuele server-eindpunt van de reverse proxy in een browser, ook via HTTPS. In beide gevallen wilt u bevestigen dat er geen certificaatwaarschuwingen verschijnen en dat de doelpagina correct wordt geladen.
Gewoonlijk hebben webservers een standaardpagina die wordt teruggegeven wanneer u naar de root van de webserver gaat. Dat is een goede optie. Een betere optie is om een webpagina te implementeren waarmee u meer kunt zien over wat er gebeurt. De showHeaders-pagina's (één voor ASPX/IIS en één voor JSP: https://github.com/dannykrouk/showHeaders) geven veel nuttige details terug zoals hieronder weergegeven:
Overweeg om de showHeaders-pagina naar uw webserver te implementeren en deze als doel te gebruiken voor zowel uw tests op uw webserver als op uw reverse proxy. Als u deze pagina implementeert in de root van uw webserver, kunt u testen met deze verzoeken:
Stap drie: Implementeer en configureer ArcGIS Enterprise
De hier beschreven implementatie van ArcGIS Enterprise is een "single-machine base deployment" (https://enterprise.arcgis.com/en/get-started/latest/windows/base-arcgis-enterprise-deployment.htm#ESRI_SECTION1_690F8D4A3ABE4FB8AE926C118E9F8299).
Installeer en configureer de basisprincipes
Documentatie die u door de installatiestappen leidt is beschikbaar op de website van Esri: https://enterprise.arcgis.com/en/documentation/install/.
In dit artikel is de Web Adaptor naam van Portal for ArcGIS (de "context") "/portal" en de Web Adaptor naam van de Hosting Server is "/server". Wanneer u uw Hosting Server Site federateert met uw Portal for ArcGIS, kunt u de Web Adaptor gebruiken voor zowel de Services URL als de Administration URL (https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-servers.htm), zolang u geen Web Tier authenticatie gebruikt. Als u Web Tier authenticatie gebruikt, moet uw Administration URL dit patroon volgen: https://machine1.domain.local:6443/arcgis.
Valideer de basisprincipes; "Systeem Vertrouwenscontrole"
Zodra u uw Web Adaptors hebt geconfigureerd en uw Hosting Server hebt gefedereerd, moet u een korte "systeem vertrouwenscontrole" uitvoeren om te controleren of de kernfuncties correct werken.
Een typische systeem vertrouwenscontrole zou het volgende omvatten:
- Inloggen op /portaladmin
- Valideer Federatie
- Publiceer een service
- Deel de service
Het "vertrouwen" dat men met deze stappen opbouwt, is dat het geïmplementeerde systeem geen fundamentele configuratiefout heeft die basiswerking zou verhinderen.
Wat u ook maakt (bijv. een gepubliceerde service) in de systeem vertrouwenscontrole moet worden verwijderd voordat u doorgaat.
Eindconfiguratie voor de Reverse Proxy
De laatste configuratiestap is het configureren van de WebContextURL voor het Portal en de Hosting Server. Deze eigenschap bepaalt hoe elke Esri-server weet onder welke naam clients deze via de BIG-IP reverse proxy zullen aanspreken.
Portal for ArcGIS: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm#ESRI_SECTION1_7C753FB1F19349A398E5FFCC6079A821
{
"WebContextURL": "https://gis.domain.com/portal"
}ArcGIS for Server: https://enterprise.arcgis.com/en/server/latest/deploy/linux/using-a-reverse-proxy-server-with-arcgis-server.htm#ESRI_SECTION1_13680C9069E14B1F8AE5793BE1ED25A6
{
"WebContextURL": "https://gis.domain.com/server"
}Stap Vier: Systeemvalidatie
De vierde en laatste stap voor de ArcGIS-beheerder is "systeemvalidatie", onafhankelijk van de BIG-IP reverse proxy. Als u op deze manier valideert en er werkt iets niet wanneer verzoeken via de reverse proxy lopen, dan moet de reverse proxy-configuratie worden gecontroleerd. Als u niet op deze manier valideert, kan het veel ingewikkelder zijn om de oorzaak van het probleem vast te stellen.
Wijzig tijdelijk naamresolutie op de webservermachine
De truc bij deze validatie is om het systeem tijdelijk te overtuigen dat de CNAME (gis.domain.com) zich bevindt op de ArcGIS Enterprise-machine (machine1.domain.local). Als u lokale beheerdersrechten hebt op machine1.domain.local, kunt u het hosts-bestand bewerken. Als machine1.domain.local het IP-adres 10.0.0.10 heeft, zou de hosts-bestandvermelding er als volgt uitzien:
10.0.0.10 gis.domain.com
Dit betekent: "gis.domain.com kan worden gevonden op 10.0.0.10".
Wanneer u uw bewerking aan dit bestand hebt voltooid (dat meestal hier te vinden is: C:\Windows\System32\drivers\etc\hosts), opent u een opdrachtprompt en bevestigt u dat uw instelling effectief is met ping:
C:\>ping gis.domain.com
Ping naar gis.domain.com [10.0.0.10] met 32 bytes data:
Antwoord van <IP-adres van machine1>: bytes=32 tijd=22ms TTL=124
…
Het resultaat van het ping-commando moet het IP-adres in uw hosts-bestand zijn, de hierboven ter verduidelijking gemarkeerde tijdelijke waarde.
Test in een browser op de webservermachine
Open nu een webbrowser op machine1.domain.local en voer opnieuw uw "systeem vertrouwenscontrole" uit, ditmaal door het systeem aan te spreken via zijn CNAME (https://gis.domain.com/portal/home/).
Als uw systeem op deze manier correct functioneert, maak dan de wijziging in het hosts-bestand ongedaan en vraag de F5-beheerders om hun configuratiewerk af te ronden.
F5 Beheerder Instructies
Vanuit een BIG-IP perspectief is dit een eenvoudige configuratie. Het ArcGIS Enterprise-systeem heeft verschillende componenten. Maar vanuit het oogpunt van de reverse proxy is er één enkele back-end webserver node die luistert op HTTPS/443. Het enige configuratie-element dat kan verschillen van andere systemen is dat ArcGIS Enterprise vereist dat de reverse proxy een X-Forwarded-Host header bevat.
Op hoofdlijnen zal uw proxyconfiguratie al het HTTPS-verkeer naar de gis.domain.com CNAME beëindigen en opnieuw HTTPS initiëren naar de enkele back-end node, machine1.domain.local. De webserver op dit adres ondersteunt twee "contexts", één voor elk belangrijk onderdeel van het ArcGIS Enterprise-systeem (Portal for ArcGIS en ArcGIS Server): /portal en /server.
Zoals beschreven in de introductie van dit artikel gaan we ervan uit dat u drie netwerken hebt die aan uw BIG-IP proxy zijn gekoppeld: een clientnetwerk, een servernetwerk en uw administratienetwerk.
Dit artikel gaat ervan uit dat u een expert bent in BIG-IP beheer en alleen aanwijzingen nodig hebt over welke stappen u moet nemen om deze virtuele server en backend pool in optimale volgorde te configureren.
Stap Eén: Proxy naar de webserver
De CNAME voor dit systeem zou met u moeten zijn vastgesteld of aan u gecommuniceerd moeten zijn. Een bijbehorend TLS-certificaat voor die CNAME moet ook worden geleverd. De certificaatautoriteit moet er één zijn die wordt vertrouwd door de clients van dit systeem.
Installeer het TLS-certificaat
Installeer het TLS-certificaat voor de Virtual Server in BIG-IP (bijv., Subject gis.domain.com)
Systeem > Certificaatbeheer > Traffic Certificate Management > SSL Certificate List > Import SSL Certificate
Maak Client SSL-profiel aan
Maak een clientprofiel aan om client TLS-verbindingen te beëindigen op het certificaat voor de naam gis.domain.com.
Local Traffic > Profiles > SSL > Client > Create
Maak een Pool met een Simple Monitor aan
Maak een backend Pool voor de webserver (bijv. https://machine1.domain.local/ ) met een Simple Monitor om te bepalen of de node resource 5C5C5Cup5C5C5D of 5C5C5Cdown5C5C5D is.
Local Traffic > Pools > Pool List > Create
<\/span><\/H3> <\/P>Maak een HTTP Services-profiel aan (Voeg de X-Forwarded-Host-header toe)<\/H3>De X-Forwarded-Host-header stelt ArcGIS Enterprise in staat om de waarde van de Host-header te kennen die bij BIG-IP is aangekomen. Het ArcGIS Enterprise-systeem zal deze waarde controleren aan de hand van zijn configuratie om ervoor te zorgen dat clients het op een juiste manier hebben aangesproken. Als de X-Forwarded-Host-header niet aanwezig is, of een verkeerde waarde bevat, zal ArcGIS Enterprise een HTTP-omleiding uitvoeren om aan te geven hoe het volgens het systeem aangesproken zou moeten worden. Dit kan resulteren in omleidingslussen. In het geval dat ArcGIS Enterprise een omleidingslus detecteert, zal het deze doorbreken en een fout retourneren.<\/P>Een X-Forwarded-Host-header kan worden toegevoegd met een iRule:<\/P>when HTTP_REQUEST {
HTTP::header insert X-Forwarded-Host [HTTP::host]
}<\/PRE> <\/P>Deze instructie neemt de waarde van de Host-header van het binnenkomende verzoek en stelt deze in als de waarde van de X-Forwarded-Host-header voor de standaard pool.<\/P>Maak de Virtual Server aan<\/H3>Local Traffic > Virtual Servers > Create<\/P>Selecteer "Standard" voor Type Virtual Server. Specificeer uw SSL-profiel (Client) dat u eerder hebt aangemaakt met uw SSL-certificaat. Bij het specificeren van een Server-profiel is het configuratiedoel het bereiken van een TLS-tunnel naar de backend. Dit kan worden bereikt met de standaardinstelling "serverssl" binnen BIG-IP. Stel "Source Address Translation" in op Auto Map.<\/P>
<\/span><\/P> Selecteer op het tabblad Resources uw pool die u eerder hebt aangemaakt.<\/P>
<\/span><\/P> <\/P>Stap Twee: Valideer Proxying naar ArcGIS Enterprise<\/H2>Er zijn twee stappen om de effectiviteit van deze configuratie te valideren. <\/P>Valideer Vertrouwen en Headers<\/H3>Aangenomen dat de showHeaders.aspx-pagina is geïmplementeerd op de backend-webserver, gebruik een webbrowser om naar https:\/\/gis.domain.com\/showHeaders.aspx<\/A> te navigeren. De browser zou vrij moeten zijn van certificaatvertrouwenswaarschuwingen. De pagina-responsinhoud moet aantonen dat het aspect van de X-Forwarded-Host-header in uw configuratie effectief is.<\/P> 
<\/span><\/P> <\/P>Op dit punt, met de headerstroom naar de backend bevestigd, is er geen behoefte meer aan de showHeaders.aspx-tool. Als uw systeem bedoeld is voor PRODUCTIE, of elke omgeving waar deze informatie niet blootgesteld mag worden, moet de tool worden verwijderd.<\/P>
TestrichtlijnenDeze instructies bevatten "systeemvertrouwenscontroles" en validaties gedurende het implementatie-/configuratieproces. Deze maatregelen waren bedoeld om te bepalen of het redelijk was om door te gaan naar de volgende stap in de instructies. Deze maatregelen bewijzen niet dat het systeem acceptabel is. Aan het einde gaan we ervan uit dat het hele systeem functioneert. Met andere woorden, deze tests stellen vast dat het systeem functionele samenhang heeft.Het doorgeven van het systeem voor
acceptatietests is de juiste volgende stap. Het doel van acceptatietests is om het geïmplementeerde systeem te meten aan de hand van de zakelijke doelen die het moet ondersteunen.ZorgcontroleDe eenvoudige monitoring die in de instructies aan F5-beheerders is opgenomen, stelt BIG-IP in staat om te stoppen met het doorsturen van verzoeken naar het ArcGIS Enterprise-systeem als de node (d.w.z. machine1.domain.local) uitvalt of ontoegankelijk is. Voor een systeem als dit, met slechts één back-end Pool-lid, is dit (een Simple Monitor) het volledige aanbevolen niveau van zorgcontrole.In principe kan BIG-IP worden geconfigureerd met out-of-band health checks die vragen aan de ArcGIS Enterprise-software om zijn gezondheid te bevestigen of te valideren dat specifieke HTTPS-verzoeken slagen met bepaalde responsinhouden. Bijvoorbeeld, het Portal for ArcGIS-component van ArcGIS Enterprise biedt deze endpoint:
https:\/\/developers.arcgis.com\/rest\/enterprise-administration\/portal\/health-check-portal.htm. In een enkel knoopsysteem elimineert een reactie op een gezondheidscontroleprobleem feitelijk alle toegang tot het systeem. Het voordeel hiervan is dat de reverse proxy een generieke foutmelding kan geven aan clients dat het systeem uitvalt. Het nadeel hiervan is dat een tijdelijk probleem, gedeeltelijk probleem of misinterpretatie via de gezondheidscontrole alle toegang tot het systeem elimineert terwijl het mogelijk nog bruikbaar was voor veel gebruikssituaties. De waarschijnlijkheid van false negatives (ongezonde bevindingen) geassocieerd met formele/gecompliceerde gezondheidscontroles kan resulteren in minder systeembetrouwbaarheid voor eindgebruikers ten opzichte van false positives (gezonde bevindingen) geassocieerd met eenvoudige node-monitoring. Met andere woorden, voor een enkel knoopsysteem is complexiteit de vijand van betrouwbaarheid; houd u aan een Simple Monitor.KredietenDit artikel is geproduceerd op basis van het werk van Roger Schlogel, een consultant bij Esri's Professional Services.
