Manche Proxies kennen Möglichkeiten, um dieses Problem zu umgehen. SNIProxy lässt sich in einem transparenten Modus betreiben, in dem die Quell-Adresse der Verbindungen beibehalten wird.

SNIProxy im transparenten Modus

SNIProxy in den transparenten Modus zu versetzen ist auf den ersten Blick ganz einfach: Über die Konfigurationsdirektive source client im passenden Listener teilt man dem SNIProxy mit, er möchte doch bitte als Quell-Adresse für die Verbindungen gegen innen die ursprüngliche IP des Clients verwenden, z.B. so:

listen 192.168.1.15 80 {
   proto http
   source client
....

Als Beispiel verwenden wir 192.168.1.15 als IP für den Proxy. Es gibt dabei allerdings die eine oder andere Hürde zu umschiffen:

• Der transparente Modus funktioniert nur bei Listenern, die nur eine IP-Version verwenden. Es ist also notwendig, separate Listener für IPv4- und IPv6-Verbindungen einzurichten. In obigem Beispiel geben wir explizit die Adresse an, auf die der Listener hören soll, d.h. wir legen uns in diesem Beispiel auf IPv4 fest.
• Die Antwort-Pakete der Webserver, auf die SNIProxy weiterverbindet, müssen durch den Proxy-Rechner geroutet werden. Im einfachsten Fall wird dieser als Router aufgesetzt und die Webserver erhalten ihn als Default-Gateway.
• Auf dem Proxy-Rechner selbst muss per IPTables dafür gesorgt werden, dass die Pakete auch tatsächlich durch den transparenten Proxy laufen.
   

iptables und Policy Route auf dem Proxy-Rechner

Damit der Transparentmodus richtig funktioniert, müssen Pakete passend geleitet werden. Dies geschieht durch eine separate Routing-Tabelle, auf die Pakete per Markierung durch iptables geleitet werden:

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Auf dem Proxy-Rechner muss ausserdem Forwarding eingeschaltet sein, z.B. durch folgende Einträge in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Webtraffic auf den Webservern durch den Proxy umleiten

Im einfachsten Fall wird ganz einfach die Default-Route der Webserver auf den Proxy gelegt. Das ist nicht immer praktikabel. Eine Variante davon ist, lediglich die Antworten des Webservers über den Proxy umzuleiten. Auch dies gelingt mit einer Policy-Route und einer iptables-Markierung, etwa so:

iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 0x8
iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 0x8

ip rule add fwmark 8 lookup 101
ip route add 192.168.1.15 dev eth0 table 101
ip route add default via 192.168.1.15 table 101

Auch hier gegen wir als Beispiel wieder vom auf der Adresse 192.168.1.15 laufenden Proxy aus und leiten alle ausgehenden Pakete mit Quellport 80 oder 443 auf diesen um.

• mehrere Webserver stellen Websites/Webanwendungen/Webdienste zur Verfügung
• aus Sicht des Anwenders/Netztopologie sollen all diese zum einem einzigen Knoten zusammengefasst sein – z.B. aus Gründen der Sicherheit, der Flexibiliät (Umzug von Webdiensten ohne DNS-Änderungen), oder Adressknappheit
• nebst unverschlüsseltem HTTP soll unbedingt auch HTTPS unterstützt werden

Ansatz: Reverse Proxy

Die logische Antwort auf eine solche Herausforderung stellt ein Reverse Proxy dar, der aus Sicht von ausserhalb alle Web-Anfragen per HTTP und HTTPS entgegennimmt und diese an die internen Server weiterreicht. Typischerweise kommen hier Produkte wie Apache oder NGINX zum Einsatz.

Der klassische Ansatz hat auch Nachteile:

• alle Requests werden zweifach bearbeitet, einmal vom Proxy, einmal vom eigentlichen Webserver
• Inkompatibilitäten machen dem Admin das Leben schwer
• die Latenz steigt, die Performance leidet
• sehr flexible Lösung mit entsprechend aufwändiger Konfiguration
• SSL-Zertifikate und -Schlüssel müssen auf dem Reverse-Proxy vorliegen (das kann auch ein Vorteil sein)

leichtgewichtige Variante: Reverse Proxying mit SNIProxy

SNIProxy ist ein simpler Proxy mit sehr überschaubarem Funktionsumfang und entsprechend einfacher Konfiguration. Als "Border Proxy" zwischen Anwender/Anwendung und Webserver erlaubt er es, abhängig vom Servernamen ("Virtual Host") Requests 1:1 an den dazu passenden Webserver weiterzureichen – und zwar sowohl HTTP- als auch HTTPS-basierte. Anders als vollwertige Reverse Proxies verarbeitet er selber die Anfragen nicht, sondern reicht sie unverändert an den jeweiligen Webserver durch. Sämtliche typischen Kompatibilitätsprobleme entfallen und Probleme mit Performance oder Latenz entfallen.

Da der SNIProxy auch SSL-Verkehr nicht selber auswertet, sondern lediglich den per SNI übermittelten Servernamen auswertet und den Aufbau der SSL-Verbindung dem Zielserver überlässt, benötigt er keinerlei SSL-Konfiguration – diese wird wie gewohnt auf den eigentlichen Webservern durchgeführt.

Natürlich sind auf Grund der einfachen Funktion auch die Einsatzszenarien begrenzt. Z.B. erlaubt SNIProxy nicht:

• URLs umzuschreiben
• Requests vorzufiltern und etwaige gefährliche Requests bereits auf dem Proxy zu blockieren

Eine simple Konfiguration von SNIProxy könnte so aussehen:

user daemon

pidfile /var/run/sniproxy.pid

listen 80 {
   proto http
   table hosts
   access_log {
     filename /var/log/sniproxy/access.log
   }
}

listen 443 {
   proto tls
   table hosts
   access_log {
     filename /var/log/sniproxy/access.log
   }
}

table hosts {
   server1.example  192.168.1.13
   server2.example 192.168.1.14
}

D.h. SNIProxy hört auf die Ports 80 und 443 und leitet Anfragen abhängig vom vom Client angesprochenen Servernamen auf die internen Adressen 192.168.1.13 oder 192.168.1.14 um (auf denselben Port wie beim urspr. Request).

IP-Adresse loggen / transparenter Proxy

Ein Problem, das im Zusammenhang mit Reverse Proxies regelmässig auftritt, ist, dass es für den Webserver hinter dem Proxy so aussieht, als würde der Request vom Proxy selbst kommen. Entsprechend landet in den Log-Files des Webservers die IP-Adresse des Proxies, Mechanismen wie Sperren bei wiederholt falschen Login-Versuchen o.ä. betreffen alle Requests, und last-but-not-least sind Logauswertungen mit Tools wie Webalizer oder AWStats relativ nutzlos.

SNIProxy bietet als Ausweg aus diesem Dilemma die Möglichkeit an, Verbindungen so durchzuschleifen, dass aus Sicht des Webservers der Zugriff von der Original-IP des Clients aus erfolgt. In einem der nächsten Beiträge hier werden wir ein entsprechendes Setup beschreiben.