PF / rdr / transparenter Proxy auf Bridge

Errorsmith

Errorsmith

Kompiliertier
Hi

Ich habe mir zum testen eine Bridge gebaut:
Code: 
FreeBSD tr-scan 10.3-RELEASE FreeBSD 10.3-RELEASE #0:
Darin sind diese Netzwerkkarten verbaut:
Code: 
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
        ether 00:13:3b:12:12:5d
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
re1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
        ether 00:13:3b:12:11:11
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
Diese sind so konfiguriert:
Code: 
# bridge0 -> filtering bridge
cloned_interfaces="bridge0"
ifconfig_bridge0="inet 10.14.1.75 netmask 255.255.252.0 addm re0 addm re1 up"

# re0 -> intern
ifconfig_re0="up"

# re1 -> extern
ifconfig_re1="up"

Auf der Bridge möchte ich nun einen transparenten Squid laufen lassen.
Dazu habe ich PF in den Kernel gebaut und diese pf.conf erstellt:
Code: 
## vars
# interfaces
if_int="re0"
if_ext="re1"
if_bri="bridge0"

# hosts

# nets
net_localnet="10.14.0.0/16"

# ports / services

# tables

# options
set skip on lo
set loginterface $if_bri

# altq

# rdr
rdr pass on $if_int inet proto tcp from !127.0.0.1 to !10.14.0.0/16 port 80 -> 127.0.0.1 port 3129

# filter
pass log all

Wenn ich das nun testen möchte, tu ich das so:
Code: 
nc -l 3129
Leider kommt auf dem Port 3129 nichts an.
Ich habe die rdr-Regel auch schon mit $if_bri und $if_ext getestet.
Wo liegt hier mein Fehler? Ich bastel da schon seit 2 Tagen rum und bekomm es nicht hin. :(


Grüße,
errorsmith
 
Ich kann meinen Eintrag scheinbar nicht bearbeiten, daher antworte ich mir selber...
Ich bin ein Stück weiter mit dieser pf.conf

Code: 
if_int="re1"
if_ext="re0"
if_bri="bridge0"

host_trscan_local=127.0.0.1
host_trscan_bridge="10.14.1.75"

port_ssh="{22}"


set skip on lo
set loginterface $if_bri
set block-policy return


rdr pass on $if_int inet proto tcp from any to any port 80 -> 10.14.1.75 port 3129
no rdr on $if_int inet proto tcp from { 127.0.0.1 10.14.1.75 } to any port 80

pass log all
pass quick proto {tcp,udp} from any to any port $port_ssh
pass quick on $if_int
pass quick on $if_ext

Nun kommen die Anfragen auf dem Port 3129 an.
Allerdings bekomme ich im Squid-Log einen "Forwarding Error"
Eigentlich sollten die Anfragen vom Squid doch mit diesem Setup nicht umgeschrieben werden (no-rdr).
Scheinbar bekommt der Squid aber trotzdem seine Anfragen zurück. Woran könnte das liegen?

Grüße,
errorsmith
 
hi

du hast den sinn , funktion und zweck einer bridge und eines transparenten proxys verstanden ?

der der proxy weis nicht wohin er mit dem requst soll da das system ja , logisch betrachtet , nur 1 interface hat ,
und somit nur ein gw und jenachdem wohin das zeigt geht der fwd requext ins leere.

tip noch am rande ... teste erstmal ohne block ?



holger
 
Hi

Bitte nicht gleich hauen.
Ich schrieb doch Eingangs das ich mir das zum Testen gebaut habe, :-)
Das heisst ich teste, bastel und lerne damit. Den Sinn einer filtering Bridge habe ich (glaube ich) durchaus verstanden.
Einen transparenten Proxy auf einem Router habe ich im Einsatz, der funktioniert wie er soll.

Zu deinen anderen Anmerkungen:
Das oben ist im wesentlichen die vollständige pf.conf. Ich habe "pass all" regeln drin und blocke im Moment nichts.
Da ich später weiter mit pf experimentieren will habe ich zusätzlich die pass Regel für SSH drin. Diese ist im Moment redundant, das ist mir bewusst. Später werde ich sie aber brauchen.

Da ich scheinbar noch Lernbedarf habe (was ja auch der Sinn der ganzen Aktion ist), würde ich dich bitten ein wenig ausführlicher zu erklären. Aus meiner sicht (so wie ich mir das vorgestellt habe) läuft der Request so ab:

- Client macht Request auf einen Webserver

- PF nimmt die Verbindung auf $if_int und schreibt sie aufgrund der rdr-Regel um nach dst=10.14.1.75:3129

- Der Proxy bekommt auf dem Bridge-Interface (10.14.1.75) den Request.

- Der Proxy nutzt dann das Bridge-Interface (ist auch in der squid.conf so konfiguriert) um den Request durchzuführen

- da ich für $if_bri und localhost eine Ausnahme in der rdr-Regel habe, wird der Request nicht nochmal durch pf umgeschrieben. Er sollte ohnehin nicht von pf bearbeitet werden da sie vom Bridge-Interface kommt und von dort auf das Externe Interface geht bevor sie "den Rechner verlässt". Die rdr-Regel ist ja an $if_int gebunden.

- Proxy nimmt die Antwort vom Webserver entgegen. Diese wird durch PF nicht weiter bearbeitet, aber als zum Request zugehörig erkannt und dem Proxy zugeführt

- Der Proxy schickt die Antwort zum Client. Pf erkennt das es die Antwort auf die ursprüngliche Verbindung ist (stateful firewall), schreibt sie "zurück" und gibt sie an den Client weiter.

Meine Fragen dazu:
- An welcher Stelle ist hier mein Fehler?

- Warum funktioniert es überhaupt nicht wenn ich den Proxy auf 127.0.0.1 laufen lasse und die pf.conf entsprechend umschreibe, so das die Requests auf 127.0.0.1:3129 umgeleitet werden.

- Ist dieses Setup derart ungewöhnlich das es kaum (aktuelle) Infos im Netz gibt oder was mache ich falsch?
Ich finde im wesentlichen Beispiele die älter als 2 Jahre sind oder für OpenBSD's pf, was nicht funktioniert, da FreeBSD ein anderes / älteres pf mit drin hat.


Grüße,
errorsmith
 
Hallo,

dein Setup ist ungewöhnlich, denn es verlangt eine Menge Frickelei. Ich würde jetzt nicht grundsätzlich sagen dass es Unsinn ist, denn du wirst sicher deinen Lerneffekt bekommen. Ich empfehle dir, dich intensiv mit den Logs von Squid und PF auseinander zu setzen. Auch das erzeugte Statetable von PF (pfctl -s state) kann manchmal für einen gewissen AHA-Effekt sorgen und machmal findet man die Lösung erst, wenn man sieht was PF aus den Regeln kompiliert hat (pfctl -s rules).


Keep State!
morph
 
Hi

An welcher Stelle ist das Setup ungewöhnlich? Ich war davon ausgegangen das es mehr oder weniger normal ist einen transparenten Proxy als Bridge ins Netzwerk zu schalten, zum Beispiel zwischen dem LAN und dem Gateway-Router zum Internet. So war die ganze Aktion auch gedacht. Ist dies nicht (ohne weiteres) möglich?

Du schreibst ja von "einer Menge Frickelei" - Lern-Effekt hin oder her: Am Ende soll natürlich eine saubere Lösung stehen die ordentlich funktioniert. Wenn das nicht der richtige Weg ist, was wäre dann die richtige Lösung?

Mir fällt mir nur ein "Mini-Router" ein, der auf der "Außenseite" ein zusätzliches Transfernetz hat und als Standard-Gateway den Internetrouter. Das zusätzliche Routing und Netzwerk wollte ich ja genau vermeiden und daher das Teil "inline" im normalen Netz haben. Transparent eben. Wo liegt hier mein gedanklicher Fehler. Scheinbar gehe ich ja schon mit den falschen Voraussetzungen an das Thema heran...?

Grüße,
errorsmith
 
Der einfachste Weg geht über den "Minirouter" der über ein Transfernetz deine DSL-Box erreicht. Ob du den Proxy auf dem Router transparent machst, oder nicht, ist dann eigentlich egal. Gefrickel hast du in deinem Setup deshalb, weil ein Bridging-Packet-Filter eigentlich schon ein Thema für sich ist, dass nicht jeder beherrscht. Da kann man sicher viel lernen, in Verbindung mit Squid aber auch viel falsch verstehen. Ich bekomme schon einen Knoten im Kopf, wenn ich nur dran denke, deshalb würde ich es nicht einsetzen.
 
Hi

Danke nochmal für dein Feedback.
Mittlerweile bin ich insoweit weiter, als das ich (vermutlich) verstanden habe, wo das Problem liegt ;-)
Ich werde also für die fertige Lösung den Minirouter wählen.

Eine Frage habe ich allerdings noch, rein aus Neugier: Solche Dinger kann man fertig kaufen: Eine Appliance die als Bridge "inline" zwischen Router und Netzwerk geschaltet wird und halt filtert. Inklusive Proxy, AV Scanner etc. Die Teile laufen nicht zwingend als Minirouter. Wie lösen die Hersteller das Problem? Ist dann innendrin auch Gefrickel oder haben die einfach eine völlig andere Software die das Gewünschte "halt einfach kann"?

Grüße,
errorsmith
 
hi

das was du meint sind , Transparente Firewalls , habe ich hier in der Firma an ein zwei stellen laufen , sind Junipers .


Proxys an der stelle Funktionieren wie eine art "Man in the Middle" der Dienst bricht den Traffic auf , verarbeitet ihn und schickt ihn weiter.

das geht auch mit OpenBSD und diverer Proxy Software.

Jedoch ist der Aufwand , und Gehirnschmalz , den in solch eine Lösung setzen muss deutlich grösser als bei einem Klassischen Proxy System mit 2 Beinchen.
.Von den wir auch run 10 Stück von Bluecoat ( noch ) betreiben.

Holger
 
Hi

Ja, genau. Der ursprüngliche Gedanke war eine transparente Firewall. Mir war nur nicht klar, das das so ohne weiteres mit FreeBSD / pf nicht geht.
Von den klassischen Proxies hab ich auch einen, allerdings kann der (mangels Rechenleistung) nicht wirklich filtern. Das aktuelle Konstrukt sieht so aus, das der die Requests via ICAP an einen zweiten Proxy weitergibt auf dem dann Cache, Filterung und AV Scan laufen. Das gefällt mir allerdings nicht und ich dachte ich könnte das ganze mit einer Bridge und relativ wenig Aufwand lösen: Die beiden Proxies weg und einen Filterproxy auf der Bridge laufen lassen. Bei der Gelegenheit dann noch lernen wie das mit der Bridge und der transparenten Firewall funktioniert und fertig. Leider scheint das nicht so einfach zu sein wie gedacht...

Grüße,
errorsmith
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben