Reverse Invoke
Reverse Invoke ermöglicht einen sicheren Verbindungsaufbau ausgehend von einem Applikationsserver des geschützten Netzwerkes, mit einem Server innerhalb der demilitarisierten Zone (DMZ). Die Netzwerksicherheit wird dadurch erhöht, dass Requests von außen, nur dann an einen Server des geschützten Netzwerkes weitergeleitet werden, wenn dieser zuvor eine Verbindung zu dem Server der DMZ aufgebaut hat. Diese Verbindung wird als Reverse Invoke Verbindung bezeichnet. Der direkte Verbindungsaufbau von außen bzw. aus der DMZ mit einem Rechner innerhalb des geschützten Netzwerkes ist beim Einsatz von Reverse Invoke also nicht möglich. Eine bestehende Reverse Invoke Verbindung wird dann von dem Server in der DMZ verwendet, um Requests weiterzuleiten die an diesen Server gerichtet und auch erlaubt sind.
Die Reverse Invoke Funktionalität ist im SAP NetWeaver Applikationsserver in der NI-Netzwerkschicht implementiert und kann damit von allen auf NI basierenden SAP-Programmen verwendet werden.
Die Abbildung zeigt eingehende Requests von außen, an das SAP-System. Der SAP Web Dispatcher steht in der demilitarisierten Zone (DMZ) und dient als Einstiegspunkt in das SAP-System. Er führt die Lastverteilung durch und leitet die Anfrage an einen geeigneten Server im SAP-System weiter. Beim Einsatz von Reverse Invoke erfolgt der Aufbau der Verbindung zum geschützten Netzwerk allerdings nicht vom SAP Web Dispatcher aus, sondern wird vom Internet Communication Manager (ICM) eines Applikationsservers des geschützten Netzwerkes aus aufgebaut.
Bei einer Reverse Invoke Verbindung wird das Programm welches die Verbindung aufbaut, als Server bezeichnet, und das Programm in der DMZ als Client.
Ablauf eines Reverse Invoke Verbindungsaufbaus:
- Der Client öffnet einen Reg.-Port.
- Der Server verbindet sich mit dem Reg.-Port, und registriert seinen eigenen Pseudo-Port.
- Bei einem Verbindungsaufbau vom Client zum Pseudo-Port des Servers öffnet der Client keine neue Verbindung, sondern nutzt die bestehende Reverse Invoke Verbindung.
Die Abbildung zeigt einen SAP Web Dispatcher, der einen Port nach außen geöffnet hat. Zum geschützten Netzwerk hin ist ebenfalls ein Port geöffnet, an welchem sich die Server registrieren können. Dieser Port wird als Reg.-Port bezeichnet. Der Server muss die Adresse und den Port des Clients kennen, um sich dort als Server registrieren zu dürfen. Bei der Registrierung teilt der Server dem Client seinen Pseudo-Port mit, d.h. zu welcher Adresse/Port-Kombination er Verbindungen annimmt. 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.
Zu jedem Verbindungsaufbau zum Server besteht eine eigene Verbindung. Der Client hält zu jedem Server eine Kontrollverbindung und eine Anzahl von Datenverbindungen, die abhängig ist von der Anzahl der Verbindungsanfragen. Es findet somit kein Multiplexing statt. 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. Das Pooling kann auch deaktiviert werden, dann werden die Verbindungen erst bei Bedarf aufgebaut (on demand).
Im Client kann durch das Mitgeben einer ACL (Access Control List) reglementiert werden, welche Server sich registrieren dürfen. Diese ACL besteht aus IP-Adressen und -Masken, welche zugelassen, beziehungsweise abgelehnt werden. Die Verbindungen können sowohl auf IPv4 als auch IPv6 basieren. UDS-Verbindungen (Unix Domain Sockets) werden nicht unterstützt.