forward.properties, addStandardServlets und tunnelHttp

Die  Lobster Data Platform  (LDP) leitet HTTP-Anfragen auf einer DMZ anders weiter als das Legacy-System _data 4.6. Standardmäßig läuft alles über einen passiven NIO‑Tunnel. Wer migriert oder fehleranalysiert, muss die drei Mechanismen unterscheiden können: forward.properties, addStandardServlets und tunnelHttp. Dieser Artikel erklärt das Standardverhalten, die drei Erweiterungsoptionen und die Unterschiede zur Legacy-Konfiguration.

 HINWEIS Dieses Verhalten gilt für die LDP ab Version 26.1.2.

Standardverhalten der LDP

Die LDP nutzt auf dem DMZ-Server standardmäßig einen tunnelbasierten Reverse Proxy. Die Komponente heißt dmz.server. Sie leitet den gesamten HTTP-Root (/) über einen passiven NIO-Tunnel an die innere Plattform weiter.

Das hat drei Konsequenzen für die Konfiguration:

• Sie müssen addStandardServlets nicht aktivieren. Der DMZ-Server leitet alle HTTP-Anfragen automatisch weiter.

• Sie brauchen keine forward.properties. Im Idealfall existiert die Datei gar nicht.

• Die vollständige Platform-UI ist über die DMZ erreichbar. Auch die Login-Seite. Das ist beabsichtigt.

In einem HA-Setup (High Availability) verteilt der DMZ-Server die Anfragen per Round-Robin auf die Working Nodes. Authentifizierte Anfragen routet er per Session-Affinität an den korrekten Node. Dazu nutzt er den Header X-ENV-SessionToken.

Verbindungsrichtung

Die Verbindungsrichtung ist umgekehrt gegenüber dem Legacy-Verhalten. Die innere Plattform baut die Tunnel-Verbindung ausgehend zum DMZ-Server auf. Eingehende Firewall-Regeln vom DMZ-Netz zum inneren Netz für HTTP-Verkehr sind nicht nötig.

Benötigte Ports

Auto-Discovery

Wenn in der Datei startup_dmz.xml keine DmzServerApp konfiguriert ist, springt der DmzServerAutoConfigurator ein. Er startet automatisch einen DMZ-Server mit folgenden Standardwerten:

• Tunnel-Port: 30000. Sie können den Port über die System-Property dmz.tunnel.port ändern.

• Tunnel-Secret: wird automatisch erzeugt. Die LDP speichert es in ./etc/dmz_tunnel_secret.property.

• Proxy-Kontext: /. Der DMZ-Server leitet den gesamten HTTP-Root weiter.

• Load-Balancing: aktiviert.

Login an der DMZ einschränken

Die LDP stellt die vollständige Platform-UI über die DMZ bereit. Damit ist auch die Login-Seite von außen erreichbar. Das könnte Sie überraschen. Sie kennen vom Legacy-Verhalten, dass die DMZ nur bestimmte Pfade weiterleitet.

Administratoren steuern den Zugang über die Benutzer- und Rollenverwaltung. Jede Rolle hat ein Flag für die DMZ‑Anmeldung. Setzen Sie das Flag, um die Anmeldung über die DMZ für die Rolle zu unterbinden.

Beispiel: Monitoring-Rollen dürfen sich über die DMZ anmelden. Administrative Rollen bleiben auf den internen Zugang beschränkt.

TIPP Details zur Konfiguration finden Sie im Artikel Rollen in der Verwaltungsdokumentation.

addStandardServlets: zusätzliche Servlet-Kontexte aktivieren

Der Parameter addStandardServlets im CommunicationForwardManager aktiviert zusätzliche HTTP-Weiterleitungs-Servlets auf dem DMZ‑Server. Diese Servlets nutzen den Legacy-Mechanismus. Sie arbeiten parallel zum Tunnel-Proxy. Der Legacy-Mechanismus besteht aus HttpForwardServlet und forward.properties.

Konfiguration

<Call name="addApplication">
    <Arg>
        <New class="com.ebd.hub.datawizard.app.CommunicationForwardManager">
            ...
            <Call name="addStandardServlets">
                <Arg type="boolean">true</Arg>
            </Call>
            ...
        </New>
    </Arg>
</Call>

Aktivierte Kontexte

Mit addStandardServlets=true aktiviert die LDP folgende Servlets auf dem DMZ-Server.

 WICHTIG  Groß- und Kleinschreibung ist relevant. Definieren Sie jeweils beide Varianten für Request/request und Trigger/trigger.

Voraussetzung: forward.properties

Achtung

Wenn Sie addStandardServlets aktivieren, muss die Datei ./etc/forward.properties existieren und korrekt konfiguriert sein. Jedes Servlet löst sein Ziel über forward.properties auf. Ohne passende Einträge liefern Anfragen HTTP 404.

Beispiel-Konfiguration:

/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

Wann brauchen Sie addStandardServlets?

In den meisten LDP-Installationen brauchen Sie addStandardServlets nicht. Der Tunnel-Proxy leitet bereits den gesamten HTTP-Root weiter.

Sinnvoll ist die Aktivierung in zwei Fällen:

• Sie wollen bestimmte Pfade über den Legacy-Mechanismus leiten. Der Legacy-Mechanismus arbeitet über direkte HTTP-Verbindung oder MessageService-Tunnel.

• Sie benötigen Kompatibilität mit bestehenden Konfigurationen. Diese basieren auf forward.properties.

Hinweis

Nach der Servlet-Registrierung ruft der CommunicationForwardManager automatisch startDMZServerApp() auf. Das löst den DmzServerAutoConfigurator aus. Die LDP startet den Tunnel-Proxy also zusätzlich, sofern er nicht bereits in der XML konfiguriert ist. Beide Mechanismen laufen dann parallel: der Tunnel-Proxy und die Legacy-Servlets.

tunnelHttp: HTTP-Anfragen über den MessageService tunneln

Die Option tunnelHttp bietet einen alternativen Transportweg. Der DMZ-Server baut keine direkte HTTP-Verbindung zum inneren System auf. Stattdessen tunnelt er HTTP-Anfragen über den MessageService auf Port 8020.

Konfiguration

<Set name="tunnelHttp">true</Set>

Funktionsweise

Mit tunnelHttp=true verarbeitet die LDP eine externe Anfrage in fünf Schritten:

1. Externe HTTP-Anfragen treffen beim HttpForwardServlet ein.

2. Das Servlet löst das Ziel über forward.properties auf.

3. Statt einer direkten HTTP-Verbindung sendet der MessageService die Anfrage über tunnelByMessage() an die innere Plattform.

4. Die innere Plattform verarbeitet die Anfrage. Sie sendet die Antwort über denselben MessageService-Kanal zurück.

5. Die DMZ-Seite überspringt das Virenscanning. Die innere Plattform übernimmt es stattdessen.

Voraussetzungen

• Sie müssen handleAS2 auf true setzen. Die Startup-Validierung erzwingt das mit der Meldung AS2 service must run locally if HTTP-tunnel is used.

• Sie müssen forward.properties konfigurieren. Die Datei löst die Zielpfade auf.

Vergleich der Transportwege

Hinweis

Der tunnelHttp-Modus ist weniger performant als der NIO-Tunnel-Ansatz. Er unterliegt den Einschränkungen des MessageService. Er eignet sich nur für Szenarien ohne NIO-Tunnel und ohne direkte HTTP-Verbindung.Welche Konfiguration wann?

Tipp

Für neue LDP-Installationen empfehlen wir die Standardkonfiguration. Sie kommt ohne addStandardServlets und ohne forward.properties aus. Der Tunnel-Proxy deckt alle HTTP-Weiterleitungen ab. Zusätzlich bietet er Cluster-Support, WebSocket-Unterstützung und dynamisches Node-Management.

Vergleich: LDP und Legacy _data 4.6

Migrationshinweise von _data 4.6

Beim Wechsel von _data 4.6 auf die aktuelle Plattform prüfen Sie drei Punkte:

• WebMonitorApplication entfernen. Löschen Sie den Eintrag aus startup_dmz.xml. Entfernen Sie auch die zugehörige WebMonitor-Datenbankkonfiguration aus database.xml.

• forward.properties prüfen. Wenn Sie ausschließlich den Tunnel-Proxy nutzen, brauchen Sie die Datei nicht mehr. Sie können sie entfernen.

• Benutzer migrieren. Plattformbenutzer mit entsprechenden Rollen ersetzen die WebMonitor-Benutzer.

Verwandte Themen

• Klasse CommunicationForwardManager

• Weiterleitung von HTTP/FTP/SSH/OFTP nach innen

• DMZ-Verbund

• Hohe Verfügbarkeit (Ausfall innerer Server)