PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : iptables: reihenfolge der regeln in verbindung mit masquerading...



Matzetronic
16.03.03, 18:50
hallo,

ich habe gerade bemerkt, dass es scheinbar nicht egal ist, an welcher stelle der firewall-regeln das masquerading steht. laut den dokumentationen auf www.netfilter.org spielt es keine rolle, da der kernel-code "intelligent genug" sei, das zu brücksichtigen. ich habe dem bisher so vertraut, ohne es weiter zu überprüfen. jetzt bin ich gerade dabei, mal ein "ordentliches" paketfilter-script zu hacken, und teste natürlich immer nach jeder regel...

wenn ich beispielsweise
"iptables -t nat -A POSTROUTING -o $DEV_EXT -j MASQUERADE"
an den anfang setze, ist es völlig egal, was in dem restlichen script steht, es geht von innen nach aussen alles.
sobald ich erst dienste einschränke und am schluss diese zeile einfüge, funktioniert es wie gewollt.

ist das jetzt ein bug, oder so gewollt, oder schlichtweg nur falsch in der doku ? kann das jemand bestätigen oder erklären ?

danke,
matze


Edit: Hier noch das Zitat...



It's common to want to do Network Address Translation (see the NAT HOWTO) and packet filtering. The good news is that they mix extremely well.

You design your packet filtering completely ignoring any NAT you are doing. The sources and destinations seen by the packet filter will be the `real' sources and destinations. For example, if you are doing DNAT to send any connections to 1.2.3.4 port 80 through to 10.1.1.1 port 8080, the packet filter would see packets going to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80. Similarly, you can ignore masquerading: packets will seem to come from their real internal IP addresses (say 10.1.1.1), and replies will seem to go back there.

geronet
16.03.03, 20:16
Es kommt ja drauf an in welche Tabelle du deine Filterregeln reinsetzt. Normalerweise sollten diese in der table filter "-t filter" stehen und nicht in "-t nat".
Du kannst ja auch mit "iptables -vL" und "iptables -t nat -vL" überprüfen ob deine Regeln auch so drin sind wie sie sollen.

Grüsse, Stefan

Jinto
16.03.03, 20:25
Original geschrieben von Matzetronic
hallo,

ich habe gerade bemerkt, dass es scheinbar nicht egal ist, an welcher stelle der firewall-regeln das masquerading steht. laut den dokumentationen auf www.netfilter.org spielt es keine rolle, da der kernel-code "intelligent genug" sei, das zu brücksichtigen. Ich schlage vor, du nimmst die deutsche Übersetzung. Zumde steht dort nicht, es wäre egal wo was steht, sondern dass man die Paket-filter und die Paket-NAT Regeln unabhängig voneinander definieren kann.

Die Regeln innerhalb einer Kette sind von ihrer Reihenfolge abhängig.

HTH

Matzetronic
16.03.03, 20:54
hmm,

dann habe ich es wohl falsch interpretiert. :ugly:
werde mich wohl erstmal noch ein wenig tiefer in die materie hineinstürzen müssen....

danke erstmal für eure antworten.

mfg,
matze

Matzetronic
17.03.03, 22:50
Die Regeln innerhalb einer Kette sind von ihrer Reihenfolge abhängig

hmm, mal ganz ernsthaft gefragt, wie sieht denn die optimale reihenfolge bezogen nur auf post/pre-routing aus ?

1. chains löschen
2. policy setzen
ist soweit i.o., aber dann ?

3. erst masq und dann forward-chain oder lieber umgekehrt ?

bisher hab ich erst die forward-chain und am schluß masq ...

und an welche stelle dann die dnat-regeln ?




_____
Eingehend / \ Ausgehend
-->[Routing ] ---> |FORWARD|------->
[Entscheidung] \_____/ ^
| |
v ____
___ / \
/ \ |OUTPUT|
|INPUT| \____/
\___/ ^
| |
----> Lokaler Prozess ---


also zuerst die routingentscheidung, das heißt für ausgehende pakete mit masq, dass sie direkt wieder rausgehen, richtig ?
denn ich kann ja nur eine masq-regel haben, und alles geht raus, die forward-chain wird also logischerweise übersprungen !? :ugly:

genau das meinte ich, ich definiere forward für meinetwegen port 80, was aber völlig sinnlos ist, da meine nachfolgende masq-regel eh alles weiterleitet. es funktioniert nur, wenn ich erst port 80 forwarde, dann den rest droppe (forward-chain), und dann die masq-regel setze.

wäre alles nicht schlimm, aber wenn ich in der forward-chain etwas droppe, dann geht DNAT nicht, egal, an welcher stelle es steht..... :ugly:

also wäre nett, wenn mir jemand mal aus diesem denkmuster bzw. fehler ausbrechen hilft *argh*


mfg,
matze

edit: jetzt hats die schöne ascii-grafik verhauen :mad:

HangLoose
17.03.03, 23:08
hi


wenn ich beispielsweise
"iptables -t nat -A POSTROUTING -o $DEV_EXT -j MASQUERADE"
an den anfang setze, ist es völlig egal, was in dem restlichen script steht, es geht von innen nach aussen alles.

nein, mit dieser regel gibst du ja nur an, das alle pakete, die die postrouting chain verlassen, mit der öffentlichen ip *maskiert* werden. damit ist aber noch nicht geregelt, ob ein paket überhaupt die output oder forward chain (bei ausgehenden paketen) verlassen darf.

edit: das setzt natürlich voraus, das die default chain auf drop steht


Gruß HL

Matzetronic
17.03.03, 23:57
hmm,

ich werd das am we mal genauestens (pen)-testen :)
werde dann hier mal die ergebnisse posten... (und ggfs. vor euch als netfilter-gurus niederknien :)

danke erstmal für die antworten.

mfg,
matze

HangLoose
18.03.03, 00:02
(und ggfs. vor euch als netfilter-gurus niederknien :)

das geht zwar runter wie öl, trifft den nagel aber nicht :D


Gruß HL