Reverse Invoke
Reverse Invoke bezeichnet die Technik, den Aufbau von Netzwerkverbindungen immer vom geschützten Netz (Intranet) aus durchzuführen. Dies erhöht die Netzwerksicherheit, da keine Verbindung von außen in das geschützte Netzwerk hinein (durch die Firewall) aufgebaut wird. Wenn also eine Verbindung zwischen einem Rechner in der demilitarisierten Zone (DMZ) und einem Rechner im Intranet (hinter der Firewall) hergestellt werden soll, darf nicht der Rechner in der DMZ diese öffnen, sondern nur der Rechner im Intranet.
Beim Betrieb einer Web-Anwendung mit einem SAP-System sieht das dann beispielsweise so aus.
Wenn der Browser eine Web-Anwendung in einem SAP-System startet, verbindet er sich mit dem SAP Web Dispatcher, der in der DMZ steht. Der Web Dispatcher dient als Einstiegspunkt in das SAP-System: er führt die Lastverteilung durch und leitet die Anfrage an einen geeigneten Server in SAP-System weiter. Hierbei wird der Aufbau der Verbindung jedoch nicht vom Web Dispatcher, sondern vom Internet Communication Manager (ICM) des Applikationsservers durchgeführt. Die Firewalls können wie folgt konfiguriert werden:
-
Die vordere Firewall lässt eingehende Verbindungen zum HTTP(S)-Port des SAP Web Dispatchers zu.
-
Die Firewall hinter der DMZ lässt keinen Verbindungsaufbau von außen zu.
Die Verbindung zwischen SAP Web Dispatcher und ICM (Applikationsserver) wird als Reverse Invoke Verbindung bezeichnet.
Reverse-Invoke-Verbindungen: Client und Server
Bei einer Reverse-Invoke-Verbindung wird das Programm, das die Verbindung aufbaut (hier der ICM) als Server bezeichnet und das Programm in der DMZ (hier der SAP Web Dispatcher) als Client. Obwohl der Verbindungsaufbau durch den ICM erfolgt und dieser somit aus TCP/IP-Sicht als Client agiert, ist aus logischer Sicht der ICM der Server.
Da der Verbindungsaufbau vom Server aus erfolgt, genügt es nicht, dass der Client Adresse und Port des Servers kennt. Der Server muss auch Adresse und Port des Clients kennen, damit er sich als Server dort registrieren kann.
Wenn - wie im Bild dargestellt - der SAP Web Dispatcher der Client ist und der ICM im Intranet der Server, so hat der Client einen Port nach außen geöffnet (Einstiegspunkt von außen). Nach innen wird ein Port zur geöffnet, an dem sich Server registrieren können ( Reg. Port). Diesen Port (und die Adresse) muss der Server (hier der ICM) kennen, um die Verbindung aufzubauen. Der Server kann dann über diese Verbindung die Registrierung vornehmen, d.h. er teilt dem Client mit, zu welcher Adresse/Port-Kombination er Verbindungen annimmt ( Pseudo-Port). Der Server nimmt auf diesem Port physisch keine Verbindungsanfragen entgegen, aber der Client kann Verbindungsanfragen eines Browsers zu diesem Server/Port über die bestehende Verbindung abwickeln. Logisch geht die Verbindungsanfrage vom Client zum Server.
Der Aufbau der Reverse Invoke Verbindung läuft also in folgenden Schritten ab:
-
Der Client öffnet einen Port ( Reg. Port), der dem Server bekannt ist.
-
Der Server verbindet sich mit dem Reg. Port und registriert seinen eigenen Service ( Pseudo-Port). Die Verbindung bleibt bestehen.
-
Bei einem Verbindungsaufbau vom Client zum Pseudo-Port des Servers öffnet der Client keine neue Verbindung, sondern nutzt die bestehende Reverse Invoke Verbindung.
Implementierung
Die Reverse Invoke Funktionalität ist im SAP NetWeaver Application Server in der Netzwerkschicht ( NI Netzwerkschnittstelle) implementiert und kann damit von allen auf NI basierenden SAP-Programmen benutzt werden.
Reverse Invoke ist so implementiert, dass zu jedem Verbindungsaufbau zum Server auch eine eigene Verbindung besteht. Der Client hält zu jedem Server eine Kontrollverbindung und eine Anzahl von Datenverbindungen. Die Anzahl hängt von der Anzahl der Verbindungsanfragen ab. Die logischen Datenverbindungen zu dem Server werden somit nicht über eine Verbindung gebündelt (kein Multiplexing).
Um den Verbindungsaufbau zu beschleunigen, werden die Verbindungen bei der Registrierung aufgebaut und in einem Pool gehalten. Die Anzahl der Verbindungen im Pool ist konfigurierbar und sollte abhängig von der Anzahl der Verbindungsanfragen pro Zeiteinheit sein. Sie können das Pooling auch deaktivieren. Dann werden die Verbindungen erst bei Bedarf aufgebaut ( on demand).
Um die Server, die sich bei dem Client registrieren dürfen, zu reglementieren, kann dem Client eine Access Control List (ACL) mitgegeben werden. Diese ACL besteht aus IP Adressen und Masken, welche zugelassen bzw. abgelehnt werden.
Die Verbindungen können sowohl auf IPv4 als auch IPv6 basieren, UDS-Verbindungen (Unix Domain Sockets) werden nicht unterstützt.