Riven Proxy: Theorie und Praxis

08.04.2010 yahe legacy thoughts

Bevor ich nach Mannheim gezogen bin und mein Studium begonnen habe, habe ich überlegt, was ich als Internetanschluss haben möchte. Mir war schon klar, dass ich in den folgenden drei Jahren viel unterwegs sein würde. Also entschied ich mich für einen mobilen Internetanschluss über GPRS und UMTS. In der folgenden Zeit stellte sich heraus, dass ich als Informatikstudent doch Lust habe, einen öffentlich zugänglichen Server zu hosten. Nun fing aber das Problem an: Im Gegensatz zu DSL erhält man bei GPRS/UMTS keine externe IP-Adresse, die aus dem Internet erreichbar ist. Stattdessen bekommt man nur eine interne Netzwerk-IP und die Information, über welches Gateway man Internetseiten aufrufen kann.

Das war natürlich sehr frustrierend. Deshalb begann ich, mir zu überlegen, wie ich dieses Problem lösen könnte. Die Lösung, zu der ich schlussendlich fand, taufte ich Riven Proxy. "Riven" ist Englisch und heißt übersetzt so viel wie "zerissen". Diese Bezeichnung ist auf seine Struktur zurückzuführen, die ich euch gerne erklären möchte. Heutzutage wird man es wohl eher als "split proxy" bezeichnen.

Zum besseren Verständnis habe ich ein tolles Bild gemalt, in dem die verschiedenen Teile des Puzzles inklusive ihrer Verbindung gezeigt werden. Das gezeigte Schema ist eine Ableitung von HujiStats Bild "Schematic_Proxy_Server.png" und steht, wie das ursprüngliche Bild, unter der Creative Commons Lizenz by-sa.

Auf dem Bild sehen wir, dass wir zum einen den Client ("C") und den Server ("S") haben. Ziel ist es, dass sich der Client mit dem Server verbinden kann. Normalerweise ist dies kein Problem. Der Server ist normalerweise so positioniert, dass der Client ihn problemlos erreichen kann. Wie ich jedoch eingangs erzählt habe, gibt es durchaus Szenarien, in denen dies nicht der Fall ist. Es kann z.B. sein, dass der Server via UMTS mit dem Internet verbunden ist, es kann aber genauso gut sein, dass sich der Server in einem Netz befindet, das über eine restriktive Firewall von außen abgeschirmt ist. In diesen Fällen ist eine direkte Verbindungsaufnahme nicht möglich (soll durch die abprallenden Verbindungspfeile "(A)" und "(B)" symbolisiert werden).

Damit trotzdem eine Verbindung aufgebaut werden kann, muss nun der angesprochene Riven Proxy eingesetzt werden. Dieser besteht aus zwei Teilen - dem Male Proxy ("M") und dem Female Proxy ("F"). Der Male Proxy befindet sich in direkter Nähe des Servers und muss in der Lage sein, sich mit dem Server und mit dem restlichen Internet verbinden zu können. Der Female Proxy hingegen befindet sich außerhalb des restriktiven Netzwerkes und aggiert als eine Art Satellit. Es ist sehr wichtig, dass der Female Proxy (der Satellit) vom Client und vom Male Proxy erreicht werden kann.

Der Aufbau funktioniert nun wie folgt: Bei der Initialisierung des Proxies verbindet sich der Male Proxy mit dem Female Proxy. Da dies eine ausgehende Verbindung ist, wird sie von der Firewall nicht blockiert. Diese Verbindung ist die sogenannte "Control Connection" ("1"). Über diese wird dem Female Proxy z.B. mitgeteilt, welcher Port für ankommende Verbindungen geöffnet werden soll. Zudem wir dem Male Proxy über diese Verbindung mitgeteilt, wann sich ein Client mit dem Female Proxy (dem Satellit) verbunden hat.

Wenn der Client sich nun mit dem Female Proxy verbindet ("2"), erhält der Male Proxy ein Signal ("3"), das ihn veranlasst, eine Datenverbindung zum Female Proxy ("4a") und eine Datenverbindung zum Server ("4b") aufzubauen. Da auch dieses Mal die Verbindung aus dem Netzwerk nach außen gerichtet ist, wird auch dieses Mal die Verbindung gestattet. Damit ist die indirekte Verbindung zwischen dem Client und dem Server hergestellt. Wenn nun der Client Daten an den Female Proxy schickt, werden diese über die neue Verbindung an den Male Proxy und von diesem an den Server geleitet. Wenn der Server Daten an den Male Proxy schickt, werden diese an den Female Proxy von diesem an den Client weitergereicht.

Dies ist die Theorie, die ich mir vor gut 3 Jahren ausgedacht habe. Wie ich nun gestern erfahren habe, gibt es so etwas sogar schon in der praktischen Anwendung. Genauer gesagt bietet SSH die Möglichkeit, eine solche Verbindung aufzubauen. Dort heißt es jedoch "Reverse Tunneling", arbeitet aber genau nach dem gerade gezeigten Prinzip. Auf dem Satelliten läuft ein SSH-Server, der seinen Benutzern erlaubt, Tunnel aufzubauen (beim Schema des Riven Proxy wäre dies der Female Proxy). Auf dem Server, der erreichbar gemacht werden soll, läuft der SSH-Client (dieser SSH-Client entspricht dem Male Proxy). Er baut eine permanente Verbindung zum SSH-Server auf und teilt diesem darüber mit, welcher Port zum SSH-Client weitgereicht werden soll. Wenn nun eine Verbindung beim SSH-Server ankommt, werden die Daten an den SSH-Client weitergereicht, der diese dann ebenfalls weitergibt.

Ich persönlich bin nun ziemlich glücklich. Zum einen, da ich den Riven Proxy nicht selber implementieren muss und zum anderen, da ich dank der SSH-Implementierung des Reverse Tunnelung gesehen habe, dass mein Konzept praxistauglich gewesen ist. Natürlich ist es ein bisschen traurig, dass ich nicht der erste war, der diese Idee hatte, aber man kann ja schließlich nicht alles haben.

P.S.: Ich habe gerade ein echtes Schmankerl ausgegraben, das ich euch nicht vorenthalten möchte. Als ich 2007 die Überlegungen zum Riven Proxy angestellt habe, habe ich einen Text darüber verfasst. Der ist nie in größeren Umlauf gekommen, aber ich denke, dass er hier in den Artikel gut hinpasst. So findet auch er endlich seine letzten Ruheort.

Riven Proxy
(Wie man einen NAT-Server überlistet)

Mit dem Zuneige-Gehen des IPv4-Adressen-Bereiches wurden Mittel und Wege gefunden, den Verbrauch von Adressen im Internet zu verringern. Eine häufig eingesetzte Variante, der NAT-Server, bringt jedoch ein Problem mit sich, das es gilt, in den Griff zu kriegen.

Wer das Pech hat, zwangsweise hinter einem NAT-Server (Network-Address-Translation-Server) sitzen zu müssen, kennt das Problem: das Anbieten eines Servers ist so gut wie unmöglich. Wenn man keinerlei Zugriff auf die Konfiguration des NAT-Servers hat und demzufolge keinen Port-Forward einrichten kann, ist es so gut wie aussichtslos - oder doch nicht?
Es kursiert die Variante, die Kommunikation zwischen dem Server, der hinter einem NAT-Server ist und dem Client über UDP ablaufen zu lassen. Jedoch gibt es bei dieser Lösung ein Problem. Damit die eigentliche Kommunikation funktioniert, muss vom Server zu Beginn ein Garbage-Package an den Client geschickt werden, um den NAT-Server in dem Glauben zu lassen, dass der Server die Verbindung zum Client initiiert hat. Woher soll der Server jedoch die Adresse des Clients kennen? Diese Methode hat also den Schwachpunkt, dass die Adresse des Clients von vorneherein bekannt sein muss. Einen Server direkt anzubieten ist demzufolge nicht möglich. Vielleicht aber indirekt?
An dieser Stelle setzt der von mir konzipierte "Riven Proxy" an ("Riven Proxy" bedeutet soviel wie "zerrissener Proxy", was auf den Aufbau des Proxys zurückzuführen ist). Bei diesem handelt es sich um eine Kombination aus einem Proxy und einem Reverse-Proxy.
Während der eigentliche Proxy (aufgrund der Form auch als weiblicher Proxy - oder "Female Proxy" - bezeichnet) außerhalb des vom NAT-Server abgetrennten Netzwerkes ist, befindet sich der Reverse-Proxy (auch männlicher Proxy oder "Male Proxy") innerhalb des Netzwerkes. Intern arbeitet der Riven Proxy durch einen Pull-Mechanismus. Das bedeutet, dass dem Server die Daten nicht zugeschickt (/gepushed) werden, sondern dass sie (über den Male Proxy) abgefragt (/gepulled) werden.

Nun aber zur genauen Funktionsweise: Damit der Proxy funktionieren kann, muss der Male Proxy (hinter dem NAT-Server) eine Kontrollverbindung ("Control Connection") zum Female Proxy (vor dem NAT-Server) aufbauen. Durch diese wird zum einen festgelegt, auf welchem Port der Female Proxy auf ankommende Verbindungen warten soll und zum anderen wird über diese Verbindung dem Male Proxy mitgeteilt, dass ein Client eine Verbindung zum Female Proxy aufgebaut hat.
Ist dies der Fall, baut der Male Proxy eine weitere Verbindung (eine "Data Connection") zum Female Proxy auf. Diese wird dann im Female Proxy zur Client-Verbindung geroutet - gleichzeitig baut der Male Proxy eine Verbindung zum eigentlichen Server auf. Wurde die Verbindung hergestellt, fragt der Male Proxy in regelmäßigen Abständenüber über die Data Connection ab, ob Daten von der Client-Verbindung eingegangen sind. Ist dies der Fall, werden die Daten über die Data Connection an den Server weitergeleitet. Antworten werden über den selben Weg an die Client-Verbindung weitergereicht.
Nun werden auch die Bezeichnungen Male Proxy und Female Proxy verständlich - während der Male Proxy an beiden Seiten Client-Verbindungen (die Verbindungen zum Server auf der einen und die Control und Data Connections auf der anderen Seite) aufbaut, besteht der Female Client auf beiden Seiten aus Servern (auf der einen Seite für die Control und Data Connections und auf der anderen für die Client-Verbindungen).

Eine berechtigte Frage möge nun sein, ob es denn überhaupt vorkommen kann, dass man einen Server hinter einem nicht-konfigurierbaren NAT-Server anbietet. Die Antwort ist jedoch ein klares "ja" - es kann sehr wohl vorkommen. Bestes Beispiel könnte die Nutzung von HSDPA und HSUPA (-> UMTS) zur Internetanbindung sein. Dieses wird vereinzelt bereits als Fallback bei Ausfall der kabelgebundenen Internetleitung genutzt und einige stützen sich bereits einzig und allein auf UMTS für die Internetverbindung. Jedoch nutzen alle großen Mobil-Anbieter (zumindest in Deutschland) NAT-Server für die Anbindung der UMTS-Nutzer an das Internet. Sicherlich lässt sich eine solche Lösung auch für andere Formen von Firewalls nutzen, die für den Geschmack des Nutzers zu streng mit Verbindungsversuchen von außen umgehen.
Desweiteren mag man fragen, weshalb man nicht anstelle des Female Proxys direkt den Server ansetzt. Zum einen mag die Zugänglichkeit zum Server selbst eine Rolle spielen und zum anderen die bereits angesprochene Nutzung von UMTS als Fallback.
Ein letzter Punkt ist sicherlich, dass es aufwendig ist, einen weiteren Server einzurichten, über den der komplette Traffic geleitet werden muss - allerdings hat sich bereits bei normalen Proxys gezeigt, dass sich zumindest dort sogar öffentlich frei nutzbare Angebote etabliert haben, das Durchleiten also wirtschaftlich nur wenig bedenklich ist.

Leider existiert bisher keine Referenzimplementierung des Konzeptes - dies soll jedoch bald nachgeholt werden.