pf-regeln für mehrere http-proxys

soul_rebel

ist immer auf der flucht
also ich hab hier einen router der folgendes machen soll:

  1. alle http requests nach *.super.de/* umleiten durch proxy1.de port 1234
  2. alle anderen http, ftp und https requests umlenken durch proxy2.de port 2345
  3. für allen anderen traffic nat machen

die beiden proxys sind außerhalb meinesnetzes...
ich habe dazu folgendes gemacht:
Code:
rdr pass proto { tcp udp } from $internal_net to super.de port http -> proxy1.de port 1234

rdr pass proto { tcp udp } from $internal_net to any port { ftp http https } -> proxy2.de port 2345

nat on $ext_if from $internal_net to any -> ($ext_if)
es wird leider nur "genattet".
ich habe schon überlegt ob die sich vielleicht in die quere kommen, oder ob ich extra nat für diese verdinungen auschalten muss, aber irgendwie fehlt mir der plan und das pf-handbuch hat irgendwie auch nur fälle beschrieben, die ich nicht auf meinen übertragen konnte.
wie muss ich das anstellen? (und speziell wie sage ich der ersten regel, dass die zieladresse *.super.de/* und nicht nur super.de sein kann?)

vielen dank!
 
du bist auf dem falschen layer. was du machen willst, erfordert einen http-proxy und keinen paketfilter.
 
hm verstehe ich nicht ganz :confused: . das umleiten zu bestimmten proxys (also das transparent machen) ist doch eine übliche funktion von firewalls und für "lokales" umleiten habe ich auch viele beispiele gefunden.
außerdem kenn ich keinen proxy, der abhängig von zieladresse andere parent-proxys nutzt...
 
soviel mir bekannt ist, kann man auf diesen layer "nur"
etwas auf die naechste "station" weiter schicken, welche wiederum
an hand der header wieder weiter gibt.
 
hm verstehe ich nicht ganz :confused: . das umleiten zu bestimmten proxys (also das transparent machen) ist doch eine übliche funktion von firewalls und für "lokales" umleiten habe ich auch viele beispiele gefunden.
eben, die betonung liegt auf "lokal".

es ist doch auch offensichtlich, dass eine anforderung wie "leite alles zum ziel *.super.de um" nicht in einen paketfilter passt. ein paketfilter kann mit domains nichts anfangen, er arbeitet auf ip(v6)-ebene.

es mag sogar sein, dass man fuer einzelne zielhosts sowas mit pf hinkriegt. das geht dann aber wirklich nur fuer im vorfeld bekannte hosts und wird zusaetzlich ein gefrickel. der ziel-proxy muesste naemlich wissen, dass er ploetzlich nicht als proxy angesprochen wird, sondern direkt als der webserver, fuer den die umleitung gemacht wurde.

ein proxy ist die einzig richtige loesung fuer dieses szenario.

außerdem kenn ich keinen proxy, der abhängig von zieladresse andere parent-proxys nutzt...
privoxy kann das z.b.
 
hm, trotz der schlechten omen, es klappt alles :)

hatte die anfragen immer vom server direkt getestet. :ugly: für den gelten diese redirect regeln nicht.

die clients werden aber richtig geroutet.

TCM said:
und wird zusaetzlich ein gefrickel. der ziel-proxy muesste naemlich wissen, dass er ploetzlich nicht als proxy angesprochen wird, sondern direkt als der webserver, fuer den die umleitung gemacht wurde.
das geht wenn der proxy als transparenter proxy arbeitet, was sogar tinyproxy inzwischen kann :)

mit domainnamen kommt pf übrigens gut klar. nur wildcards in den domainnamen will er nicht. aber dafür kann ich ja eine tabelle oder ein liste anlegen.

danke auf jeden fall
 
mit domainnamen kommt pf übrigens gut klar. nur wildcards in den domainnamen will er nicht. aber dafür kann ich ja eine tabelle oder ein liste anlegen.
das hat nichts mit "mit domainnamen klarkommen" zu tun. ein paketfilter kennt nur ip-adressen.

pfctl loest nur hoeflicherweise einzelne hostnamen zur parse-zeit in adressen auf. wenn sich die adresse zur laufzeit aendert, behaelt es trotzdem die alte in den regeln. die fehlende moeglichkeit, hosts unterhalb der domain sauber zu erfassen, hast du ja selbst schon genannt.

zusammen mit der tatsache, dass die anderen proxies extra support fuer transparentes ansprechen brauchen, halte ich das ganze immer noch fuer eine frickelloesung. :)

Code:
rdr pass proto { tcp udp } from $internal_net to super.de port http -> proxy1.de port 1234

rdr pass proto { tcp udp } from $internal_net to any port { ftp http https } -> proxy2.de port 2345

nat on $ext_if from $internal_net to any -> ($ext_if)
einige dinge stoeren hier trotzdem noch:

1. http ist nur tcp, kein udp. selbes gilt fuer ftp und https.
2. dass die geschichte mit dem transparenten proxying auch fuer ftp funktioniert, kann ich nicht ganz glauben. hast du das auch probiert?
3. du solltest fuer rdr auch ein interface angeben, alles am besten so spezifisch wie moeglich. d.h. auch noch "inet" dazu, da die regeln so auch fuer ipv6 gelten wuerden.
 
TCM, was Deiner Meinung nach macht ein Proxy z.B. Squid wenn sich die IP-Adresse des Angefragten zur Laufzeit der Anfrage ändert?

In Summe: ein Paketfilter filtert, wie der Name schon sagt, Pakete. Die pf (oder heißt es der pf?) ist in der Lage an Hand des Zieles zu entscheiden, was mit dem Paket geschehen soll.

Es ist die ureigene Funktion einer Firewall Verkehr zu regeln, daß heißt auch umzuleiten. Der Gedankenansatz, den soul_rebel verfolgt hat, ist natürlich vollkommen richtig den Verkehr in die gewünschte Richtung zu lenken. Warum heißt es rdr und nicht localrdr?

Die Idee eines Proxies ist eine andere.

Mir graut einfach bei dem Gedanken den Mailverkehr, der am externen Beinchen meiner Firewall eingeht, nicht auf die Mailserver (seperate Zone) umleiten zu dürfen...
 
TCM, was Deiner Meinung nach macht ein Proxy z.B. Squid wenn sich die IP-Adresse des Angefragten zur Laufzeit der Anfrage ändert?
da er im besten fall eine regex auf den url matcht, macht er gar nichts mit adressen. man legt einfach fest, dass der host ^(.*\.)?super\.de$ bestimmten bedingungen unterliegt und das wars.

Der Gedankenansatz, den soul_rebel verfolgt hat, ist natürlich vollkommen richtig den Verkehr in die gewünschte Richtung zu lenken.
s.o. und die wildcards hat man damit immer noch nicht erschlagen. es ist und bleibt die frickelloesung.

Die Idee eines Proxies ist eine andere.
naemlich? da bin ich jetzt gespannt.
 
Der spass geht noch weiter.
Wie soll PF eine HTTPS Anfrage an banane.super.de feststellen?
Diese steht nun mal im HTTP-Header, der wiederum verschlüsselt ist.
Somit, PF kann bei HTTPS "nur" anhand von IPs umleiten und nicht anhand von Hostnames da PF, auch wenn er wollte, den Header von der HTTPS-Anfrage nicht nach "HOST: ..." durchsuchen kann.
 
Wie das Ziel gefunden wird steht doch gar nicht zur Diskussion. Sprich, ob der reguläre Ausdruck glücklich ist oder nicht. Wenn pf (richtig) entscheidet, ob Proxy A oder Proxy B zu benutzen ist, wo ist Dein Problem?

Ein Proxy baut stellvertretend eine (neue) Verbindung zum Angefragten auf und speichert Daten zwischen.
Anfragender --Verbindung A--> Proxy --Verbindung B--> Angefragter
 
Wie das Ziel gefunden wird steht doch gar nicht zur Diskussion. Sprich, ob der reguläre Ausdruck glücklich ist oder nicht. Wenn pf (richtig) entscheidet, ob Proxy A oder Proxy B zu benutzen ist, wo ist Dein Problem?
die anforderung lautete "alle http requests nach *.super.de/* umleiten".

das kann pf nicht zuverlaessig erfuellen, weil es 1) keine wildcards kennt 2) mit domainnamen zur laufzeit nicht anfangen kann. man wundert sich also irgendwann, warum es auf einmal zum falschen proxy weiterleitet, dabei hat sich nur die adresse geaendert. ist das so schwer zu verstehen, dass pf dafuer einfach das falsche tool ist?

Ein Proxy baut stellvertretend eine (neue) Verbindung zum Angefragten auf und speichert Daten zwischen.
Anfragender --Verbindung A--> Proxy --Verbindung B--> Angefragter
ein proxy ist auch als filter da, um acls umzusetzen.

ich weiss ja nicht, welche anforderungen das ganze szenario ueberhaupt hat. waere es z.b. schlimm, wenn die anfragen an *.super.de nicht ueber den richtigen proxy gehen? wenn z.b. sensible daten uebertragen werden und es sichergestellt sein muss, dass die anfragen ueber proxy1 gehen, dann ist pf erst recht das falsche tool.

dass https und ftp gar nicht gehen, hat soul_rebel ja sogar selbst gesagt. was bleibt also uebrig? ein protokoll von drei benoetigten funktioniert ueberhaupt nur, und das dann noch nicht einmal vernuenftig.

fuer manche leute mit hammer sieht halt alles wie ein nagel aus..
 
Richtig.

Eine gute Variante ist, den http verkehr auf einen local proxy weiter zu leiten.
der kann dann diese Aufgabe erledigen.

Gg
 
Code:
ext_if = "fxp0"
sub_a_super_de = "1.2.3.4"
sub_b_super_de = "1.2.3.5"
sub_c_super_de = "1.2.3.6"

super_de = "{" sub_a_super_de $sub_b_super_de $sub_c_super_de "}"

proxyA = "2.3.4.5"
proxyB = "2.3.4.6"
 
rdr on $ext_if proto tcp from $internal_net to $super_de port 80 -> $proxyA port 1234
rdr on $ext_if proto tcp from $internal_net to !$super_de port { 80 443 } -> $proxyB port 2345

Wenn man mit dem auskommt, was OpenBSD von Haus aus bietet, dann würde ich es benutzen, statt zusätzliche Software zu installieren. Die pf hat Lists, Macros und Anchors. Das heißt man kann sich die Liste der Subdomänen von super_de in eine Datei regelmäßig schreiben lassen und somit aktuell halten.

Im Falle FTP würde ich den mitgelieferten FTP-Proxy benutzen.

Ich bemerke jetzt erst (beim Tippen von mitgeliefert), daß es um pf auf FreeBSD geht...
Vieleicht hatte ich ja ein paar Ideen, die die pf auf FreeBSD (noch) nicht kann.

rdr from $FreeBSD -> $OpenBSD =)
 
Hallo!

also https und ftp gehen nicht, das stimmt, aber für den http verkehr ist das ne superlösung...
Super ist sicherlich was anderes. Es ist ein Notlösung: Wenn super.de auf einem Host mit vielen anderen Websites gehostet ist, wird für alle Domains die auf dieser IP gehostet sind, der gleiche Proxy verwendet (weil ja super.de beim laden der Regeln zu einer IP aufgelöst wird und alle Anfragen an diese IP an den ProxyA redirected werden).

Wenn das keinen Unterschied macht oder man sicherstellen kann, dass die Domain nie auf einem shared Host gehostet wird, ist das natürlich vernachlässigbar.

Ciao.
Markus Mann
];-)
 
Back
Top