Kommunikation zwischen Integration Server und DMZ‌

Allgemeine Architektur


images/download/attachments/135168570/DMZ-version-3-modificationdate-1740043178485-api-v2.png


Ein DMZ-Server ist ein eigener Lobster Integration Server, bei dem aus Sicherheitsgründen nur die benötigten Kommunikations-Dienste, wie z. B. FTP oder SMTP ausgeführt werden. Die Firewall zwischen diesem DMZ-Server und dem Internet erlaubt nur die benötigten Ports/Protokolle.

Die Verbindung zwischen DMZ-Server und Lobster_data im Intranet erfolgt über ein proprietäres Protokoll der Lobster GmbH, dem Message Service. Damit ist ein Eindringen von außen in das innere System verhindert. Beim Message Service handelt es sich um ein HTTP-getunneltes Protokoll, das ausschließlich TCP/IP nutzt. Siehe auch Abschnitt Konfiguration allgemein‌ (DMZ).

Zwischen DMZ-Server und innerem Lobster_data Server ist ebenfalls eine Firewall erforderlich. Sie muss für den angegebenen Message-Port (üblicherweise 8020, kann jedoch konfiguriert werden) den Datenverkehr in beide Richtungen erlauben. Zudem werden HTTP-Requests und -Responses in beide Richtungen durchgereicht, es muss also auch der HTTP-Port (üblicherweise 80, kann jedoch konfiguriert werden) freigegeben werden.

Der Message Service kann für sehr große Sicherheitsansprüche auch im Pushback-Modus konfiguriert werden, dann geht der Verbindungsaufbau immer vom inneren Server aus, und es werden keine eingehenden Verbindungen ins Intranet gebraucht.

Wird eine maximale Nachrichtengröße definiert oder soll Lobster_data Dateien via DMZ-Server versenden/bereitstellen, so müssen diese Dateien vom inneren System auf den DMZ-Server kopiert werden. Dazu muss in der Firewall zusätzlich FTP oder SFTP (konfigurierbar) von Lobster_data zur DMZ erlaubt sein.

Verwendung des DMZ-Servers in der Lobster_data-GUI


In einem Profil

Die Checkbox Via DMZ muss im Eingangsagenten (Phase 1) bzw. im Antwortweg (Phase 6) gesetzt sein. Hinweis: Die Checkbox ist nur sichtbar, wenn ein DMZ-Server vorhanden ist. Ist allerdings folgende Option in der Konfigurationsdatei ./etc/startup.xml vorhanden, dann wird sie trotzdem angezeigt.


...
<Set name="ignoreDMZSettings">true</Set>
...


  • CloudStorage (Eingangsagent Cron)

  • FTP/FTPS/SFTP (Eingangsagent Cron)

  • X.400 (Mail)

  • Antwortweg AS2

  • Antwortweg AS4

  • Antwortweg CloudStorage

  • Antwortweg Fax

  • Antwortweg FTP (FTPS, SFTP)

  • Antwortweg HTTP(S)

  • Antwortweg X.400

In einem Kanal

Ist die Option Für DMZ unsichtbar nicht gesetzt, werden die Daten des betreffenden Kanals auf den DMZ-Server repliziert.

Ist diese Checkbox Für DMZ unsichtbar gesetzt, werden die Daten dieses Kanals nicht an den DMZ-Server weitergeben. Der Kanal ist dann für den DMZ-Server sozusagen gar nicht vorhanden. Das kann benutzt werden, um Kanäle zu definieren, die von extern nicht zugänglich sein sollen und nur intern verwendet werden.

Im Modul "ASM"


  • Übertragungsart AS2

  • Übertragungsart FTP

  • Übertragungsart Fax

  • Übertragungsart OFTP

  • Übertragungsart X.400

Kommunikations-Szenarien


Partner sendet Daten an Lobster_data via DMZ‌


Siehe hierzu folgende Abbildung für ein FTP-Beispiel.

images/download/attachments/135168570/4-version-3-modificationdate-1740043193414-api-v2.png

(1) Der Partner sendet Dateien per FTP an den DMZ-Server.

(2) Der DMZ-Server erstellt aus Datei-Inhalt und den FTP-Informationen (Anmeldedaten, Home-Verzeichnis, etc.) eine Message und sendet sie nach innen an den Lobster_data. Lobster_data sucht das zu den Daten passende Profil und verarbeitet die Daten. Hinweis: Siehe dazu auch den Hinweis zum Pushback-Modus in Abschnitt Zusammenspiel Lobster_data und DMZ‌ .

(3) Lobster_data sendet eine Antwort-Message an den DMZ-Server, dass die Daten verarbeitet sind.

(4) Ist der Payload größer als die im Parameter streamingSize konfigurierte Angabe (siehe Abschnitt Parameter‌), holt Lobster_data die Daten per FTP vom DMZ-Server ab und verarbeitet sie. Der Verbindungsaufbau erfolgt vom inneren Lobster_data aus.

Lobster_data-Cron-Job holt Partner-Daten ab via DMZ


Siehe hierzu folgende Abbildung für einen Cronjob vom Typ FTP.

images/download/attachments/135168570/3-version-3-modificationdate-1740043206494-api-v2.png

(1) Lobster_data sendet eine Anfrage-Message an den DMZ-Server: Hole Datei(en) per FTP ab (mit Anmeldedaten, Home-Verzeichnis, etc.).

(2) Der FTPService des DMZ-Servers führt den Transfer durch.

(3) Der DMZ-Server sendet eine Antwort-Message an den inneren Lobster_data: Die Datei(en) sind transferiert. Bitte abholen.

(4) Lobster_data holt die Daten per FTP ab und verarbeitet sie. Der Verbindungsaufbau erfolgt vom inneren Server aus.

Lobster_data sendet Daten per Antwortweg via DMZ an Partner‌


Siehe hierzu die folgende Abbildung für einen Transfer per FTP.

images/download/attachments/135168570/1-version-3-modificationdate-1740043218872-api-v2.png

(1) Lobster_data legt eine Datei per FTPService im DMZ-Verzeichnis ab. Der Verbindungsaufbau erfolgt vom inneren Lobster_data aus.

(2) Lobster_data sendet Anfrage-Message an den DMZ-Server: Sende Datei per FTP an Partner (mit Anmeldedaten, Home-Verzeichnis, etc.).

(3) Der DMZ-Server transferiert die Datei zum Partner.

(4) Der DMZ-Server sendet eine Antwort-Message an den inneren Lobster_data: Datei ist transferiert. Hinweis: Siehe dazu auch den Hinweis zum Pushback-Modus in Abschnitt Zusammenspiel Lobster_data und DMZ‌.

Lobster_data stellt Daten auf DMZ für Partner zur Verfügung‌


Siehe hierzu die folgende Abbildung für einen Transfer per FTP.

images/download/attachments/135168570/2-version-3-modificationdate-1740043234153-api-v2.png

(1) Lobster_data legt eine Datei per FTPService im DMZ-Verzeichnis ab. Der Verbindungsaufbau erfolgt vom inneren Lobster_data aus.

(2) Der Partner holt die Datei dort ab.

Anmerkung: Der MessageService wird in diesem Fall nicht benötigt.

Kubernetes-/Docker-Umgebung


Falls Sie einen DMZ-Server in einer Kubernetes- oder Docker-Umgebung betreiben, können Sie die System-Property -Dhub.datawizard.enableDmzIpResolving=true setzen. Das erzwingt, dass die URL des DMZ-Servers immer neu aufgelöst wird, anstatt dass nur die initiale (und gegebenenfalls nicht mehr gültige) IP des DMZ-Servers verwendet wird. Setzen müssen Sie die System-Property auf dem inneren Integration Server, bzw. auf dem Node Controller und allen Working Nodes, wenn Sie mit Load Balancing arbeiten.