"Matthias Eberspächer" wrote: [...]
danke für die Ideen. Wie gesagt läuft bind auf dem Router:
rcnamed status Checking for nameserver BIND 9 running
OK.
search sol nameserver 192.168.1.1
OK
Übrigens bekommt der Router vom Provider auch artig die neuen nameserver & trägt sie in seine resolv.conf ein:
[...]
search sol nameserver 212.60.192.100 nameserver 212.60.192.101
??? IMO Blödsinn. Wenn Du einen lokalen named laufen hast, solltest Du die Nameserver des Providers in deiner bind-Konfiguration als forwarder eintragen (das ist dann allerdings nicht mehr dynamisch) Ansonsten findet der Client NIE einen Rechner im I-Net (da dein lokaler Bind die auch nicht kennt). Auf dem Server wird (lokal) ab der Einwahl der lokale bind nicht mehr verwenden (s. resolv.conf); den kannst Du auch runterfahren und am Server trotzdem noch surfen. Also: - lokale resolv.conf auf dem Server NICHT durch die Einwahl ändern lassen - die NS des Providers als forwarder in die Config des named eintragen - Die clients erhalten als NS den Server (wie gehabt)
Ich hab auch schon hoffnungsfrohes hoch- und 'runterfahren der Firewall (auf Router & Client) sowie des Nameservers (auf dem Router) ausprobiert. Es hängt auch noch ein zweiter Client (mit Suse 8.2) am Router. Das ist der meiner Frau und wird kaum genutzt :o) An dem haben wir mit an Sicherheit grenzender Wahrscheinlichkeit nix geändert und von dem läuft auch nichts mehr - damit liegt doch die Vermutung nahe, dass es an der Router-Konfig hängt, oder?!
Ok, forwarding hast Du aktiviert. Wie sieht mit masquerading aus? Der einzige Rechner mit 'ner offiziellen IP wird Dein Route sein; wenn Du masquerading nicht aktiviert hast, werden die Pakete der Rechner hinter deinem Router zwar rausgelangen, aber kein einziges Antwortpaket findet den Weg zurück. Also: in der SuSE-FW II auf dem Router MUSS masquerading in der Configuration eingestellt werden, damit clients aus dem lokalen LAN über den Router ins Nezt kommen UND auch Antworten zurück kommen. Andreas