[fli4l] PF_INPUT -?==?utf-8?Q? ein paar Verständnisfrag?==?utf-8?Q?en

[K. Dreier]

Hallo!

hab das hier zusammengeschrieben, bevor Martin gepostet hat. Mache nun
Anpassungen, verarbeite also - in Teilen - Input der Posts von Peter und
Martin.

Peter Schiefer schrieb am Fr, 30 Januar 2015 19:51
> >  PF_INPUT_N='3'
> >  PF_INPUT_1='IP_NET_1 ACCEPT'
> 
> lass alles Clients aus dem Netz IP_NET_1 auf Dienste des fli4l
> zugreifen

Genau. Gut so. In meinem Setup will ich eben gerade _nicht_ daß via
einem zusätzlichen IP_NET_3 ACCEPT alle Rechner auf _alle_ Dienste des
fli4l zugreifen können. Deswegen hier nur NET_1.

Zitat:
> >  PF_INPUT_2='tmpl:samba DROP NOLOG'
> 
> Verwerfe alle Samba-Anfragen an den fli4l und logge nichts davon

Auch das verstehe ich so, daß es das ist, was ich (und wahrscheinlich
die weitere Menschheit) will, nämlich daß diese Samba-Pakete das
LAN/die LANs nicht ins WAN verlassen. Richtig?

Zitat:
> >  
> >  PF_FORWARD_N='3'
> >  PF_FORWARD_1='tmpl:samba DROP'
> 
> route keinerlei Samba-Pakete zwischen belibiebigen Netzen

Ups. There's your problem!  :d  Logisch kann ich damit nicht zwischen
meinen 2 Netzen auf deren Win-Shares zugreifen.

Zitat:
> >PF_FORWARD_2='IP_NET_1 ACCEPT'
> 
> lasse das routing von Paketen des Quellnetzes IP_NET_1 zu jedem
> beliebigen Ziel

Ebenfalls das, was ich will. NET_1 darf alles.

Zitat:
> >PF_FORWARD_3='IP_NET_1 IP_NET_3 ACCEPT'
> 
> lasse das routing von Pakete des Quellnetzes IP_NET_1 zum Zielnetz
> IP_NET_3
> zu (Ist durch Regel 2 bereit zugelassen, so das diese Regel nie
> greift.

Macht Sinn. Ok, weg damit.

Zitat:
> >plus immer PF_POSTROUTING_2='IP_NET_3 MASQUERADE'
> 
> POSTROTING MASQURADE = ersetzt die Source-Adresse des gerouteten
> Paketes
> mit der Adresse des fli4l

Auch das sollte ja Standard sein: für jedes weitere Netz, das ins WAN
darf, muß man halt ein Masquerade machen.

Zitat:
> INPUT regelt zugriffe auf Dienste die auf dem fli4l laufen, das hat
> also
> nicht mit Zugriffen von LAN zum Internet zu tun!
> [...]
> alles was von LAN zum Internet gehen soll muss di in einer
> FORWARD-Regel
> erlauben

Ok, das war mein Denkfehler bzw. ich habe es etwas vermischt. Meine
PF_FORWARD_Regeln hatten das ja eigentlich doch als Grundlage. Die
Tatsache, daß NET_1 ins WAN kommt, liegt also _nicht_ an
PF_INPUT_x='IP_NET_1 ACCEPT', sondern an PF_FORWARD_x='IP_NET_1
ACCEPT'.

Zitat:
> die Reihenfolge der Regeln ist entscheidend - wenn du in regel
> 1 Samba-Verkehr verbietest und dann in Regel 2 routing zwischen
> deinen
> lokalen Netzen erlaubst dann sind die Paket für Samba aka
> Windows-Shares
> schon von Regel 1 blockiert worden.

Das hab ich jetzt verstanden.  :)  

Nach dem weiteren Input von Martin (und diversen Test-Varianten vorher,
die nur teilweise erfolgreich waren) sieht es nun fast so aus, wie von
Martin vorgeschlagen - denn seine Variante verunmöglichte erneut
WAN-Zugang von NET_3 .
Es funktioniert jetzt in dieser Form:

PF_INPUT_N='6'
PF_INPUT_1='IP_NET_1 ACCEPT'
PF_INPUT_2='if:IP_NET_2_DEV:any prot:tcp 22 ACCEPT'
PF_INPUT_3='tmpl:samba DROP NOLOG'
PF_INPUT_4='tmpl:dns IP_NET_3 ACCEPT'
PF_INPUT_5='tmpl:ntp IP_NET_3 ACCEPT' *
PF_INPUT_6='tmpl:ping IP_NET_3 ACCEPT' *

(* wahrscheinlich nicht nötig, aber fli4l soll auch ein NTP-Server sein
können; ping wegen Testen)

PF_FORWARD_N='5'
PF_FORWARD_1='IP_NET_1 ACCEPT'
PF_FORWARD_2='[IP von NET_3-client1] IP_NET_1 ACCEPT'
PF_FORWARD_3='tmpl:samba DROP NOLOG'
PF_FORWARD_4='IP_NET_3 IP_NET_1 REJECT'
PF_FORWARD_5='IP_NET_3 ACCEPT'

PF_POSTROUTING_N='3'
PF_POSTROUTING_1='IP_NET_1 IP_NET_3 ACCEPT BIDIRECTIONAL'	# ist das
wirklich nötig?
PF_POSTROUTING_2='IP_NET_1 MASQUERADE'
PF_POSTROUTING_3='IP_NET_3 MASQUERADE'

Ich kann nicht beurteilen, ob nun z.B. eine Xbox als NET_3-client2
Zugriff aufs NET_1 hat - wüsste nicht, wie ich das testen soll. Aber
mit (meiner) Forward-Regel4 dürfte das ja nicht sein. WAN-Zugang hat
sie jedenfalls, wie auch die anderen NET_3-clients1-x jetzt.

Nachdem ich dann noch ein kleines Win-Firewall-Problemchen erkannt und
beseitigt habe  :twisted: kann ich nun auf alles so zugreifen, wie ich
möchte, inkl. der Win-Shares. Mit einer Ausnahme: mein NAS lässt den
NET_3-client1 nicht drauf, obwohl ich auf dem NAS sogar den Zugriff aus
gesamten NET_3 (zum Testen) geöffnet habe. Da ich aber auf
NET_1-client1 zugreifen kann, liegt das Problem also wohl am NAS.

Interessant wäre es jetzt zu analysieren, wieso der Vorschlag von
Martin nicht funktioniert hat, sondern es erst ging nachdem ich noch dns
in der Input-chain geöffnet habe. Mit meinem limitierten Verständnis
leuchtet mir das allerdings ein...

Gruß
Klaus