RootForum Community

Hi,

ich bin gerade dabei einen transparent proxy aufzusetzen. leider klappt das nicht so, wie ich mir das vorstelle.

der proxy läuft, d.h. wenn ich ihn am client angebe, dann wird er auch verwendet. das ist aber ja nicht sinn eines transparent proxies.

jetzt habe ich über iptables einen port forward von 80 auf 3128(squid default) eingerichtet. wie kann ich überprüfen, ob das port forward läuft? mit iptables -L sollte ich zwar die regeln sehen, da steht aber nix, ausser die leeren abschnitte?!?!?

vielen dank für die hilfe!

bis denn de bald
dr.zuse

Bei Squid sollte es so aussehen: vorausgesetzt Dein Proxy läuft auf diesem Port und der Rest des Netzes hängt an eth0.
Ich teste das folgendermassen: Ich habe einen Bereich fürs lokale Netz eingerichtet. Das sieht so aus: und den gebe ich frei mit Zum Test ersetze ich nur das allow durch deny.
Wenn dann eine Fehlermeldung des Proxy kommt auch wenn dieser nicht explizit angegeben wurde, dann ist es richtig.

Was ich noch nicht hinbekommen habe ist die Umleitung auf einen anderen Server.
Ich setze aber das scheint nicht zu klappen. Der Router sitzt auf der 192.168.0.250 und nen Proxy auf dem Router selbst will ich nicht :)
Ausserdem wäre die Kiste dafür zu klein.

Hat da jemand eine Idee ? Mit REDIRECT statt DNAT ging es auch nicht

@dr.zuse: Der Proxy muss auch wissen, dass er als transparent proxy arbeiten soll. Hast du ihm das beigebracht? Siehe http://www.squid-cache.org/Doc/FAQ/FAQ-17.html

@Matthias:

Prinzipiell sollte dein Befehl schon korrekt sein. Hast du bedacht, dass du in der FORWARD chain entsprechende Regeln benötigst, um die Paket weiterzuleiten? Ansonsten empfehle ich zum debuggen, eine catch-all Regel zum loggen zu verwenden, die direkt vor der REJECT Regel am Ende der Chains kommt. (Ich nehme doch mal an, dass deine Default-Policy DENY ist...) Dann könntest du die Logs studieren.

Habe noch nicht ganz dein Setup erfasst, falls die Clients im selben Netz wie die Destination sind und diese auch direkt erreichen könnten, gibt es Probleme, siehe hier: http://www.netfilter.org/documentation/ ... TO-10.html

Hi Dodolin,

Danke für Deine Antwort.
Leider bin ich iptables-Neuling und fummele mich mit ein paar alten Rechner zuhause durch :)
Folgendes Netz liegt vor:

192.168.0.250: Linux-Router mit DSL
192.168.0.249: Linux als DNS und Proxy
192.168.0.41: WinXP Pro als Client
DNS, Router, Prox etc. gehen auch.
Ich möchte aber einen tranpsarenten Proxy einsetzen, einfach nur weil ich die ganze Mimik kennenlernen möchte.

Squid ist als transparenter Proxy konfiguriert. Mein Problem scheint nun zu sein, dass die Anfragen ja zuerst an den Router kommen. Der schickt Sie dann mit dem obigen Eintrag an den Proxy Port 3128 statt Router Port 80. Nur sendet der Proxy dann ja wieder an den Router und ich habe eine wunderbare Schleife, oder ?

Ã?brigens: Der DNS verwaltet auch das lokale Netz

Meine letzte Idee war jetzt sowas wie: Würde das Sinn machen ? Ich schaue mir jetzt erstmal den Squid an, ob ich vielleicht dort die ausgehenden Pakete von Port 80 weglegen kann. Das müsste ja auch helfen.

Ich hoffe ich nerve nicht :)

Ã?hm.. also erstmal wollte ich noch anmerken, dass ich bisher noch kein DNAT ausser lokalem gemacht habe. Mein Wissen ist da also rein "theoretisch"... :)

Folgendes Netz liegt vor:

192.168.0.250: Linux-Router mit DSL
192.168.0.249: Linux als DNS und Proxy
192.168.0.41: WinXP Pro als Client

Welche Netzmaske? Ich nehme an, /24, also 255.255.255.0?
Gehe ich also richtig in der Annahme, dass alle Rechner im selben Subnet sind und sich auch alle gegenseitig direkt erreichen können?

Code: Select all

iptables -t nat -A PREROUTING -i eth0 -p tcp -s ! 192.168.0.249 --dport 80 -j REDIRECT --to 192.168.0.249:3128

Würde das Sinn machen ?

Nein, absolut nicht, denn das ist ja schon syntaktisch falsch. Oder nimmt dein iptables das etwa ohne Murren an?

Aus meiner man-page von iptables:

REDIRECT
This target is only valid in the nat table, in the PRE­
ROUTING and OUTPUT chains, and user-defined chains which
are only called from those chains. It alters the destina­
tion IP address to send the packet to the machine itself
(locally-generated packets are mapped to the 127.0.0.1
address). It takes one option:

--to-ports <port>[-<port>]
This specifies a destination port or range or ports
to use: without this, the destination port is never
altered. This is only valid with if the rule also
specifies -p tcp or -p udp).

Du kannst also nicht REDIRECT in Verbindung mit -to und einer IP:Port Kombination verwenden. Ausser, es hätte sich da etwas von meiner iptables Version zu deiner geändert...

Mein Problem scheint nun zu sein, dass die Anfragen ja zuerst an den Router kommen. Der schickt Sie dann mit dem obigen Eintrag an den Proxy Port 3128 statt Router Port 80. Nur sendet der Proxy dann ja wieder an den Router und ich habe eine wunderbare Schleife, oder ?

Der Anfang ist korrekt, ja. Der letze Satz ist jedoch falsch. Wenn meine Annahmen von oben zutreffend sind, dann schickt dein Proxy die Antwort eben direkt an den Client und umgeht die NAT Box. Damit wird das NAT nicht mehr "zurückübersetzt" und der Client erkennt die Antwort nicht als "gültig" an. Genau dieses Problem ist in dem Link beschrieben, den ich oben schon gepostet habe. Bitte da mal nachlesen. Wenn was unklar ist, dann nachfragen. Wenn es mit Englisch hapert (ich nehme halt immer das Englische zum nachlesen, wenn ich die Wahl habe...), dann nimm die deutsche Ã?bersetzung, die es davon gibt.

Dort ist auch eine Lösung beschrieben: Die Source IP vom Client auf der NAT Box in der POSTROUTING Chain zusätzlich ändern und auf die NAT Box umschreiben. Somit gehen die Antworten vom Proxy wieder zuerst an die NAT Box und diese kann sie korrekt "zurück umschreiben" und an den Client weiterleiten.

Eine andere (dort nicht genannte) Alternative wäre (unter der Annahme, dass sowohl die NAT Box als auch der Proxy unter Linux laufen), den beiden Kisten noch ein zusätzliches virtuelles Interface in einem anderen Subnet zu spendieren und den Proxy dann nur an diese IP zu binden. Somit können sich Proxy und Client nicht direkt erreichen und du hast die ganzen Probleme nicht und kannst ganz "normales" DNAT machen, mit dem zu allerst genannten Befehl machen. (Das sollte dann eigentlich funktionieren...)

ch hoffe ich nerve nicht

Nee, da musst du dir schon noch mehr leisten...
(Was jetzt nicht heisst, dass du das unbedingt tun sollst...) :)

PS: Ich verschiebe das Ding mal komplett nach Security. Proxies und iptables gehören IMHO mehr dahin.

Guten Morgen !

Stimmt, die Netzmaske ist /24, hatte ich vergessen anzugeben und die Rechner erreichen sich alle untereinander und zwar über die IP und auch über die Namen (eigener DNS mit Verwaltung des lokalen Netzes).
Daher bin ich auf die 1. Lösung aus Deinem Posting nicht eingegangen, denn diese Lösung existiert ja schon.

Code: Select all

iptables -t nat -A PREROUTING -i eth0 -p tcp -s ! 192.168.0.249 --dport 80 -j REDIRECT --to 192.168.0.249:3128 

Würde das Sinn machen ?

Nein, absolut nicht, denn das ist ja schon syntaktisch falsch. Oder nimmt dein iptables das etwa ohne Murren an?

Ja, iptables nimmt das wirklich an. Mein Fehler war, die Syntax von DNAT zu nehmen, denn dort ist das erlaubt und wird auch in

man iptables

beschrieben. Warum iptables nicht meckert weiss ich auch nicht.

Ich werde das jetzt mal mit SNAT testen und sehen ob es funzt.
Vielen Dank für Deine Hilfe. Wenn es nicht geht ist das nicht schlimm, denn ich brauche es nicht. Aber durch solche Sachen lerne ich viel besser die Vorgänge zu verstehen.

Aber eine Verstädnisfrage habe ich noch. Ich bin immer noch der Meinung, ich hätte eine Schleife.
Wenn Rechner 192.168.0.41 eine URL aufruft und kein Proxy eingetragen ist (weil es ja transparent gehen soll), dann läuft das Paket von 192.168.0.41 (Client) zu 192.168.0.250 (Router) Port 80. Es greift dort der Eintrag:. Dadurch wird die Adresse maskiert und die Anfrage geht an 192.168.0.249 (proxy) Port 3128. Dieser bearbeitet die Anfrage indem er versucht die aufgerufene URL zu kontaktieren. Dazu schaut er in sein Routing und will die Anfrage über 192.168.0.250 (router) direkt an die URL senden. Aber da er ja auch den Router nutzen muss, greift dort wieder die obige Regel und der Router sendet es wieder an den Proxy zurück, oder ?

Wo ist mein Denkfehler bzw. wenn das stimmt, wie kann ich die Schleife verlassen ?

Hat jemand eine Buchempfehlung zu iptables ? Ich habe bisher nur reine Firewall-Bücher gefunden und meine Frau will mir was schenken :)

Daher bin ich auf die 1. Lösung aus Deinem Posting nicht eingegangen, denn diese Lösung existiert ja schon.

Nee, nee, diese Lösung existiert bei dir eben noch nicht. Genau lesen: Die Source IP müsstest du ebenso umschreiben. Bisher schreibst du ja nur die Destination IP um. Hast du inzwischen mal den Link von mir gelesen?

Wo ist mein Denkfehler bzw. wenn das stimmt, wie kann ich die Schleife verlassen ?

Das hatte ich ganz übersehen. Ja, jetzt wo du es sagst, sehe ich auch die "Schleife". Vermeiden kannst du das ganz einfach, indem du noch nach der/den Source IPs matched oder sogar umgekehrt, alles ausser dem Proxy mit dieser Regel matched.

Beispiele: Das letzte fände ich am elegantesten.

Hat jemand eine Buchempfehlung zu iptables ?

Hm... ich habe mich bisher auf die Packet Filtering und NAT Howtos und die man-page beschränkt. Bisher konnte ich alle meine Frage dadurch beantworten.

meine Frau will mir was schenken

Hm... das ist dann allerdings ein Problem, ja.
Gibt es nicht auch andere Themen, zu denen sie dir was schenken könnte?
Also ich kenne keins, sorry.

Danke für Deine Antworten Dodolin !
Ich meinet die 1. Lösung aus dem Link den Du gepostet hattest. Natürlich habe ich den auch gelesen :). Da ging es darum einen internen DNS aufzusetzen. Das meinte ich mit dem bereits vorhandenen Ansatz.

Jetzt weiss ich dass ich es grundsätzlich nicht falsch verstanden habe und werde weiter fleissig lesen :)

Danke !
Matthias

Ich meinet die 1. Lösung aus dem Link den Du gepostet hattest.

Ah, dann hatte ich dich hier missverstanden. Klar, das hatte ich auch gar nicht erst erwähnt, weil du mit dem internen DNS alleine dein konkretes Problem ja auch nicht beheben könntest. (Das Szenario auf dieser Seite ist ja ein anderes...)

Ich dachte, du meintest damit die 1. Lösung, die ich vorgeschlagen habe (Source IP des Clients ändern), was aber im Link die 2. Lösung ist. Hm... kompliziert. :)