Metainformationen zur Seite
  •  

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
sysbetr:proxyinfo [2019/06/30 14:40] – cbsysbetr:proxyinfo [2020/04/06 17:46] – [Test:] cb
Zeile 1: Zeile 1:
-====Proxy-Infoseite im Stil eine Captive Portals==== +=====Proxy-Infoseite im Stil eine Captive Portals===== 
-==Problem:== +====Problem:==== 
-In einem Netzwerk, von dem aus man nur mit einem Proxy in "das Internet"((gemeint ist natürlich das per HTTP und HTTPS erreichbare WWW)) kommt, finden sich immer wieder Rechner, die keinen Proxy konfiguriert haben und im Browser nur nichtssagende Fehlermeldungen über den nicht erreichbaren Server erhalten. +In einem Netzwerk, von dem aus man nur mit einem Proxy in "das Internet"((gemeint ist natürlich das per HTTP und HTTPS erreichbare WWW)) kommt, finden sich immer wieder Rechner (meist durch [[BYOD]]), die keinen Proxy konfiguriert haben und im Browser nur nichtssagende Fehlermeldungen über den nicht erreichbaren Server erhalten. 
-==Idee:== +====Idee:==== 
-Da die direkten HTTP-Requests sowieso nicht über die Firewall zum Zielserver gelangen, leitet man sie an einen Webserver auf der Firewall weiter, von dem genaue eine (temporäre) Redirect-Seite zurückgeliefert wird. Für HTTPS-Requests gibt es diese Lösung natürlich nicht. Jedoch starten viele Browser/Betriebssystem von sich aus einen HTTP-Zugriff auf entsprechende Seiten, damit diese Funktion für sogenannte Captive-Portals genutzt werden kann, also den Seiten, bei denen man sich z.B. in einem Hotel anmelden muss. +Rechner, die einen direkten HTTP-Request (nicht via Proxy) lossenden, sollen eine Infoseite zurück geliefert bekommen. \\ 
-==Realisierung:== +Die direkten HTTP-Requests werden an die Firewall gerichtet, das sie das IP-Gateway zum Internet ist. Anstatt den Request zum Zielserver zu schicken, leitet man ihn an einen Webserver auf der Firewall weiter. Dieser antwortet mit einer (temporären) HTML-Redirect-Seite - also einer gefälschten Antwort. Diese Seite gibt dem Browser das Kommando eine andere Seite zu laden - die Infoseite. Für HTTPS-Requests funtioniert so eine Lösung natürlich nicht - die Fälschung würde nicht akzeptiert werden. Jedoch starten viele Browser/Betriebssystem bei einem frisch konfigurierten WLAN von sich aus einen HTTP-Zugriff auf entsprechende Seiten, damit diese Funktion für sogenannte Captive-Portals genutzt werden kann, also den Seiten, bei denen man sich z.B. in einem Hotel anmelden muss. 
-Bedingung: Die Firewall ist das Gateway für die internen Netze. Damit erhält sie die bisher abgelehnten HTTP-Anfrage-Pakete. +====Realisierung:==== 
- +1. Infoseite 
-  * lege eine geeignete Infoseite an, hier auf http://intranet.example.de/proxyinfo.html. diese Seite muss aus den internen Netzen ohne Proxy erreichbar sein! HTTPS ist auch möglich. +  * lege eine geeignete Infoseite an, hier auf http://intranet.example.de/proxyinfo.html. Diese Seite muss aus den internen Netzen ohne Proxy erreichbar sein! HTTPS ist auch möglich. 
-  * installiere einen Webserver auf der Firewall, z.B. auf Port 8888 +2. Redirect-Seite 
-  * konfiguriere den virtual host in der Datei 000-default.conf:+  * installiere einen Webserver (hier apache) auf der Firewallmaschine, hier auf Port 8888 
 +  * konfiguriere den VirtualHost in der Datei 000-default.conf:
  
       <VirtualHost *:8888>       <VirtualHost *:8888>
Zeile 20: Zeile 21:
       </VirtualHost>       </VirtualHost>
  
-  * beachte, dass die 302 für eine temporäre Weiterleitung steht, damit der nächste Request durch den Browser wieder an das originale Ziel gerichtet wird. +    * beachte, dass die 302 für eine temporäre Weiterleitung steht, damit der nächste Request durch den Browser wieder an das originale Ziel gerichtet wird. 
-* konfiguriere +3. Firewallkonfiguration 
 +  * konfiguriere die Firewall für folgenden Redirect: 
 +      * in Worten: Leite alle TCP-Pakete aus den lokalen Netzen (leh,kwl,lwl), welch an einen Port 80 (www) außerhalb der lokalen Netze (nicht 10.0.0.0/8) gerichtet sind und die Firewall erreichen an den Port 8888 der Firewall weiter 
 +      * für Shorewall in der Datei rules - ggf. aber erst nach den Regeln, in denen Port-80-Zugriffe erlaubt werden: 
 + 
 +    #ACTION   SOURCE          DEST      PROTO DPORT   SPORT   ORIGDEST 
 +    REDIRECT  leh,kwl,lwl     8888      tcp   www     -       !10.0.0.0/8 
 + 
 +====Test:==== 
 +  * rufe mit [[curl]] die URL <ip-der-firewall>:8888 auf und beobachte den Redirect 
 +  * rufe die Infoseite ohne Proxy auf 
 +  * rufe mit curl eine Seite außerhalb((z.B. die IP des Internetrouters, der meist auf Port 80 reagiert)) der internen Netze auf und prüfe, ob der Redirect stattfindet. 
 +  * Alternative: mit telnet kann man auch ohne Browser oder curl die Verbindung testen. 
 + 
 +    telnet checkip.dyndns.org 80 
 + 
 +{{tag>Proxy}}