Am Donnerstag, 22. Mai 2003 14:08 schrieb guenther.mair@energis.it: Hallo Günther, hallo Liste! Ich habe noch ein paar Sachen herausgefunden, die du bestimmt schon kennst. Die Ketten existieren alle separat, z.B. die OUTPUT-Kette der nat oder die OUTPUT-KETTE der mangle- bzw. filter-Tabelle müssen als verschiedene Dinge betrachtet werden. Die filter-tabelle ist die einzige, die grundsatzlich nichts am Paket verändern kann. Die anderen beiden schon. Ich vermute, dass die Ketten aller Tabellen hintereindander abgearbeitet werden. Das würde einiges erklären.
Hallo!
Ich bin zwar kein Experte in Sachen DHCP und habe auch nicht so schnell die Möglichkeit etwas zu testen, aber grundsätzlich kann ich folgendes Sagen:
- mangle/nat Tabellen sind üblicherweise nur dazu da um
"Sonderfälle" zu handhaben und IP-Header im Ein-/Ausgang zu verändern; sie dürften keinen Einfluß auf DHCP nehmen
Da stimme ich dir ohne weiteres zu. Vermutlich gehört das Sperren dieser Ketten eher in den Bereich Sonderfälle.
- X-Windows Desktop-Manager (wie viele andere
Client/Server-Anwendungen) benutzen Unix- oder TCP/IP-Sockets um mit anderen Anwendungen zu kommunizieren; das macht die Verwendung von "X-Clients" (oder nennen wir sie zum besseren Verständnis "Network Clients" oder "Thin Clients") über xdmcp erst möglich
Ich glaube, dass ein ACCEPT für mangle und nat das Problem gar nicht aufkommen lässt, werde es bei Gelegenheit probieren.
- wenn die lokale Anmeldung nach Einsatz der FW-Tools nicht
läuft, würde das bedeueten, dass dies bei SuSE über eine öffentliche IP-Adresse erfolgt (loopback ist ja frei).... Sinn und Unsinn sei dahingestellt; es gibt bei SuSE allerdings irgendwo eine Konfigurationsdatei wo dies eingestellt wird..... /etc/sysconfig/xdm oder /etc/X11/xdm oder irgendsowas.... bin mir
Da habe ich nichts gefunden
nicht mehr 100%ig sicher in der Sache (versuch evtl. kurz ein "lsof -i" dann siehst du welche Anwendung sich lokal an welchen Port bindet)
Das ist ein sehr guter Tipp.
Im Anhang die abgekürzte Version des gleichen Skripts unter Verwendung von stateful connections. Ich habe das mit DHCP noch nicht getestet, aber denke schon, dass das conntrack-Modul die Sachen erkennt. Nimm bei Nicht-Funktionieren evtl. die state-Befehle weg, im Log sollte sich schon einiges finden. Ausserdem ist es vielleicht nützlich (und korrekter) die LOG-Befehle einzuschränken sonst ist dein Server bei viel Verkehr womöglich innerhalb ein paar Stunden mit einem großen Logfile zugestopft.
Werde ich beherzigen.
Grüße,
Heute habe ich noch die benutzerdefinierten Ketten etwas angeschaut. Ich glaube bis Ende nächster Woche müsste meine firewall stehen. Nochmals allen ein schönes Wochenende. Luigi