Weiterleitung von HTTP(S)-Anfragen nach innen
Um, zum Beispiel, einem Profil Daten per HTTP zu senden, muss man eine bestimmte URL ansprechen. Der schematische Aufbau der URL ist:
http://<URL/IP und Port Integration Server>/dw/Request/<URL-Suffix des Profils> |
Wenn nun ein DMZ-Server im Einsatz ist, möchte man, dass Anfragen dieser Art an den DMZ-Server gehen und von dort an den inneren Integration Server weitergeleitet werden (Forwarding).
Hinweis: Bedenken Sie bitte generell, welche Pfade Sie über den DMZ-Server zugänglich machen möchten und richten Sie nur die ein, die Sie wirklich benötigen.
Standard-Kontext auf DMZ-Server
Per Default wird auf dem DMZ-Server auf HTTP-Anfragen reagiert, deren URL-Pfad mit dem URL-Kontext /forward beginnen. Diese Vorgabe kann in der Konfigurationsdatei ./etc/startup_dmz.xml (auf dem DMZ-Server) über die Parameter servletContext und servletPath geändert werden. Nachfolgend gehen wir davon aus, dass die Default-Einstellungen verwendet werden, also servletContext=/forward und servletPath=/*
Forwarding-Regeln auf DMZ-Server
Auch wenn per Default auf dem DMZ-Server auf den URL-Kontext /forward reagiert wird, müssen dort noch Forwarding-Regeln definiert werden, also wie solche Anfragen weitergeleitet werden, da der DMZ-Server selbst nicht auf die Anfragen antwortet. Die Definition dieser Forwarding-Regeln erfolgt in der Konfigurationsdatei ./etc/forward.properties (auf dem DMZ-Server).
Falls der DMZ-Server innerhalb ./etc/hub.xml mehrere HTTP-Listener (Port 80, 443, usw.) hat, werden alle Requests, die über einen der HTTP-Listener eintreffen und einer Forwarding-Regel entsprechen, entsprechend der Regel weitergeleitet.
Jede Zeile stellt eine unabhängige Regel dar. Die linke Seite (Quell-Kontext), links neben dem Gleichheitszeichen, muss eindeutig sein.
Änderungen in der Datei ./etc/forward.properties werden zur Laufzeit erkannt und neu ausgewertet. Ein Neustart des Systems ist nicht notwendig.
Für Diagnosezwecke kann man das HTTP-Requestlog und das Serverlog unter ./logs auswerten. Achtung: Die Zeiten im Requestlog sind in der Zeitzone UTC, die im Serverlog sind in der Systemzeitzone.
Gehen wir nun von folgender Forwarding-Regel aus und davon, dass der innere Integration Server die gezeigte IP hat.
...
/forward/*=http://192.168.213.12:80
...In diesem Fall werden alle Anfragen an den DMZ-Server, die mit dem Pfad /forward beginnen, an den inneren Integration Server weitergeleitet. Alle anderen Pfade werden nicht weitergeleitet.
Die Anfrage http://<URL/IP und Port DMZ-Server>/forward/dw/Request/<URL-Suffix des Profils> würde also weitergeleitet werden an http://192.168.213.12:80/dw/Request/<URL-Suffix des Profils>.
Wenn man nicht alle Anfragen weiterleiten möchte, kann man es auch etwas spezifischer machen.
...
/forward/dw/Request/*=http://192.168.213.12:80/dw/Request
...Oder noch spezifischer mit folgender Regel. Damit könnte man die URL-Suffixe von HTTP-Profilen so setzen, dass nur manche von außen über den DMZ-Server ansprechbar sind. Ein HTTP-Profil mit URL-Suffix outside/example1 wäre dann über den DMZ-Server erreichbar und ein HTTP-Profil mit URL-Suffix example2 wäre nur über den inneren Integration Server erreichbar.
...
/forward/dw/Request/outside/*=http://192.168.213.12:80/dw/Request/outside
...Weitere Kontexte auf DMZ-Server einrichten
Damit auf dem DMZ-Server auf weitere Kontexte reagiert wird (also nicht nur auf /forward), auf der innere Integration Server normalerweise reagiert, muss für den CommunicationForwardManager der Parameter addStandardServlets in der Konfigurationsdatei ./etc/startup_dmz.xml (auf dem DMZ-Server) auf true gesetzt werden.
<Call name="addApplication">
<Arg>
<New class="com.ebd.hub.datawizard.app.CommunicationForwardManager">
...
<Call name="addStandardServlets"><Arg type="boolean">true</Arg></Call>
...
</New>
</Arg>
</Call>Folgende Kontexte werden damit auf dem DMZ-Server aktiviert.
/dw/Request /dw/request | Siehe Abschnitt HTTP (Eingangsagent). |
/dw/Trigger /dw/trigger | Siehe Abschnitt Trigger/Externer Aufruf. |
/dw/oauth2 | Siehe Abschnitt OAuth 2.0 (Client). |
/dw/cloud | Siehe Abschnitt CloudStorage (Kanal-Einstellungen). |
/dw/register/oauth2 | Siehe Abschnitt OAuth 2.0 (Server). |
/partner/AS2Retrieve | Wichtiger Hinweis: Beachten Sie bitte, dass hierfür weitere Einstellungen nötig sind, siehe Abschnitt AS2-Handling unten. |
Auch hier müssen erst entsprechende Forwarding-Regeln definiert werden, damit eine Weiterleitung stattfindet. Wichtiger Hinweis: Beachten Sie bitte, dass hier Groß-/Kleinschreibung relevant ist und definieren Sie bitte jeweils beide Varianten Request/request und Trigger/trigger.
...
/dw/request/*=http://<URL/IP und Port innerer Integration Server>/dw/request
/dw/Request/*=http://<URL/IP und Port innerer Integration Server>/dw/Request
/dw/trigger/*=http://<URL/IP und Port innerer Integration Server>/dw/trigger
/dw/Trigger/*=http://<URL/IP und Port innerer Integration Server>/dw/Trigger
/dw/oauth2/*=http://<URL/IP und Port innerer Integration Server>/dw/oauth2
/dw/cloud/*=http://<URL/IP und Port innerer Integration Server>/dw/cloud
/dw/register/oauth2/*=http://<URL/IP und Port innerer Integration Server>/dw/register/oauth2
/partner/AS2Retrieve/*=http://<URL/IP und Port innerer Integration Server>/partner/AS2Retrieve
...Hinweis: Wenn auf dem inneren System ein HTTPS-Listener aktiv ist, kann das Forwarding auch über HTTPS erfolgen. Da die Verbindung vom DMZ-Server zum inneren Integration Server in einem geschützten Netzwerkteil erfolgt, ist aber dort eine nochmalige Verschlüsselung per HTTPS normalerweise nicht notwendig.
AS2-Handling
AS2-Requests können entweder auf dem DMZ-Server behandelt oder an den inneren Integration Server weitergeleitet werden. Zudem ist eine Kombination beider Varianten möglich.
AS2 auf DMZ-Server
Parameter handleAS2 in der Konfigurationsdatei ./etc/startup_dmz.xml (auf DMZ-Server) steht auf true.
AS2-Service auf DMZ-Server ist aktiv.
AS2-Requests werden per Message nach innen weitergereicht. Ist der innere Integration Server (vorübergehend) nicht erreichbar, werden die Messages (wie auch bei FTP, usw.) gepuffert.
AS2-Weiterleitung
Parameter handleAS2 in der Konfigurationsdatei ./etc/startup_dmz.xml (auf DMZ-Server) steht auf false.
Weiterleitung für Kontext /partner/AS2Retrieve ist eingerichtet (siehe Anleitung oben).
Alle AS2-HTTP-Requests werden nach innen gereicht und der innere Integration Server sendet MDNs und Nachrichten.
AS2 auf DMZ-Server und Weiterleitung
Hier richten Sie AS2 auf dem DMZ-Server ein (siehe Anleitung oben), definieren aber zusätzlich eine Weiterleitung über den Default-Kontext /forward (siehe Anleitung oben).
/forward/AS2Retrieve/*=http://<URL/IP und Port innerer Integration Server>/partner/AS2Retrieve |
AS2-Requests über den Pfad /partner/AS2Retrieve/ werden dann auf dem DMZ-Server verarbeitet und AS2-Requests über den Pfad /forward/AS2Retrieve/ werden an den inneren Integration Server weitergeleitet.
HTTPS einrichten (DMZ-Server)
Sie können HTTPS für die Kommunikation zwischen dem externen Client und dem DMZ-Server verwenden.
Siehe Abschnitt Hinzufügen eines HTTPS-Listeners.
HTTP(S) tunneln (vom DMZ-Server zum inneren System)
Es ist möglich HTTP(S)-Requests über den MessageService zu tunneln. Dazu fügen Sie bitte folgende Option in der Konfigurationsdatei ./etc/startup_dmz.xml (auf DMZ-Server) ein. Die Forwarding-Regeln müssen auch in diesem Fall angepasst werden (siehe oben).
<Set name="tunnelHttp">true</Set>Weiterleitung für FTP, SSH, OFTP nach innen
Im FTP-Server kann man Benutzer oder auch nur einzelne Verzeichnisse eines Benutzers von der Weiterleitung an den inneren Integration Server ausschließen. Die Dateien verbleiben dann im FTP-Verzeichnis und der Administrator ist dafür verantwortlich, die Dateien zu kopieren bzw. zu löschen.
In der Datei ./etc/startup_dmz.xml wird der Pfad der Konfigurationsdatei definiert, in der hinterlegt ist, welche FTP-/SSH-/OFTP-Benutzer/-Dateien nicht an den inneren Integration Server weitergeleitet werden.
<Set name="noForwardRulesForFtp">./etc/admin/datawizard/ftp_user_rules.properties</Set>Hier ein Beispiel für die Datei ftp user rules.properties:
# No forwarding for user dummy1 at all
dummy1=
# No forwarding for user dummy2 when upload is done in folder tmp and output
# (relative subdirs under home dir of user)
dummy2=tmp;outputWird nur der Name eines FTP-/SSH-/OFTP-Benutzers angegeben, dann werden alle Dateien, die dieser Benutzer auf dem DMZ-Server ablegt, in den Verzeichnissen belassen. Mit zusätzlicher Angabe eines oder mehrerer Unterverzeichnisnamen, werden die Dateien in den angegebenen Unterverzeichnissen nicht an den inneren Integration Server weitergeleitet. Die Unterverzeichnisnamen werden durch Semikolons getrennt.
OFTP auf dem DMZ-Server
Es ist möglich, den OFTP-Service auf dem DMZ-Server laufen zu lassen, und diesen Service vom inneren Integration Server aus anzusprechen. Dazu muss der innere Integration Server die Kontaktaufnahme zum DMZ-Server initiieren. Um dies zu ermöglichen müssen folgende Einstellungen vorgenommen werden.
1. Beim Anlegen von OFTP-Kanälen müssen diese dem DMZ-Server bekannt gegeben werden. Außerdem müssen die zugehörigen OFTP-Home-Verzeichnisse (für eingehende und ausgehende Daten) auf dem DMZ-Server angelegt werden. Folgendes Listing zeigt den Eintrag hierfür in der Konfigurationsdatei ./etc/startup.xml des inneren Integration Servers im Abschnitt "DataWizard".
...
<!-- Create OFTP, SSH & FTP user homes in DMZ as well & enable OFTP via DMZ, etc -->
...
<Set name="useOFtpUserOfDmz">true</Set>
...Hinweis: Analoges gilt für FTP (useFtpUserOfDmz) und SSH (useSshUserOfDmz).
2. ISDN: Dem DMZ-Rechner muss gegebenenfalls die ISDN-Nummer mitgeteilt werden, mit dem der OFTP-Service arbeiten soll. Das folgende Listing zeigt den Eintrag in der Konfigurationsdatei ./etc/startup_dmz.xml des DMZ-Servers im Abschnitt CommunicationForwardManager.
...
<Set name="isdnNumber">Ihre_ISDN_Nummer</Set>
...DMZ Hybrid Mode
Es ist möglich den DMZ-Server in einen speziellen Modus zu setzen, in dem keine Anfragen an den DMZ-Server an das innere System weitergeleitet werden. D. h. FTP-Uploads verbleiben z. B. im Verzeichnis des FTP-Benutzers, HTTP-Anfragen werden mit Status 404 beantwortet, etc.
Alle anderen Funktionen (z. B. Statusabfragen für das Dashboard, Aufträge vom inneren Integration Server an den DMZ-Server (Senden/Holen von Daten), etc.) werden jedoch wie gewohnt ausgeführt.
Damit agiert der DMZ-Server z. B. für FTP wie jeder andere FTP-Server, da keine eventbasierte Behandlung der Dateien stattfindet.
Fügen Sie dazu folgenden Abschnitt (im CommunicationForwardManager) in die Konfigurationsdatei ./etc/startup_dmz.xml ein.
<Set name="noForwardEvents">true</Set>Wichtiger Hinweis: Wenn der AS2-Service auf dem DMZ-Server installiert und gestartet wird mit der Option handleAS2 in Konfigurationsdatei ./etc/startup_dmz.xml, also nicht mit HTTP-Forwarding, sondern mit direktem Handling, dann werden AS2-Events dennoch nach innen gereicht.