Herausforderung
- 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.