Einführung
Dieser Artikel behandelt einen grundlegenden Anwendungsfall, wie er in einer Vorproduktionsumgebung vorkommen könnte. Alle ArcGIS Enterprise-Komponenten (Portal, Server und Data Store) befinden sich auf einer einzigen Maschine in einem internen Netzwerk. Der BIG-IP Reverse Proxy ermöglicht es, das System einem anderen Netzwerk (kann ein internes Client-Netzwerk oder ein öffentliches Netzwerk sein) zu präsentieren, wobei der gesamte Client-Verkehr über das BIG-IP-Gerät geleitet wird.
Dieser Artikel ist in drei Hauptabschnitte unterteilt. Der erste Abschnitt richtet sich an die ArcGIS Enterprise-Administratoren und soll sie mit ihren Aufgaben in der Sprache und den Begriffen vertraut machen, die sie verstehen. Der zweite Abschnitt richtet sich an die BIG-IP-Administratoren und spricht hoffentlich ihre Sprache und Begriffe an. Der letzte Abschnitt behandelt zusätzliche Optionen und Details, die für beide Administratorengruppen geeignet sind.
Das Ziel dieses Artikels ist es, ArcGIS- und F5-Administratoren dabei zu helfen, zusammenzuarbeiten, indem ein bewährtes Verfahren beschrieben wird, um gemeinsam vorzugehen. Dieser Artikel soll nicht ArcGIS-Administratoren befähigen, F5 selbst zu konfigurieren (oder umgekehrt). Es wird davon ausgegangen, dass ArcGIS-Administratoren Experten für ArcGIS sind und sich für Details auf die Esri-Dokumentation verlassen. Ebenso wird angenommen, dass F5-Administratoren Experten für BIG-IP sind und sich für Details auf die F5-Dokumentation stützen.
Obwohl der Anwendungsfall „grundlegend“ ist, ist das Unterfangen nicht „einfach“. Erfolg erfordert die Integration von Technologie und Wissen aus mehreren spezialisierten Bereichen (Esri-Technologie, F5-Technologie, Netzwerke, Zertifikate usw.). Wenn die Verfahren in diesem Artikel in Ihrem organisatorischen Kontext nicht klar genug für eine Umsetzung sind, kann dies ein Hinweis darauf sein, dass externe Beratungsunterstützung hilfreich wäre.
Dieser Artikel basiert auf den folgenden spezifischen Anwendungsfalldetails:
- Verwendung von F5s BIG-IP als „OSI Layer 7“ oder „Full Proxy“
- Verwendung von ArcGIS Enterprise, bei dem der Web Adaptor mit IIS auf dem Windows-Betriebssystem bereitgestellt wird
Anweisungen für ArcGIS-Administratoren
Der Fokus des ArcGIS-Administrators liegt darauf, ArcGIS Enterprise so bereitzustellen, dass es vom F5 BIG-IP Reverse Proxy weitergeleitet werden kann. Das Bereitstellungsziel ist im folgenden Diagramm dargestellt.
Je nach den spezifischen Anforderungen ist es möglicherweise nicht erforderlich, Web Adaptors bei Verwendung eines Reverse Proxys bereitzustellen. Es wird jedoch empfohlen, dies aus folgenden Gründen zu tun:
- Die Verwendung von Web Adaptors reduziert die Konfigurationskomplexität im BIG-IP Reverse Proxy.
- Web Adaptors ermöglichen es Ihnen, die Korrektheit des ArcGIS Enterprise-Systems unabhängig vom Reverse Proxy zu validieren; dies kann bei der Fehlerbehebung sehr wertvoll sein.
- Obwohl Web Adaptors auf Linux-basierten Systemen mit einem Java-Webserver bereitgestellt werden können, ist die Häufigkeit der Bereitstellung unter Windows mit IIS der Grund dafür, dass dieser erste Leitfaden sich auf dieses Muster konzentriert.
Schritt Eins: Designentscheidungen und Kommunikation mit F5-Administratoren
In dieser Konfiguration adressieren Clients ArcGIS Enterprise über den Reverse Proxy. Der Reverse Proxy präsentiert einen CNAME („DNS-Alias“, im Diagramm unten grün dargestellt), der die HTTPS-Sitzungen von den Clients terminiert. Anschließend initiiert er neue HTTPS-Sitzungen von sich selbst zum Webserver, der die Web Adaptors hostet. Der Webserver präsentiert üblicherweise ein Zertifikat mit dem Betreffnamen des A-Eintrags (dem Hostnamen, im Diagramm rot dargestellt), der die eingehenden HTTPS-Sitzungen vom BIG-IP Reverse Proxy terminiert.
Bevor Sie Ihr System bereitstellen, müssen Sie folgende Entscheidungen treffen:
- Was ist der CNAME („DNS-Alias“), unter dem der Reverse Proxy das ArcGIS Enterprise-System repräsentieren wird?
- Was sind die „Kontexte“ („Web Adaptor-Namen“, im Diagramm blau dargestellt) für das Portal for ArcGIS und die ArcGIS Server-Sites?
Sie müssen wahrscheinlich mit Ihren F5-Administratoren zusammenarbeiten, um sich auf den CNAME zu einigen und sicherzustellen, dass sie ein TLS-Zertifikat besitzen, das geeignet ist, HTTPS-Kommunikation unter diesem CNAME zu terminieren. Gleichzeitig können Sie den F5-Administratoren den Namen (den A-EINTRAG) der Maschine mitteilen, auf der Ihr Webserver betrieben wird und an die Anfragen weitergeleitet werden sollen.
Schritt Zwei: Bereitstellung eines Webservers mit TLS-Zertifikat
Es ist sinnvoll, Ihren Webserver bereitzustellen und ihn mit einem TLS-Zertifikat für HTTPS-Verkehr zu konfigurieren, bevor Sie direkt etwas mit ArcGIS Enterprise tun. Dies ermöglicht es Ihnen sicherzustellen, dass HTTPS mit Ihrem Webserver funktioniert und erlaubt es den F5-Administratoren, den Reverse Proxy frühzeitig für den Webserver zu konfigurieren. Dies ermöglicht eine frühe Validierung des TLS-Zertifikats und der HTTPS-Pfade.
HTTPS auf Ihrem Webserver konfigurieren
Die Konfigurationsschritte zur Aktivierung von HTTPS bei Webservern variieren je nach Webserver-Marke. Da IIS ein sehr verbreiteter Webserver ist, hat Esri Anweisungen bereitgestellt, wie man ihn für HTTPS als Teil seiner Anleitung zur Installation des Web Adaptors konfiguriert: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-https-on-your-web-server-server-.htm.
Wenn Sie HTTPS auf Ihrem Webserver aktivieren, müssen Sie ein TLS-Zertifikat bereitstellen. Zertifikate haben unter anderem Subjects und Subject Alternative Names (SANs). Der Subject des Zertifikats sollte mit dem Namen übereinstimmen, den der BIG-IP Reverse Proxy verwendet, um den Webserver anzusprechen. Dies ist oft der A-EINTRAG (machine1.domain.local im Diagramm). Die SANs sind eine Liste alternativer Namen. Eine gute Praxis für SANs ist es einzuschließen:
- Den Subject-Namen (z.B. machine1.domain.local)
- Die Kurzform des Subject-Namens (z.B. machine1)
- Den CNAME, den der Reverse Proxy präsentieren wird (z.B. gis.domain.com), wenn möglich
Je nach Zertifizierungsstelle Ihrer Organisation und deren Richtlinien können Sie den CNAME möglicherweise nicht in die SAN aufnehmen. Der Vorteil dabei ist jedoch eine größere Möglichkeit zur Validierung von ArcGIS Enterprise unabhängig vom Reverse Proxy.
Validieren
Sobald Ihr Webserver für HTTPS konfiguriert ist, sollten Sie Ihre Konfiguration validieren. Zuerst sollten Sie validieren, indem Sie direkt im Browser über das HTTPS-Protokoll auf Ihren Webserver zugreifen. Zweitens können Sie dann – falls Ihre F5-Administratoren den BIG-IP Reverse Proxy so konfiguriert haben, dass er Verkehr an Ihren Webserver weiterleitet – auch über den virtuellen Server-Endpunkt des Reverse Proxys im Browser mittels HTTPS navigieren. In beiden Fällen möchten Sie bestätigen, dass keine Zertifikatswarnungen angezeigt werden und die Zielseite korrekt geladen wird.
Typischerweise haben Webserver eine Standardseite, die zurückgegeben wird, wenn man zum Stammverzeichnis des Servers geht. Das ist eine gute Option. Eine bessere Option ist es jedoch eine Webseite bereitzustellen, die mehr darüber zeigt was passiert. Die showHeaders-Seiten (eine für ASPX/IIS und eine für JSP: https://github.com/dannykrouk/showHeaders) geben viele nützliche Details zurück wie unten gezeigt:
Ziehen Sie in Betracht die showHeaders-Seite auf Ihrem Webserver bereitzustellen und sie als Ziel sowohl für Ihre Tests am Webserver als auch am Reverse Proxy zu verwenden. Wenn Sie die Seite im Stammverzeichnis Ihres Webservers bereitstellen, können Sie mit diesen Anfragen testen:
Schritt Drei: Bereitstellung und Konfiguration von ArcGIS Enterprise
Die hier beschriebene Bereitstellung von ArcGIS Enterprise ist eine „Single-Machine Base Deployment“ (https://enterprise.arcgis.com/en/get-started/latest/windows/base-arcgis-enterprise-deployment.htm#ESRI_SECTION1_690F8D4A3ABE4FB8AE926C118E9F8299).
Installation und Grundkonfiguration
Dokumentation, die Sie durch die Installationsschritte führt, ist auf der Esri-Webseite verfügbar: https://enterprise.arcgis.com/en/documentation/install/.
In diesem Artikel ist der Web Adaptor-Name („Kontext“) von Portal for ArcGIS „/portal“ und der Web Adaptor-Name des Hosting Servers ist „/server“. Wenn Sie Ihre Hosting Server-Site mit Ihrem Portal for ArcGIS föderieren, können Sie den Web Adaptor sowohl für die Services-URL als auch für die Administrations-URL (https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-servers.htm) verwenden, solange Sie keine Web Tier-Authentifizierung nutzen. Wenn Sie Web Tier-Authentifizierung verwenden, sollte Ihre Administrations-URL diesem Muster folgen: https://machine1.domain.local:6443/arcgis.
Grundlagen validieren; „Systemvertrauensprüfung“
Sobald Ihre Web Adaptors konfiguriert und Ihr Hosting Server föderiert ist, sollten Sie eine kurze „Systemvertrauensprüfung“ durchführen, um sicherzustellen, dass die Kernfunktionen korrekt arbeiten.
Eine typische Systemvertrauensprüfung würde Folgendes umfassen:
- Anmeldung bei /portaladmin
- Föderation validieren
- Einen Dienst veröffentlichen
- Dienst freigeben
Das „Vertrauen“, das man mit diesen Schritten aufbaut, besteht darin, dass das bereitgestellte System keinen grundlegenden Konfigurationsfehler aufweist, der den Basisbetrieb verhindern würde.
Alles, was Sie im Rahmen der Systemvertrauensprüfung erstellen (z. B. einen veröffentlichten Dienst), sollte vor dem Fortfahren gelöscht werden.
Endkonfiguration für den Reverse Proxy
Der letzte Konfigurationsschritt besteht darin, die WebContextURL für das Portal und den Hosting Server zu konfigurieren. Diese Eigenschaft bestimmt, unter welchem Namen jeder Esri-Server von Clients über den BIG-IP Reverse Proxy angesprochen wird.
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"
}Schritt Vier: Systemvalidierung
Der vierte und letzte Schritt für den ArcGIS-Administrator ist die „Systemvalidierung“, unabhängig vom BIG-IP Reverse Proxy. Wenn Sie auf diese Weise validieren und etwas nicht funktioniert, wenn Anfragen über den Reverse Proxy geleitet werden, dann muss die Reverse Proxy-Konfiguration überprüft werden. Wenn Sie nicht auf diese Weise validieren, kann es viel komplizierter sein, die Ursache des Problems zu ermitteln.
Temporäre Änderung der Namensauflösung auf dem Webserver-Rechner
Der Trick bei dieser Validierung besteht darin, das System vorübergehend davon zu überzeugen, dass der CNAME (gis.domain.com) auf dem ArcGIS Enterprise-Rechner (machine1.domain.local) liegt. Wenn Sie lokale Administratorrechte auf dem Rechner machine1.domain.local haben, können Sie die Hosts-Datei bearbeiten. Hat machine1.domain.local die IP-Adresse 10.0.0.10, sieht der Eintrag in der Hosts-Datei so aus:
10.0.0.10 gis.domain.com
Dies bedeutet: „gis.domain.com ist unter 10.0.0.10 zu finden“.
Nachdem Sie diese Datei bearbeitet haben (normalerweise zu finden unter: C:\Windows\System32\drivers\etc\hosts), öffnen Sie eine Eingabeaufforderung und prüfen mit ping, ob Ihre Einstellung wirksam ist:
C:\>ping gis.domain.com
Ping wird ausgeführt für gis.domain.com [10.0.0.10] mit 32 Bytes Daten:
Antwort von <IP-Adresse von machine1>: Bytes=32 Zeit=22ms TTL=124
…
Das Ergebnis des Ping-Befehls sollte die IP-Adresse aus Ihrer Hosts-Datei sein, der oben zur Verdeutlichung hervorgehobene Platzhalterwert.
Test im Browser auf dem Webserver-Rechner
Öffnen Sie nun einen Webbrowser auf machine1.domain.local und führen Sie Ihre „Systemvertrauensprüfung“ erneut durch, diesmal indem Sie das System über seinen CNAME (https://gis.domain.com/portal/home/) ansprechen.
Wenn Ihr System auf diese Weise korrekt funktioniert, machen Sie die Änderung in der Hosts-Datei rückgängig und bitten die F5-Administratoren, ihre Konfigurationsarbeiten abzuschließen.
Anweisungen für F5 Administratoren
Aus Sicht von BIG-IP handelt es sich um eine einfache Konfiguration. Das ArcGIS Enterprise-System besteht aus mehreren Komponenten. Aus Sicht des Reverse Proxys gibt es jedoch nur einen einzelnen Backend-Webserver-Knoten, der auf HTTPS/443 hört. Das eine Konfigurationselement, das sich von anderen Systemen unterscheiden kann, ist, dass ArcGIS Enterprise vom Reverse Proxy verlangt, einen X-Forwarded-Host Header einzuschließen.
Auf hoher Ebene wird Ihre Proxy-Konfiguration allen HTTPS-Verkehr zum gis.domain.com-CNAME terminieren und HTTPS zum einzelnen Backend-Knoten machine1.domain.local neu initiieren. Der Webserver an dieser Adresse unterstützt zwei „Kontexte“, einen für jede Hauptkomponente des ArcGIS Enterprise Systems (Portal for ArcGIS und ArcGIS Server): /portal und /server.
Wie in der Einleitung dieses Artikels beschrieben gehen wir davon aus, dass Sie drei Netzwerke mit Ihrem BIG-IP Proxy verbunden haben: ein Client-Netzwerk, ein Server-Netzwerk und Ihr Administrationsnetzwerk.
Dieser Artikel setzt voraus, dass Sie Experte in BIG-IP Administration sind und nur Hinweise zu den Schritten benötigen, um diesen virtuellen Server und Backend-Pool in optimaler Reihenfolge zu konfigurieren.
Schritt Eins: Proxy für den Webserver einrichten
Der CNAME für dieses System sollte Ihnen bereits bekannt sein oder mitgeteilt worden sein. Ein passendes TLS-Zertifikat für diesen CNAME sollte ebenfalls bereitgestellt werden. Die Zertifizierungsstelle muss eine sein, der die Clients dieses Systems vertrauen.
TLS-Zertifikat installieren
Installieren Sie das TLS-Zertifikat für den Virtual Server in BIG-IP (z.B., Subject gis.domain.com)
System > Certificate Management > Traffic Certificate Management > SSL Certificate List > Import SSL Certificate
Client SSL Profil erstellen
Erstellen Sie ein Client-Profil zur Terminierung von Client-TLS-Verbindungen mit dem Zertifikat für den Namen gis.domain.com.
Local Traffic > Profiles > SSL > Client > Create
Pool mit einfachem Monitor erstellen
Erstellen Sie einen Backend-Pool für den Webserver (z.B. https://machine1.domain.local/) mit einem einfachen Monitor zur Bestimmung, ob die Knotenressource „up“ oder „down“ ist.
Local Traffic > Pools > Pool List > Create
<\/span><\/H3> <\/P>Erstellen Sie ein HTTP Services Profil (Fügen Sie den X-Forwarded-Host Header hinzu)<\/H3>Der X-Forwarded-Host Header ermöglicht es ArcGIS Enterprise, den Wert des Host-Headers zu kennen, der bei BIG-IP eingegangen ist. Das ArcGIS Enterprise System überprüft diesen Wert anhand seiner Konfiguration, um sicherzustellen, dass Clients es auf angemessene Weise adressiert haben. Wenn der X-Forwarded-Host Header nicht vorhanden ist oder einen falschen Wert enthält, gibt ArcGIS Enterprise eine HTTP-Weiterleitung aus, um anzuzeigen, wie es glaubt, dass es adressiert werden sollte. Dies kann zu Weiterleitungsschleifen führen. Falls ArcGIS Enterprise eine Weiterleitungsschleife erkennt, wird diese unterbrochen und ein Fehler zurückgegeben.<\/P>Ein X-Forwarded-Host Header kann mit einer iRule eingefügt werden:<\/P>when HTTP_REQUEST {
HTTP::header insert X-Forwarded-Host [HTTP::host]
}<\/PRE> <\/P>Diese Anweisung nimmt den Wert des ankommenden Host-Headers der Anfrage und setzt ihn als Wert des X-Forwarded-Host Headers für den Standard-Pool.<\/P>Erstellen Sie den Virtual Server<\/H3>Local Traffic > Virtual Servers > Create<\/P>Wählen Sie "Standard" als Typ des Virtual Servers. Geben Sie Ihr zuvor erstelltes SSL Profile (Client) mit Ihrem SSL-Zertifikat an. Beim Angeben eines Serverprofils besteht das Konfigurationsziel darin, einen TLS-Tunnel zum Backend zu erreichen. Dies kann mit der Standard-Einstellung "serverssl" innerhalb von BIG-IP erreicht werden. Setzen Sie "Source Address Translation" auf Auto Map.<\/P>
<\/span><\/P> Wählen Sie auf der Registerkarte Ressourcen Ihren zuvor erstellten Pool aus.<\/P>
<\/span><\/P> <\/P>Schritt Zwei: Validieren Sie das Proxying zu ArcGIS Enterprise<\/H2>Es gibt zwei Schritte, um die Wirksamkeit dieser Konfiguration zu validieren. <\/P>Vertrauen und Header validieren<\/H3>Vorausgesetzt, die showHeaders.aspx Seite wurde auf dem Backend-Webserver bereitgestellt, verwenden Sie einen Webbrowser, um zu https:\/\/gis.domain.com\/showHeaders.aspx<\/A> zu navigieren. Der Browser sollte frei von Zertifikatswarnungen sein. Der Seitenantworttext sollte die Wirksamkeit des X-Forwarded-Host Headers in Ihrer Konfiguration bestätigen.<\/P> 
<\/span><\/P> <\/P>An diesem Punkt, nachdem der Header-Durchfluss zum Backend bestätigt wurde, ist das showHeaders.aspx Tool nicht mehr erforderlich. Wenn Ihr System für PRODUKTION oder eine Umgebung vorgesehen ist, in der die Informationen nicht offengelegt werden sollten, sollte das Tool entfernt werden.<\/P>
P>Diese Anweisungen enthielten während des Bereitstellungs-/Konfigurationsprozesses "Systemvertrauensprüfungen" und Validierungen. Diese Maßnahmen sollten bestimmen, ob es vernünftig ist, zum nächsten Schritt der Anweisungen überzugehen. Diese Maßnahmen beweisen nicht, dass das System akzeptabel ist. Am Ende gehen wir davon aus, dass das gesamte System funktioniert. Mit anderen Worten stellen diese Tests fest, dass das System funktionale Kohärenz besitzt.P>Die Übergabe des Systems zur
Abnahmetestung ist der angemessene nächste Schritt. Ziel der Abnahmetestung ist es, das bereitgestellte System an den Geschäftszielen zu messen, die es unterstützen muss.GesundheitsprüfungP>Die einfache Überwachung (Simple Monitoring), die in den Anweisungen für die F5 Administratoren enthalten ist, ermöglicht es BIG-IP, die Weiterleitung von Anfragen an das ArcGIS Enterprise System zu stoppen, wenn der Knoten (d.h. machine1.domain.local) ausgefallen oder nicht erreichbar ist. Für ein System wie dieses mit nur einem Back-End Pool-Mitglied ist dies (ein Simple Monitor) das volle Ausmaß der empfohlenen Gesundheitsprüfung.P>Grundsätzlich kann BIG-IP mit Out-of-Band-Gesundheitsprüfungen konfiguriert werden, die von der ArcGIS Enterprise Software verlangen, ihre Gesundheit zu bestätigen oder zu validieren, dass bestimmte HTTPS-Anfragen mit bestimmten Antwortinhalten erfolgreich sind. Zum Beispiel stellt die Portal for ArcGIS Komponente von ArcGIS Enterprise diesen Endpunkt bereit:
https://developers.arcgis.com/rest/enterprise-administration/portal/health-check-portal.htm. In einem Ein-Knoten-System eliminiert eine Antwort auf ein Gesundheitsprüfungsproblem im Wesentlichen jeglichen Zugriff auf das System. Der Vorteil davon ist, dass der Reverse Proxy Clients einen generischen Fehler anzeigen kann, dass das System ausgefallen ist. Der Nachteil davon ist, dass ein temporäres Problem, Teilproblem oder Fehlinterpretation durch die Gesundheitsprüfung jeglichen Zugriff auf das System eliminiert, obwohl es für viele Anwendungsfälle noch nutzbar sein könnte. Die Wahrscheinlichkeit von Fehlalarmen (unhealthy findings) bei formalen/komplexen Gesundheitsprüfungen kann dazu führen, dass die Systemzuverlässigkeit für Endbenutzer geringer ist als bei Fehlmeldungen (healthy findings), die mit einfacher Knotenüberwachung verbunden sind. Mit anderen Worten: Für ein Ein-Knoten-System ist Komplexität der Feind der Zuverlässigkeit; bleiben Sie bei einem Simple Monitor.DanksagungenP>Dieser Artikel wurde basierend auf der Arbeit von Roger Schlogel erstellt, einem Berater bei Esris Professional Services.P> P>
