Hallo Luigi,
Wieso der ursprüngliche Versuch mit DROP in sei es SNAT (und bei
DNAT) funktioniert, ist bei genauerer Überlegung auch vollkommen
klar: diese Tabellen treffen bei dem ursprünglichen Problem gar
nicht zu.
Wie meinst du das? Ich dachte, dass eine "gedropte" Kette
gewissermaßen aktiv wird und folgerichtig alles verwirft was nicht
explizit erlaubt wurde. Oder habe ich hier etwas falsch verstanden?
Diese Tabellen (nicht INPUT-Kette o.ä., Vorsicht!) treffen nur dann zu,
wenn ein entsprechender Gegeneintrag vorhanden ist, d.h. der IP-Stack
enthält keine Einträge in seiner NAT-Tabelle, da in einem lokalen Netz wie
du es hier führst kein NAT im Ausgang durchgeführt wird. Im Eingang kann
deshalb eine Default-Policy DROP stehen (in Prerouting/NAT), da diese aber
nie durchlaufen wird, bleibt das Packet auch nicht hängen. Sie würde nur
dann abgearbeitet wenn der Stack dieses Packet im Ausgang als ge"NAT"et
erkennt.
Grüße,
Günther
Günther Mair
Internet Engineer
ENERGIS Italia GmbH
Pfarrhofstrasse 60/A
I-39100 Bozen (BZ)
Tel.: +39 0471 254000
Fax: +39 0471 251617
Email: guenther.mair(a)energis.it
Web: http://www.energis.it
Hallo Günther!
Hallo Luigi,
>> Wieso der ursprüngliche Versuch mit DROP in sei es SNAT (und
>> bei DNAT) funktioniert, ist bei genauerer Überlegung auch
>> vollkommen klar: diese Tabellen treffen bei dem ursprünglichen
>> Problem gar nicht zu.
>
>Wie meinst du das? Ich dachte, dass eine "gedropte" Kette
>gewissermaßen aktiv wird und folgerichtig alles verwirft was
> nicht explizit erlaubt wurde. Oder habe ich hier etwas falsch
> verstanden?
Diese Tabellen (nicht INPUT-Kette o.ä., Vorsicht!) treffen nur
dann zu, wenn ein entsprechender Gegeneintrag vorhanden ist, d.h.
der IP-Stack enthält keine Einträge in seiner NAT-Tabelle, da in
einem lokalen Netz wie du es hier führst kein NAT im Ausgang
durchgeführt wird. Im Eingang kann deshalb eine Default-Policy
DROP stehen (in Prerouting/NAT), da diese aber nie durchlaufen
wird, bleibt das Packet auch nicht hängen. Sie würde nur dann
abgearbeitet wenn der Stack dieses Packet im Ausgang als
ge"NAT"et erkennt.
Das dachte ich ja auch. Seinerzeit hatte ich diese Situation:
Wenn ich nat/POSTROUTING,OUTPUT und mangle/OUTPUT nicht auf ACCEPT
setze, dann kann ich vom W98-Client (ausführen --> winipcgf -->
aktualisieren) die Adresse nicht mehr aktualisieren.
Ein Überprüfen der /var/log/messages sagt dann
lintsz01 dhcpd: DHCPACK on 192.168.1.199 to 00:a0:24:ef:94:a1 via
eth0 lintsz01 dhcpd: send_packet: Operation not permitted
Vielleicht habe ich sonst noch etwas falsch gemacht, kann im Moment
keine Tests durchführen weil dass Netzteil vom Hub den Geist
aufgegeben hat..
Grüße
Luigi