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

[Martin Dresbach]

Hallo Klaus.

Sorry, heute hatte ich anscheinend ein bis fünf Kaffee zu wenig. :)
An manchen Stellen hat sich da irgendwie ein kleiner Fehlerteufel
eingeschlichen...

Zitat:
> Steht so in der base.txt, wenn auch via dem Standard N='1' nicht
> aktiv. Hab halt meine weiteren Regeln einfach als 3 usw bezeichnet,
> weswegen nun 2 mit drin ist. Soll ich das löschen?

Da ich nicht beurteilen kann, ob du die Samba-Ports in deinem Setup
benötigst, kann ich dir da leider nichts zu sagen. Wenn du die Ports
natürlich nicht benötigst, spricht auch nichts dagegen, die Regel so
zu lassen. Brauchst du Samba nicht, kannst du die ja raus nehmen und die
Nummerierung der nachfolgenden Regeln entsprechend aufrücken.

Zitat:
> Hab ich dahingehend aus der Doku: "if:br0:any tmpl:dns @xbox
> IP_NET_1_IPADDR ACCEPT".

Da hast du allerdings Recht, das Beispiel steht so drin. Allerdings
verstehe ich dieses um ehrlich zu sein nicht völlig. Offensichtlich
kann man nur nicht das Ziel-Interface bestimmen, sehrwohl aber die
Ziel-IP. Meiner Meinung nach ist das aber nirgends in der Doku so
wirklich erwähnt. Ich kann dir aber aus meiner Erfahrung sagen, dass
die Regeln auch ohne diese Angabe funktionieren.

Zitat:
> [...] PF_INPUT_3='1.2.3.4 prot:tcp 22 ACCEPT'. 1.2.3.4 wäre dann
> natürlich durch die zuzulassende IP zu ersetzen.
> Fehlermeldung beim build?

Sorry, da war wieder der Kaffeemangel... einfach die Reihenfolge
umdrehen. Das Protokoll kommt natürlich VOR der IP. Also:
PF_INPUT_3='prot:tcp 1.2.3.4 22 ACCEPT'

Zitat:
> Sowohl
> PF_INPUT_x='if:dynamic:any prot:tcp 22 ACCEPT'
> als auch
> PF_INPUT_x='dynamic prot:tcp 22 ACCEPT'
> wie auch
> PF_INPUT_x='prot:tcp dynamic 22 ACCEPT'
> gibt einen Fehler?

Auch das schiebe ich dann mal auf den Kaffee...
Das mit dem "dynamic" geht nicht als Interface sondern z.B. bei der
FORWARD-Chain als Quallengabe.

Zitat:
> Ok, das heißt aber, daß dafür dann auf keinen Fall
> PF_INPUT_x='IP_NET_3' gesetzt sein darf, richtig?

Auch wenn der Befehl unvollständig ist (es würde z.B. das ACCEPT
fehlen), im Prinzip hast du recht.

Zitat:
> Logik: weil fli4l sozusagen (via "REJECT") eine Mauer zwischen 1 und
> 3 gebaut hat, die man nur mit einer Leiter ("FORWARD") überwinden
> kann, richtig?
> Wenn ich also bei mir NET_1 _auf_ NET_3 unbeschränkten Zugriff
> erlauben will, aber nicht umgekehrt, dann muss es noch das haben:
> PF_FORWARD_x='IP_NET_1 IP_NET_3 ACCEPT'. Oder?

So könnte man sich das wohl bildlich vorstellen. :)
Die FORWARD-Regel müsste so passen, falls es dein Ziel ist, den Zugriff
nicht weiter einzuschränken. Ansonsten müsstest du die Regel halt noch
um Ziel, Quelle, Port oder Protokoll (oder was auch immer du halt
benötigst) erweitern.

Zitat:
> Zugang für NET_3 zu z.B. DNS
> 
> Wenn du den DNS-Zugriff für ALLE NET_3 Clients auf den Fli erlauben
> willst, würde PF_INPUT_x='IP_NET_3 tmpl:dns ACCEPT' reichen. Um den
> Zugriff für nur EINEN Client aus NET_3 zu erlauben könntest du dann
> PF_INPUT_x='1.2.3.4 tmpl:dns ACCEPT' verwenden, wobei hier 1.2.3.4 der
> IP des Clients entspricht.

Auch hier stimmt die Reihenfolge der Regel natürlich nicht. Richtig
wäre also: PF_INPUT_x='tmpl:dns 1.2.3.4 ACCEPT'.

Sorry nochmal für die Verwirrung und weiterhin beim Basteln.

Liebe Grüße,
Martin