Autoproxy mittels WPAD

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Autoproxy mittels WPAD

Beitrag von pangu » 24.05.2012 00:17:20

Hey all,

ich hab etliche Seiten durchforstet und jedes Tutorial zeigt in etwa andere Optionen oder Möglichkeiten. Ich denke, dass es teils veraltete HowTo's sind und würde daher gerne wissen ob jemand ein aktuelle Tutorial für WPAD mit Debian Squeeze empfehlen kann.

Im Squeeze DHCP-server habe ich erstmal in der global Sektion eine neue Option definiert:

Code: Alles auswählen

option wpad-url code 252 = test;
Danach innerhalb meiner scope die Zeile

Code: Alles auswählen

option wpad-url "http://10.0.0.50/wpad.dat";
hinzugefügt, damit das an die DHCP-Clients übertragen wird.

Ich bin mir nun nicht sicher, ob ich für meinen Apache2 die Konfigurationszeile

in der /etc/apache2/httpd.conf

Code: Alles auswählen

AddType application/x-ns-proxy-autoconfig .dat
setzen muss, ...

-oder-

... in der /etc/apache2/mods-availabe/mime.conf

Code: Alles auswählen

AddType application/x-javascript-config pac
setzen sollte.

Was nun?

des Weiteren ist mir nicht klar, ob die Datei mit dem Skript "wpad.pac", "wpad.dat" oder "wpat.dat" oder in allen 3 Dateinamen im Root meines Webservers 10.0.0.50 vorhanden sein sollte. Da widersprechen sich einige Tutorials. Ich würde gerne wissen, ob ich im DNS zwingend irgendwelche Einträge setzen muss, oder braucht man das nicht tun, da der DHCP-Server problemlos die oben definierte Funktion an seine DHCP-Clients verteilt?

Und wenn doch ins DNS, wie genau müssen die records aussehen? Das eine Tutorial meint, einen A record setzen, ein anderes wiederum schreibt es genüge ein CNAME, und in einem anderen wird folgendes geschrieben:

Code: Alles auswählen

wpad    A     10.0.0.50
wpad.tcp   SRV 0 0 80   10.0.0.50
                TXT "service: wpad:http://10.0.0.50/wpad.dat"
das nimmt mein BIND9 aber nicht an, weil er meckert.

Und obendrauf meint der Wiki-Artikel (http://de.wikipedia.org/wiki/Proxy_Auto-Config) zu WPAD, dass im Skript die Funktion "IsInNet" Performance-Einbussen bringt. Ich bin total verwirrt...

Wer kann mir hier mit 'ner richtigen Konfiguration helfen?
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 24.05.2012 20:21:36

Hi,

zunächst empfehle ich dir, dich sehr grundlegend mit DNS, DHCP, SRV-Records, ... zu beschäftigen. Es sind da einige markante Verständnisprobleme zu erkennen. Lies nicht nur stumpf Tutorials, sondern beschäftige dich damit, was die einzelnen Dienste und Protokolle tun.
  • HTTP-Clients können sich ihre Proxy-Konfiguration selbstständig aus einem JavaScript erzeugen, das allgemein als WPAD bezeichnet wird.
  • Es gibt verschiedene Möglichkeiten, dieses Skript abzulegen.
    • Standardmäßig suchen die meisten Browser z.B. das Skript unter http://wpad.<primäres DNS-Suffix>/wpad.dat
    • Du kannst per DHCP die von dir genannte Option mitgeben. Deine Frage, ob die Datei in diesem Fall denn dann wpad.dat oder wpad.pac heißen mus, ist irrelevant, weil du da ja einen eindeutigen URI übergibst!
    • Du kannst auch mit einem SRV-Record in der Zone deines primären DNS-Suffix Host und Port des HTTP-Server überschreiben. Allerdings heißt der Name dafür wpad._tcp (bei dir fehlt der Unterstrich)
An der Apache-Konfig brauchst du im Wesentlichen nichts zu ändern - im einfachsten Fall setzt du, unter der Annahme, dass der Server, auf dem die wpad-Datei liegt, 192.168.1.1 als IPv4-Adresse hat, in deiner DNS-Zone

Code: Alles auswählen

wpad          IN       A     192.168.1.1
(oder sorgst, nachdem du dich grundlegend mit DNS beschäftigt hast, dafür, dass der Name anders aufgelöst wird, von mir aus per NSS (NIS, LDAP, PostgreSQL), mDNS oder sonst wie ;))

... und legst die wpad.dat in dessen DocumentRoot (standardmäßig /var/www).

-nik

P.S.: Das ist kein Gemecker, wirklich nicht. Du postest sehr viele Fragen, aus denen ich schließe, dass du in umfangreichen Installationen tätig bist. Es ist gut, dass du so viel fragst. Aber wenn die Anforderungen an dich wachsen, solltest du früher oder später in der Lage sein, dir neue Lösungen ohne genaue Anleitungen zu überlegen, indem du die grundlegenden Komponenten intuitiv beherrschst und korrekt zusammensetzen kannst. "Give a man a fish, and you feed him for a day. Teach a man how to fish, and you feed him for life. ;)

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 25.05.2012 01:35:59

Hallo Natureshadow,

danke nochmals für dein Feedback. Ich weiss deine Antworten wie auch die der anderen User sehr zu schätzen. Wie du richtig erkannt hast, lese ich mich in verschiedene Thematiken ein, versuche die Zusammenhänge zu erkennen und probiere sehr viel aus. Mein Ziel ist es immer zu verstehen, was genau wie funktioniert. Wenn ich dann am Ziel angelangt bin und auch das Verständnis entwickelt habe, hilft es mir unheimlich weiter. Oft stosse ich dabei auf Verständnisprobleme oder poste parallel meine Fragen, während ich recherchiere. Das mache ich nicht um das Forum zu spammen, sondern aus einem einfachen Grund: Ich möchte mir stets Anregungungen sammeln und vor allem Ideen. Dadurch dass mir andere User antworten und auf hoffentlich mir unbekannte Richtungen lenken, erweitere ich hoffentlich meinen Horizont. Ich will nicht stur nach einem Schema arbeiten, sondern mich freut es unheimlich zu erfahren, wie ihr -die Profis- in der Praxis damit umgeht. Selbst wenn ich mein Ziel bereits erreichen konnte, möchte ich mehr zum speziellen Thema lernen und auch wissen wie es der Rest der Welt so handhaben tut.

Ich kann dich beruhigen, dass viele meiner Fragen nicht in produktiven Szenarien Einsatz finden, sondern lokal in meinen Testdomänen. Ich habe zum Glück die Mittel und kann in Ruhe alles mögliche ausprobieren und das ist auch gut so. Ich danke dir wirklich recht herzlich für all deine Ratschläge und Tips. Ich bemühe mich, soweit es mir möglich ist, in die Thematik gründlich einzulesen, Indianerehrenwort :)

Back to topic:

Leider wurden meine offenen Fragen noch nicht beantwortet. Es geht mir jetzt wirklich um die WPAD und Autoproxy (.pac) Funktion. Ob und wie der SRV RR funzt soll nebensächlich sein, denn: ich weiss ja immer noch nicht einmal ob ich solch ein SRV überhaupt benötigen sollte? Vielleicht stammt das sogar aus älteren Zeiten, wo WPAD noch in den Kinderschuhen steckte, oder nicht viele Browser die Autoproxy-Config-Möglichkeit boten. Ich habe jetzt etliche Seiten zu dieser Thematik gelesen und es funktioniert auch bisher mit dem "FIREFOX".
HTTP-Clients können sich ihre Proxy-Konfiguration selbstständig aus einem JavaScript erzeugen, das allgemein als WPAD bezeichnet wird.
soviel ich weiss nennt sich das PAC-Datei. WPAD kommt hier noch gar nicht ins Spiel. Das Javascript wird in der PAC-Datei geschrieben.
Es gibt verschiedene Möglichkeiten, dieses Skript abzulegen. Standardmäßig suchen die meisten Browser z.B. das Skript unter http://wpad.äres DNS-Suffix>/wpad.dat
es soll wohl auch Browser geben, die nach wpad.pac oder wpat.dat suchen. Was nu?
Du kannst per DHCP die von dir genannte Option mitgeben.
Klar, bloss woher weiss welche Clients das überhaupt verarbeiten können? Ich hab mit code 252 verteilt, soweit ok. Aber können das wirkliche ALLE DHCP-Clients ? Woher finde ich genau Angaben hierzu?
Deine Frage, ob die Datei in diesem Fall denn dann wpad.dat oder wpad.pac heißen mus, ist irrelevant, weil du da ja einen eindeutigen URI übergibst!
Der DHCP-Server-Eintrag lautet doch "option wpad-url "http://192.168.111.222/wpad.dat"; also mit Angabe des Dateinamens. Oder hab ich jetzt was falsch verstanden (zumindest auf einigen Sites hatte ich das so gelesen) Ich habs mal getestet. Wenn ich im IE manuell das Proxy-Skript als URL angebe, dann teste ich folgende Eingaben (immer mit Browser-Restart anschließend). Ins Feld habe ich abwechselnd eingegeben "192.168.111.222", "http://192.168.111.222". Das funktioniert leider nicht, IE kann keine Scriptdaten so auslesen.

Auf meinem Web-Server gibts mein Proxy-Skript in drei Dateiausführungen, also "http://192.168.111.222/wpad.dat", "http://192.168.111.222/wpad.pac", und auch eine "http://192.168.111.222/wpat.dat". Gebe ich das so in den IE funktionieren alle 3 Varianten. Bedeutet also schonmal, dass der IE alle 3 verarbeiten kann und nicht auf eine bestimmte Dateiendung festgelegt ist.
Du kannst auch mit einem SRV-Record in der Zone deines primären DNS-Suffix Host und Port des HTTP-Server überschreiben. Allerdings heißt der Name dafür wpad._tcp (bei dir fehlt der Unterstrich)
siehe mein folgendes Statement/ bzw. Frage hierzu ...
An der Apache-Konfig brauchst du im Wesentlichen nichts zu ändern - im einfachsten Fall setzt du, unter der Annahme, dass der Server, auf dem die wpad-Datei liegt, 192.168.1.1 als IPv4-Adresse hat, in deiner DNS-Zone
es wäre sinnvoll noch ServerAliase richtig zu setzen, falls NameVirtualHost verwendet wird. So stellt man sicher, dass in jedem Falle (hostname only oder FQDN) der Webserver den Aufruf interpretiert und zur richtigen Site leitet. Mit einem korrekten DNS sollte das aber auch vernachlässigbar sein imho.


Warum ich das alles frage?

ich finde nirgends Daten, welche Browser welchen Mechanismus verarbeitet/verarbeiten kann. Ich hab funktionierendes DNS; der Client kann "wpad" und "wpad.meinedomain.de" auflösen und auf "http://wpad/wpad.dat" oder "http://wpad.meinedomain.de/wpad.dat" kann er auch zugreifen. Schalte ich im Firefox die Automatische Suche ein, dann funktioniert das. Soweit so gut, aber im Internet Explorer funktioniert's eben NICHT. Natürlich habe ich auch dort "automatisch suchen" gewählt und den Browser sicherheitshalber auch restartet. Das lässt mich doch darauf schliessen, dass der Microschrott irgendwie anders abfrägt oder abarbeitet. Auf jeden Fall greift mein wpad übers DNS nicht. Oder nicht? Könnte also sein, dass der IE den SRV RR im DNS benötigt, oder vllt. auch einen TXT record, oder weiss der Kukuck ...

Man könnte jetzt evtl. mit Sniffern arbeiten, aber damit habe ich leider noch keine Erfahrung. Bevor ich mich schwer tue, würde ich natürlich gerne in die Runde fragen, ob jemand mehr Infos dazu hat. Welcher Browser benötigt spezielle Mechanismen? Vielleicht
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 25.05.2012 02:25:00

So, es gibt Neuigkeiten. Und zwar hat mein Test-IE die Version "6.0.2900.xxxx". Und ich hab tatsächlich gesnifft. Der Windows-Agent und Mozilla funktionierten problemlos und konnte über WPAD mein Skript erhalten. Nur der IE wollte nicht. Warum? Weil er auf dem Webserver nach der Datei "wpad.da" sucht !!! Grrrr ... da fehtl das 't'.

Und dann hab ich nach diesem Text "wpad.da" gegoogelt und auch einen Eintrag im englischsprachigen Wikipedia gefunden, dass diese genannte IE-Version eben nach wpad.da sucht statt nach wpad.dat
Da macht einem der Microschrott wieder eindeutig einen Strich durch die Rechnung *röchel*. Manche schlugen sogar als Workaround vor, in der DHCP-Verteil-Option, einfach ein Leerzeichen nach dem wpad.dat einzufügen, da sie annahmen dass die MS-Clients ein Zeichen am Ende abschneiden. Das stimmt aber nicht, ich habs trotzdem aus Neugier ausprobiert. Natürlich half es nicht, da der IE definitiv und fix nach "wpad.da" sucht. Also hab ich meine 3 Dateien jetzt auf eine vierte Datei namens "wpat.da" erweitert. Natürlich müssen die Dateien auch entsprechende Leserechte für den Webserver haben, ist klar.

Als Nachtrag möchte ich noch hinzufügen, dass einige empfehlen statt einem CNAME unbedingt einen A record zu erstellen. Ich hab das auch ausprobiert. Es geht in meinem Falle auch mit CNAME. Bisher getestet nur IE und MOZILLA FIREFOX.

So, wieder was dazugelernt ... learn by doing, try & error *schwitz* vielleicht hilft's ja dem einen oder anderen bei seiner Problemsuche.

Bei Gelegenheit werde ich auch die anderen gängigen Browser (Konqueror, Iceweasel, Opera, GoogleChrome, usw...) testen. Aber für heute ist genug, meine Augen fallen zu.

Gute Nacht.

PS: Ich freue mich trotzdem auf rege Kritik oder Feedback, man lernt schließlich nie aus.

EDIT: Also, Opera in der aktuellen Version installiert. Da gibts gar keine Möglichkeit für "Automatische Suche der Proxy Einstellungen..." ich muss die URL angeben für mein Skript, damit es funktioniert. Also Opera hat keine Autoproxy-Möglichkeit, lasse mich aber gerne des Besseres belehren. Google Chrome funktionierte, Konqueror und Iceweasel auch. Jaja, die Neugier ... jetzt geh ich aber ins Bett
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 25.05.2012 09:50:09

So, hab jetzt weitere Tests durchgeführt und möchte feedback geben. Hinzufügen möchte ich, dass die WPAD Autokonfiguration lediglich mit meinem DNS-Alias "wpad" hervorragend funktioniert. Ich hab das sowohl mit internen Clients getestet, externen, als auch VPN-angebundenen Clients. Sobald ein Client meine DNS-Server nutzt in welchen ich den CNAME "wpad" definiert habe, dann kriegt er automatisch das Skript ordnungsgemäß übermittelt und kann den Proxy nutzen.

Das lässt mich also darauf schliessen, dass die code 252 function auf meinem DHCP-Server gar nicht erst zum Zuge kommt oder kommen muss. Denn bei meinen Tests handelt es sich nicht um DHCP-Clients, sondern um feste IP-Adressen. Zur Vergewisserung hatte ich auch bei diesen Tests den DHCP-Server ausgeschaltet, so dass der Dienst gar nicht aktiv war.

Bedeutet also, Mozilla Firefox in Ubuntu, Firefox aus Win7, IE in Win7, Konqueror aus CentOS, usw... priorisieren die DNS-Abfragen, statt irgendwelche code-252 Optionen auszulesen. Jetzt würde ich natürlich immer noch gerne wissen, welche Reihenfolgen exakt abgearbeitet werden. Gibt's denn nirgends Whitepapers dazu ? Ich konnte nichts finden :(
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 25.05.2012 10:19:09

pangu hat geschrieben:
Du kannst per DHCP die von dir genannte Option mitgeben.
Klar, bloss woher weiss welche Clients das überhaupt verarbeiten können? Ich hab mit code 252 verteilt, soweit ok. Aber können das wirkliche ALLE DHCP-Clients ? Woher finde ich genau Angaben hierzu?
Nein, können sie nicht. Das ist eine Vendor-Erweiterung.
pangu hat geschrieben:
Deine Frage, ob die Datei in diesem Fall denn dann wpad.dat oder wpad.pac heißen mus, ist irrelevant, weil du da ja einen eindeutigen URI übergibst!
Der DHCP-Server-Eintrag lautet doch "option wpad-url "http://192.168.111.222/wpad.dat"; also mit Angabe des Dateinamens. Oder hab ich jetzt was falsch verstanden (zumindest auf einigen Sites hatte ich das so gelesen)
Ja, richtig. Und wenn da wpad.dat steht, muss deine Datei wpad.dat heißen. Wenn da wpad.pac steht, muss sie wpad.pac heißen. Und wenn da mops.ruehrei steht, muss sie mops.ruehrei heißen.
pangu hat geschrieben: Ich habs mal getestet. Wenn ich im IE manuell das Proxy-Skript als URL angebe, dann teste ich folgende Eingaben (immer mit Browser-Restart anschließend). Ins Feld habe ich abwechselnd eingegeben "192.168.111.222", "http://192.168.111.222". Das funktioniert leider nicht, IE kann keine Scriptdaten so auslesen.
Äh, natürlich nicht. Wieso sollte dein Browser auch irgendeine wpad.dat aufrufen, wenn du ihn auf den Directory-Index ansetzt? Das ist doch Quark . . .
pangu hat geschrieben: Auf meinem Web-Server gibts mein Proxy-Skript in drei Dateiausführungen, also "http://192.168.111.222/wpad.dat", "http://192.168.111.222/wpad.pac", und auch eine "http://192.168.111.222/wpat.dat". Gebe ich das so in den IE funktionieren alle 3 Varianten. Bedeutet also schonmal, dass der IE alle 3 verarbeiten kann und nicht auf eine bestimmte Dateiendung festgelegt ist.
Was hat das überhaupt noch mit Proxy-Autokonfiguration zu tun, wenn du einfach im Browser Plaintext-Dateien von einem Webserver abrufst? Das sind sinnlose Tests, das ist vollkommen kontextfrei!
pangu hat geschrieben: es wäre sinnvoll noch ServerAliase richtig zu setzen, falls NameVirtualHost verwendet wird. So stellt man sicher, dass in jedem Falle (hostname only oder FQDN) der Webserver den Aufruf interpretiert und zur richtigen Site leitet. Mit einem korrekten DNS sollte das aber auch vernachlässigbar sein imho.
Nein, ist es nicht! Wenn dein Apache nicht auf alle Hostnamen hört, musst du den wpad-Host natürlich bekannt machen!
pangu hat geschrieben: ich finde nirgends Daten, welche Browser welchen Mechanismus verarbeitet/verarbeiten kann. Ich hab funktionierendes DNS; der Client kann "wpad" und "wpad.meinedomain.de" auflösen und auf "http://wpad/wpad.dat" oder "http://wpad.meinedomain.de/wpad.dat" kann er auch zugreifen. Schalte ich im Firefox die Automatische Suche ein, dann funktioniert das. Soweit so gut, aber im Internet Explorer funktioniert's eben NICHT. Natürlich habe ich auch dort "automatisch suchen" gewählt und den Browser sicherheitshalber auch restartet. Das lässt mich doch darauf schliessen, dass der Microschrott irgendwie anders abfrägt oder abarbeitet. Auf jeden Fall greift mein wpad übers DNS nicht. Oder nicht? Könnte also sein, dass der IE den SRV RR im DNS benötigt, oder vllt. auch einen TXT record, oder weiss der Kukuck ...
Dann schnapp dir einfach Debiantcpdump, Debianngrep oder Debianwireshark und guck dir an, was der IE macht ;). Was nicht dokumentiert ist, muss man eben reverse-engineeren. Das ist ja das spannende an unserem Job 8) !
pangu hat geschrieben: Man könnte jetzt evtl. mit Sniffern arbeiten, aber damit habe ich leider noch keine Erfahrung. Bevor ich mich schwer tue, würde ich natürlich gerne in die Runde fragen, ob jemand mehr Infos dazu hat. Welcher Browser benötigt spezielle Mechanismen?
Ich bin selber schon daran verzweifelt und Hunderte andere auch. Weil jeder sein eigenes Süppchen kocht. Microsoft will auf Biegen und Brechen eigentlich immer möglichst alles über ein AD oder zumindest per Gruppenrichtlinie haben. GNOME per dconf. Bla, alles Mist.

In den allermeisten Fällen kommst du in einem heterogenen Netz mit nur einer Lösung nicht weiter.

hec_tech
Beiträge: 774
Registriert: 28.06.2007 21:49:36
Wohnort: Wien
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von hec_tech » 25.05.2012 13:36:39

Hat es eigentlich irgendeinen Grund warum du alles mit wpad machen willst?
Wenn keine Gründe vorliegen würde ich einfach einen transparenten Proxy machen und es ist egal welcher Browser da verwendet wird.
Die Weiterleitung macht die Firewall/Router und fertig.

Hatte früher auch wpad im Einsatz bin aber davon abgekommen da für die meisten Einsatzzwecke der transparente Proxy einfach besser funktioniert.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 25.05.2012 13:43:52

Und bevor jetzt einer schreit "Aber SSL geht nicht mit transparentem Proxy": SSL wird auch nicht geproxied.

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 27.05.2012 16:22:19

Hallo nochmal,

@hec_tech:
über einen transparenten Proxy habe ich mir noch keine Gedanken gemacht, weil:

a.) ein bereits vorhandener squid Proxy bereits im Betrieb ist
b.) ich absolut noch keine Infos darüber habe.

Kannst du mir sagen, welche grundlegenden Vor-/Nachteile noch bestehen ? Ein Vorteil ist natürlich bereits genannt: die Enduser kriegen nix mit von irgendeinem Proxy, ergo muss auch am Endpunkt nix an Browsern konfiguriert werden oder ähnliches. Was gibts aber sonst noch für bemerkenswerte Vor-/Nachteile?
Edit: Wenn ich das aus Wikipedia richtig verstanden habe, dann bleibt der squid ja so wie er ist. Ich müsste also irgendwo alle Client-Anfragen abfangen und an meinen Internetrouter leiten. Momentan verwenden die Clients den Standardgateway 192.168.1.254 das ist ein Cisco Catalyst Switch. Der Internetrouter selbst hat die 192.168.1.5 und ist ein Linksys-OpenWRT Router. Wo müsste ich also die Ports 80, 21, etc.. abfangen und an die 192.168.1.5 weiterleiten? Am OpenWRT kommen sie ja gar nicht erst, also müsste ich es am Cisco Router bewerkstelligen ?


Wie sieht dann eigentlich die Infrastruktur beim Einsatz eines transparenten Proxy aus? Momentan siehts in dem einen Fall so aus: die Clients habe keine Route zum Internet-Router, sondern müssen zwangsweise den squid verwenden um im Internet surfen zu können.

@Natureshadow:Was hat es mit dem SSL auf sich? Kannst du mir das bitte etwas näher erläutern?

Danke euch beiden und einen schönen Sonntag wünsche ich.
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 27.05.2012 16:36:03

Hi pangu,

ich antworte mal für hec_tech mit, weil Vorraussetzung für deine Frage an mich :).
pangu hat geschrieben: Wie sieht dann eigentlich die Infrastruktur beim Einsatz eines transparenten Proxy aus? Momentan siehts in dem einen Fall so aus: die Clients habe keine Route zum Internet-Router, sondern müssen zwangsweise den squid verwenden um im Internet surfen zu können.
Der Squid ist schon gut. Du sagst ihm in der Konfiguration nur, dass er als transparenter Proxy arbeiten soll.

Dann gibst du deinen CLients allen ein Default-Gateway - das solltest du immer, über deine interne Firewall. Dafür, den Clients zu verbieten, nach außen zu kommunizieren, ist dann die Firewall zuständig!

Und auf dieser Firewall erstellst du dann eine Regel, die alle Pakete für Port 80 auf externen Hosts an deinen lokalen Squid umleitet (DNAT). Der kümmert sich dann darum.
pangu hat geschrieben: Was hat es mit dem SSL auf sich? Kannst du mir das bitte etwas näher erläutern?
Naja, um als transparenter Proxy arbeiten zu können, nimmt der Squid die HTTP-Requests auseinander. Im normalen Modus bekommt er eine Anfrage, die so aussieht:

Code: Alles auswählen

GET http://www.example.com/foo.html HTTP/1.1
Host: www.example.com
[...]
Die hat der Browser schon so vorbereitet, dass der Proxy weiß, zu welchem Host er sich verbinden muss. Bei Plaintext-HTTP im transparenten Modus sieht das ähnlich aus:

Code: Alles auswählen

GET /foo.html HTTP/1.1
Host: www.example.com
[...]
Hier analysiert der Squid dann den Host-Header, anstatt den absoluten URL.

Im normalen Modus funktioniert das für HTTPS etwas anders. Der Browser bereitet die verbindung vor, indem er nicht einen GET-Request, sondern ein CONNECT an den Proxy sendet:

Code: Alles auswählen

CONNECT www.example.com:443
Daraufhin baut der Proxy die verbindung auf und leitet Pakete dann einfach weiter. In die Kommunikation selber kann er wegen SSL nicht mehr hineinsehen.

Manche Browser machen auch ein

Code: Alles auswählen

GET https://www.example.com/foo.html HTTP/1.1
und der Proxy terminiert dann die SSL-Verbindung. Das finde ich aber äußerst unsauber, weil der verschlüsselte traffic den Proxy-Betreiber nichts angeht.

Wenn du transparent arbeitest, kann der Browser den Request nicht vorbereiten, sondern initiert die Verschlüsselung direkt mit dem Server. Dein Proxy kann in den verschlüsselten Traffix aber nicht hineinsehen, weshalb er nicht weiß, wohin er die Verbindung weiterleiten soll.

Es gibt dafür zwei Lösungen:
  • den Squid selber SSL machen zu lassen und in beide Richtungen terminieren zu lassen. Ein absolutes No-Go, weil dich Benutzerdaten in SSL nichts angehen und das auch unsauber ist (du musst die Daten dann mti einem neuen Zertifikat versehen, User können die ursprünglichen Zertifikate nicht mehr prüfen, also SSL faktisch kaputt)
  • HTTPS geht durch die Firewall durch, ohne Proxy
Die zweite Option ist völlig in Ordnung. Weil da du dir verschlüsselten Traffic ja nicht ansiehst, kannst du ihn nicht filtern. Und gecachet wird verschlüsselter Traffic auch nicht.

-nik

P.S.: Hier mal die relevanten Config-Teile aus meinem bekannten Netzwerk (Erklärungen jeweils in den Kommentaren in den Dateien oder in den Dokus der Dienste):

/etc/squid/squid.conf

Code: Alles auswählen

acl students src 172.30.0.0/16
acl mensa src 192.168.2.0/24
acl road src 10.18.0.0/16
acl limit maxconn 5
acl mensa_domains url_regex -i "/etc/squid/mensa_domains.lst"
acl unlimited_domains url_regex -i "/etc/squid/unlimited_domains.lst"
acl unlimited_clients src "/etc/squid/unlimited_clients.lst"
acl blocked_domains url_regex -i "/etc/squid/blocked_domains.lst"
acl free src "/etc/squid/free.lst"
acl blocked src "/etc/squid/blocked.lst"

http_access allow unlimited_domains
http_access deny blocked
http_access deny blocked_domains
http_access allow students
http_access allow mensa mensa_domains
http_access allow road
[...]
http_access deny all

http_port 3128 transparent

delay_pools 3
delay_class 1 2
delay_class 2 2
delay_class 3 2
delay_access 1 allow unlimited_clients
delay_access 1 allow unlimited_domains
delay_access 1 deny all
delay_access 2 allow students
delay_access 2 allow road
delay_access 2 deny all
delay_access 3 allow mensa
delay_access 3 deny all
/etc/shorewall/rules

Code: Alles auswählen

# Transparent proxy
ACCEPT		mensa		fw			tcp	3128
HTTP/REDIRECT	mensa		3128
ACCEPT		road		fw			tcp	3128
HTTP/REDIRECT	road		3128
ACCEPT		students	fw			tcp	3128
HTTP/REDIRECT	students	3128
-nik

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 27.05.2012 17:04:41

Mensch, danke die für diese Einblicke. Jetzt würde mich natürlich noch zu deiner Aussagen hier ...
Manche Browser machen auch ein

GET https://www.example.com/foo.html HTTP/1.1

und der Proxy terminiert dann die SSL-Verbindung. Das finde ich aber äußerst unsauber, weil der verschlüsselte traffic den Proxy-Betreiber nichts angeht.
interessieren: welche Browser machen eigentlich solche 'unsaubere' Verbindungen mit SSL?

Also sollte ich meinen Clients als Default-Gateway meine Firewall angeben (IPFire). Diese hat die 3 NICs. eth0 hat die 192.168.1.6 (office-LAN), eth1 hat die 10.0.0.1 (DMZ) und eth2 die WAN-IP mit eth2:1 eth2:2 usw... die einzelnen fixen IPs meines ISPs. Ich müsste also als Default-Gateway die 192.168.1.6 angeben. Meine Clients kontaktieren also meine IPFire FW und dort konfiguriere ich dann, dass alle Anfragen "Source: Grünes internes LAN" nach "Ziel: rotes Netz WAN/Internet:Port80" einen redirect zu der IP 192.168.1.2 (squid) erhalten. Stimmt das so?

Kann ich dann gleich auch Port 21 in diesen redirect mit einbeziehen? wie schaut's eigentlich aus, wenn ein Client z.B. eine SSH-Verbindung zu seinem privaten Home-PC aufbauen möchte. Angenommen er möchte den default-Port 22 nutzen, oder von mir aus auch mal auf den Port 2222 über SSH? Oder ein Client möchte eine https://irgendeine.url.addresse:4567 aufrufen? Wie handhabe ich so etwas? Soll man so etwas grundsätzlich an der FW blockieren, so dass NUR default-Ports erlaubt werden? Dann würde natürlich der Zugriff auf ssh://1.2.3.4:4567 nicht funktionieren, genauso auch der SSL-Connect auf Port 4567 nicht. Wie sollte man so etwas also richtigerweise bewerkstelligen?


Und eins noch: wieso sollte ich diese transparente Proxy-Methode bevorzugen, gegenüber meiner jetzigen? Was ist daran auszusetzen, dass die Clients meinen Internet-Router 192.168.1.5 nicht direkt nutzen dürfen (iptables so konfiguriert, dass wirklich nur der squid Proxy 192.168.1.2 erlaubt wurde ins Internet zu gehen) sondern direkt den squid ansprechen?
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 27.05.2012 17:17:12

pangu hat geschrieben:welche Browser machen eigentlich solche 'unsaubere' Verbindungen mit SSL?
Nun, hauptsächlich ist das Konfigurationssache. Wenn du halt nur einen HTTP-Proxy und keinen HTTPS-Proxy konfigurierst, macht er bis zum Proxy Plaintext-HTTP. Ist ja eigentlich auch korrekt so.
pangu hat geschrieben: Also sollte ich meinen Clients als Default-Gateway meine Firewall angeben (IPFire). Diese hat die 3 NICs. eth0 hat die 192.168.1.6 (office-LAN), eth1 hat die 10.0.0.1 (DMZ) und eth2 die WAN-IP mit eth2:1 eth2:2 usw... die einzelnen fixen IPs meines ISPs. Ich müsste also als Default-Gateway die 192.168.1.6 angeben. Meine Clients kontaktieren also meine IPFire FW und dort konfiguriere ich dann, dass alle Anfragen "Source: Grünes internes LAN" nach "Ziel: rotes Netz WAN/Internet:Port80" einen redirect zu der IP 192.168.1.2 (squid) erhalten. Stimmt das so?
Ja.
pangu hat geschrieben: Kann ich dann gleich auch Port 21 in diesen redirect mit einbeziehen?
Nein, ich glaube, das macht der Squid nicht transparent. Muss er ja auch nicht. Du hast mit deinem Proxy ja nur zwei Absichten:
  • Filtern
  • Cachen
Beides ist für FTP nicht notwendig. Bei HTTP hast du die Herausforderung (beim Filtern), dass auf einem Ziel-Host (auf IP-Ebene) mehere namensbasierte Virtual Hosts sein könnten. Deshalb brauchst du da den Proxy zum Filtern und kannst das nicht per Firewall machen (und der Proxy kann auch den Content filtern, wobei ich das selbst bei uns in der Schule nicht mache, da ich mich technischen Lösungen für pädagogische Probleme verweigere).
pangu hat geschrieben: wie schaut's eigentlich aus, wenn ein Client z.B. eine SSH-Verbindung zu seinem privaten Home-PC aufbauen möchte. Angenommen er möchte den default-Port 22 nutzen, oder von mir aus auch mal auf den Port 2222 über SSH? Oder ein Client möchte eine https://irgendeine.url.addresse:4567 aufrufen? Wie handhabe ich so etwas? Soll man so etwas grundsätzlich an der FW blockieren, so dass NUR default-Ports erlaubt werden? Dann würde natürlich der Zugriff auf ssh://1.2.3.4:4567 nicht funktionieren, genauso auch der SSL-Connect auf Port 4567 nicht.
Sowas ist reine Firewall-Sache. Wie gesagt, da gibt es nichts inhaltlich zu filtern und nichts zu cachen. Du kannst auch mit den Safe_ports im Squid geproxxte verbindungen auf diesen Ports zulassen, aber das macht m.E. keinen Sinn.
pangu hat geschrieben: Wie sollte man so etwas also richtigerweise bewerkstelligen?
Das ist eine philosophische Frage. Ich bin grundsätzlich dieser Ansichten hier:
  • Keine technischen Lösungen für soziale Probleme. Wenn Mitarbeiter während der Arbeit Unfug machen (oder Schüler in der Schule), und ich sie nicht durch Vereinbarungen davon abbringen kann, ist mein Problem ein anderes als die Firewall.
  • Verschlüsselter Traffic wird nicht angefasst.
  • Unverschlüsselter Traffic wird höchstens gecachet und technisch sinnvoll gefiltert. (z.B. auf Malware)
Ich lasse bei mir im bekannten Netz diesen Traffic zu (Shorewall-Rules): NoPaste-Eintrag36473

Benutzeravatar
pangu
Beiträge: 1348
Registriert: 15.11.2011 20:50:52
Lizenz eigener Beiträge: GNU General Public License
Wohnort: /proc/1

Re: Autoproxy mittels WPAD

Beitrag von pangu » 29.05.2012 11:08:02

Hallo nochmal,

ich hätte zum Thema WPAD noch eine Frage. In meinem DNS habe ich einen A record eingerichtet á-la:

Code: Alles auswählen

wpad   A <IP-Webserver1>
Ich habe aber noch einen zweiten Server, der sowieso also Backup dient. Auf diesem habe ich ebenfalls Apache2 installiert, und der bietet ebenfalls unter gleichem Pfad dieses WPAD script. Wenn Server1 nun ausfällt, wäre es ja gut, wenn die Clients trotzdem ihr Script weiterhin über Server2 beziehen könnten. Ich würde gerne den Webserver2 als Backup nutzen wollen, auch fürs WPAD. Wenn ich nun im DNS den Eintrag auf diesen hier abändere:

Code: Alles auswählen

wpad   A <IP-Webserver1>
          A <IP-Webserver2>
und anschliessend den Webserver1 beende, dann würde ein Browser-Client folgendes Verhalten aufzeigen. Er löst "wpad" auf und kriegt die IP des Webservers1 übermittelt, weil das DNS ja nicht weiß oder prüfen kann, dass der Webserver1 eigentlich down ist. Der Client wird also gar nicht erst den Webserver2 kontaktieren und somit schlägt WPAD fehl.

Wie könnte ich das geschickt lösen ? Geht das dann irgendwie mit DNS-Roundrobin ? Ich vermute kaum, weil ja der Dienst DNS keine Möglichkeit hat, einen Server auf Erreichbarkeit hin zu prüfen.
Man gibt Geld aus, das man nicht hat, um damit Dinge zu kaufen, die man nicht braucht, um damit Leute zu beeindrucken, die man nicht mag.

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: Autoproxy mittels WPAD

Beitrag von Natureshadow » 29.05.2012 13:54:34

Hi,

der DNS-Resolver erhält alle RRs vom angefragten Typ A. Mit welchen davon er Verbindungen versucht, ist clientabhängig.

Alleine mit DNS kannst du kein Fallback realisieren. Deine Monitoring-Lösung (Icinga o.Ä.) könnte sicherlich ein Update der Zone triggern.

-nik

Benutzeravatar
ThorstenS
Beiträge: 2708
Registriert: 24.04.2004 15:33:31

Re: Autoproxy mittels WPAD

Beitrag von ThorstenS » 29.05.2012 18:19:34

nochmal zu den oben genannten Dateien wpa{t,d}.pac oder .dat
Ich habe bei meinem Setup eine Datei, die anderen sind hardlinks darauf. So funktionierts mit den meisten Systemen problemlos.

Einen transparenten proxy kann man IMHO nur aufsetzen, wenn keine Proxyanmeldung gefordert ist. Ich lasse mich aber gerne eines Besseren belehren.

Antworten