Routing mit Gentoo einrichten

[Christoph Schnauß]

hallo Forum,

ich trage mal eine Diskussion hier herein, die ich an anderer Stelle bereits führe, in der mir aber noch eine praktikable Antwort fehlt. Schuld daran, daß ich euch jetzt damit belästige, ist Fabian, der mich auf einen etwas älteren Thread (an dem ich sogar beteiligt war) aufmerksam gemacht hat.

Der Hintergrund: ich kenne Gentoo jetzt schon ein Weilchen und halte es derzeit von allen Linux-Distributionen, die ich mir angeschaut habe, für die überzeugendste. Allerdings hatte ich es mir bisher immer nur auf irgendwelchen Netzwerk-Clients eingerichtet oder aber auf Rechnern, die über einen (Hardware-)Router ins Internet gehen, so daß ich mir über die Internetanbindung keine Gedanken zu machen brauchte, da die Eintragung eines Gateway in /etc/conf.d/net genügte, um Gentoo online zu bringen.

Da ich aber meinem Ruf als Betriebssystemsammler gerecht werden möchte, versuche ich nun seit etwas über einer Woche, Gentoo auf meinem Netzwerk-Host so einzurichten, daß es nicht nur selber online gehen, sondern auch routen kann. Und die Geschichte mit dem Routing klappt nicht.

Der Rechner kann online gehen, und über die zweite Netzwerkschnittstelle funktioniert auch ein ping im lokalen Netz. Das heißt, die LAN-Kisten, die hintendranhängen, können ihn erreichen, aber sie können ihn (noch) nicht als Gateway benutzen, weil er mit Gentoo nix weiterleitet. An der Hardware liegts nicht, mit anderen Systemen klappt das problemlos. Alles, was sich in den verlinkten Quellen auffinden läßt, habe ich inzwischen durchprobiert, aber "es geht nicht". Und es gibt auch nix im log, was ich zur Korrektur verwenden könnte, da steht immer nur, daß die DSL-Verbindung aufgebaut wurde. Was mach ich nun?

Grüße aus Berlin

Christoph S.

[Henryk Plötz]

Moin,

Der Rechner kann online gehen, und über die zweite Netzwerkschnittstelle funktioniert auch ein ping im lokalen Netz. Das heißt, die LAN-Kisten, die hintendranhängen, können ihn erreichen, aber sie können ihn (noch) nicht als Gateway benutzen, weil er mit Gentoo nix weiterleitet.

Willst du wirklich routen oder doch eher nur Masquerading machen? Für's routen musst du nur die passenden Routen einrichten (wenn du Rechner in allen beteiligten Netzen pingen kannst, sind die offenbar eingerichtet) und dann das Forwarding aktivieren, wie unter jeder anderen Distribution auch (echo 1 > /proc/sys/net/ipv4/ip_forward). Wenn du (evt. zusätzlich noch) Masquerading machen willst, musst du - wie unter jeder anderen Distribution auch - passende iptables-Regeln setzen.

Für die iptables-Regeln hat Gentoo ein Skript welches beim Runterfahren automatisch die Regeln sichert und bei Hochfahren wieder herstellt (auf Wunsch sogar mit den Zählern). Das Skript muss natürlich gestartet werden (rc-update add iptables default; dann ggbf. /etc/init.d/iptables start) und wenn du das in der Konfiguration (/etc/conf.d/iptables) eingetragen hast, aktiviert es freundlicherweise auch gleich das forwarding für dich (ENABLE_FORWARDING_IPv4="yes"). (Ein SAVE_RESTORE_OPTIONS="-c" sorgt dafür, dass die Zähler gesichert und wiederhergestellt werden.)

Jetzt kannst du - wie unter jeder anderen Distribution auch - die passenden Regeln eingeben. Zum Beispiel

iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -j REJECT --reject-with icmp-net-prohibited
iptables -P FORWARD DROP

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Sie werden beim Runterfahren automatisch gespeichert, aber um sicherzugehen wäre es keine schlechte Idee das jetzt manuell anzustoßen: /etc/init.d/iptables restart

Fertig ist die Laube.

(Speziell für Gentoo gibt es da aber auch Doku zu, mit teilweise anderen Ansätzen, siehe http://www.gentoo.org/doc/en/home-router-howto.xml.)

[Fabian St.]

Hi Christoph!

Hast du dein Routing unter Gentoo nun hinbekommen?

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Hast du dein Routing unter Gentoo nun hinbekommen?

Nö, immer noch nicht.

:-(

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

Hast du dein Routing unter Gentoo nun hinbekommen?

Nö, immer noch nicht.

:-(

Auch auf die Gefahr hin, dass ich mich wiederhole und das du einige Sachen hier bereits zum zweiten oder gar dritten Male liest, liste ich nochmals alle Sachen auf die m.E. wichtig sind. Manchmal sieht man den Wald vor lauter Bäumen nicht...

1.) Ich gehe davon aus, dass du mit deinem Gentoo-Rechner bereits online gehen kannst (z.B. mit rp-pppoe).
2.) Du hast zwei Netzwerkkarten (eth0 [192.168.0.1] --> LAN , eth1 [192.168.10.1] --> WAN)
3.) Alle benötigten iptables-Module sind fest in den Kernel einkompiliert oder als Module vorhanden, iptables ist installiert.
4.) Alle anderen iptable-Regeln sind gelöscht (iptables -F).
5.) IP-Forwarding ist gesetzt:

echo "1" > /proc/sys/net/ipv4/ip_forward

Masquerading ist aktiviert:

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Korrektur des MTU-Wertes für die Clients:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

5.) Auf den Linux-Clients legt nun folgende Zeile den Gateway fest:

route add -net default gw 192.168.0.1 netmask 0.0.0.0 metric 1 # 192.168.0.1 ist dabei natürlich die IP des Routers
6.) Eine traceroute auf den Clients sollte nun folgende Ausgabe haben:

fabi@erde ~# traceroute forum.de.selfhtml.org
traceroute to odin.selfhtml.org (213.198.84.177), 30 hops max, 40 byte packets
 1  sonne (192.168.0.1)  0.510 ms  0.314 ms  0.159 ms # mein Gentoo-router
 2  217.5.98.11 (217.5.98.11)  56.595 ms  58.795 ms  57.774 ms
 3  217.237.152.94 (217.237.152.94)  53.944 ms  54.228 ms  55.671 ms
 4  f-ea1.F.DE.net.DTAG.DE (62.154.18.22)  63.800 ms  63.594 ms  63.176 ms
 5  p1-0-3-0.r01.frnkge02.de.bb.verio.net (129.250.9.137)  64.444 ms  62.778 ms 63.210 ms

[...]

Mich würde es wirklich sehr, sehr wundern, wenn das nicht funktionieren sollte. Ich habe mir jetzt mal extra die 2004.3 gezogen, um mögliche Probleme mit der neuen Version auszuschließen zu können, und auf einem Testrechner installiert. Das Routing funktionierte sofort anstandslos - wie ich es unter SuSE und Gentoo gewöhnt war.

Grüße,
Fabian St.

P.s Sorry für das OT auf forums.gentoo.org in deinem "DSL-Verbindung schlägt fehl"-Thread ;-)

[Christoph Schnauß]

hallo Fabian,

1.) Ich gehe davon aus, dass du mit deinem Gentoo-Rechner bereits online gehen kannst (z.B. mit rp-pppoe).

Korrekt.

2.) Du hast zwei Netzwerkkarten (eth0 [192.168.0.1] --> LAN , eth1 [192.168.10.1] --> WAN)

Jaein. Es gibt einen onboard-Chip fürs LAN (192.168.0.1, bei allen Clients als Gateway eingetragen) und eine Karte (DHCP), an der das DSL-Modem hängt.

3.) Alle benötigten iptables-Module sind fest in den Kernel einkompiliert

Das sind sie.

4.) Alle anderen iptable-Regeln sind gelöscht (iptables -F).
5.) IP-Forwarding ist gesetzt

Das trifft zu.

Masquerading ist aktiviert:
    iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
    Korrektur des MTU-Wertes für die Clients:
    iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Das ist so geschehen.

6.) Eine traceroute auf den Clients sollte nun folgende Ausgabe haben

Sollte, tut es aber nicht.

Mich würde es wirklich sehr, sehr wundern, wenn das nicht funktionieren sollte.

Dann wundere dich mal. Mit Debian funktioniert das ja, aber mit Gentoo nicht.

Ich habe mir jetzt mal extra die 2004.3 gezogen, um mögliche Probleme mit der neuen Version auszuschließen zu können, und auf einem Testrechner installiert. Das Routing funktionierte sofort anstandslos

Schön für dich. Ich habe mittlerweile rund ein dutzendmal iptables deinstalliert und wieder installiert, mehrere dutzendmal den Kernel neu gebaut bzw. kontrolliert. Ich habe den Service von http://www.harry.homelinux.org bemüht und mehrere Scripts von http://www.linuxguruz.com/iptables probiert  -  das bißchen Anpassen, was da nötig ist, kriege ich schon hin. Dann gibts noch http://www.subverted.net/wakka/wakka.php?wakka=GentooRouting, wobei ich die Scripts auch da anpassen muß, zusätzlich wird mir von dem dort angebotenen Script aber gleich der X-Server geblockt, was ich nicht so schön finde.

Es läuft in de.comp.os.unix.linux.misc auch noch eine Anfrage.

P.s Sorry für das OT auf forums.gentoo.org in deinem "DSL-Verbindung schlägt fehl"-Thread ;-)

Gottchen, da gibts Schlimmeres ;-)

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi!

6.) Eine traceroute auf den Clients sollte nun folgende Ausgabe haben

Sollte, tut es aber nicht.

Das ist schlecht.

Mich würde es wirklich sehr, sehr wundern, wenn das nicht funktionieren sollte.

Dann wundere dich mal. Mit Debian funktioniert das ja, aber mit Gentoo nicht.

Mache ich gerade ;-) Normalerweise ist man ja sowas von Windows gewöhnt - SuSE lasse ich mir auch noch eingehen, aber Gentoo?!

Ich habe mir jetzt mal extra die 2004.3 gezogen, um mögliche Probleme mit der neuen Version auszuschließen zu können, und auf einem Testrechner installiert. Das Routing funktionierte sofort anstandslos

»»

Schön für dich.

Find' ich auch :-/ Den Sarkasmus (?) verstehe ich jetzt aber nicht...

Ich habe mittlerweile rund ein dutzendmal iptables deinstalliert und wieder installiert, mehrere dutzendmal den Kernel neu gebaut bzw. kontrolliert. Ich habe den Service von http://www.harry.homelinux.org bemüht und mehrere Scripts von http://www.linuxguruz.com/iptables probiert  -  das bißchen Anpassen, was da nötig ist, kriege ich schon hin. Dann gibts noch http://www.subverted.net/wakka/wakka.php?wakka=GentooRouting, wobei ich die Scripts auch da anpassen muß, zusätzlich wird mir von dem dort angebotenen Script aber gleich der X-Server geblockt, was ich nicht so schön finde.

Die obigen Seiten kenne ich, wobei die Qualität mancher Artikel stark zu wünschen übrig lässt, da sie nicht gerade aktuell sind...

Es läuft in de.comp.os.unix.linux.misc auch noch eine Anfrage.

Diese scheint jedoch im Moment auch noch nichts gewinnbringendes hervorgebracht zu haben.

Wenn du es hinbekommen hast, so lasse mich das bitte wissen, da es mich schon interessieren würde, worans hakt.

P.s Sorry für das OT auf forums.gentoo.org in deinem "DSL-Verbindung schlägt fehl"-Thread ;-)

Gottchen, da gibts Schlimmeres ;-)

Na dann, ist ja gut :-)

Grüße,
Fabian St.

[Henryk Plötz]

Moin,

Jaein. Es gibt einen onboard-Chip fürs LAN (192.168.0.1, bei allen Clients als Gateway eingetragen) und eine Karte (DHCP), an der das DSL-Modem hängt.

Den Teil nach dem 'und' verstehe ich nicht.

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Diese Einstellung ist mindestens fragwürdig, siehe http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#PMTUD.

Sollte, tut es aber nicht.

Na dann mal Butter bei die Fische, was passiert denn? Liefere idealerweise noch die Ausgabe von route -n auf dem Router und den Clients, sowie iptables -nvL und iptables -t nat -nvL dazu.

[Christoph Schnauß]

hallo Henryk,

Es gibt einen onboard-Chip fürs LAN (192.168.0.1, bei allen Clients als Gateway eingetragen) und eine Karte (DHCP), an der das DSL-Modem hängt.
Den Teil nach dem 'und' verstehe ich nicht.

Jetzt verstehe ich nicht, was du nicht verstehst. Die RealTek-Karte, die ich in einen Slot gesteckt habe, hat ein Kabel, das zum DSL-Modem führt. Sie ist bei meiner augenblicklichen Gerätekonstellation eth1. dmesg zeigt mir für diese Karte:
  eth1: RealTek RTL8139 at 0xd400, 00:50:bf:91:2a:24, IRQ 177
  eth1:  Identified 8139 chip type 'RTL-8139C'
Darüberhinaus gibts auf dem Mainoard einen Chip, der laut dmesg so gefunden wird:
  eth0: 3Com Gigabit LOM (3C940)
        PrefPort:A  RlmtMode:Check Link State
Am entsprechenden Ausgang steckt ein Kabel fürs LAN. Auf die Ausgabe von ifconfig darf ich sicher verzichten. eth1 hat die 192.168.0.1 zugewiesen bekommen, eth0 bekommt seine aktuelle IP vom ISP (t-online) zugewiesen. Der Rechner geht online (ich schreibe gerade von ihm aus), im LAN funktioniert alles wie gewünscht. Nur die Sache mit dem Routing klappt eben (noch immer) nicht.

Liefere idealerweise noch die Ausgabe von route -n auf dem Router und den Clients, sowie iptables -nvL und iptables -t nat -nvL dazu.

Gut. Das gibt aber nen bissel viel Zeugs ab. Zuerst der Netzwerkclient. Da läuft im Moment eine SuSE 9.2. die aktuelle Routingtabelle sieht so aus:
  pc2:~ # route -n
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  192.168.0.0     192.168.0.1     255.255.255.0   UG    0      0        0 eth0
  192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
  169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
  127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
  0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
  pc2:~ #
Das ist völlig korrekt. Die Anzeige würde auch nicht anders aussehen, wenn der Router/Host korrekt arbeiten würde. Auf einem Windows-Client gibts nun leider keinen Konsolenbefehl "route -n", da muß dafür "route print" getippt werden. Und das ergibt bei einem solchen Client:
   Aktive Routen:
  Netzwerkadresse      Subnet Mask  Gateway-Adresse    Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.3      192.168.0.3       1
      192.168.0.3  255.255.255.255        127.0.0.1        127.0.0.1       1
    192.168.0.255  255.255.255.255      192.168.0.3      192.168.0.3       1
        224.0.0.0        224.0.0.0      192.168.0.3      192.168.0.3       1
  255.255.255.255  255.255.255.255      192.168.0.3      192.168.0.3       1
Du siehst, auch das ist korrekt. Das heißt, sofern der hier als Gateway eingetragene Rechner routen kann, bekommt der Client auch das, was er haben möchte. Auf Windows gibt es iptables sowieso nicht, so daß sich dein Wunsch nach "iptables -t nat -nvL" erübrigt, und auf der SuSE-Kiste hab ich es nicht installiert (brauche ich ja für einen Client auch nicht), so daß es da ebenfalls keine Aussage geben kann.

So, und jetzt zum Router/Host mit seinen beiden Schnittstellen. Statt "route -n" nehme ich gewohnheitsmäßig lieber netstat. Das liefert folgendes bei bestehender online-Verbindung:
  bash-2.05b# netstat -nr
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
  217.5.98.87     0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
  192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
  127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
  0.0.0.0         217.5.98.87     0.0.0.0         UG        0 0          0 ppp0
  bash-2.05b#
"eth1" taucht hier nicht auf, das ist aber richtig, weil ppp0 von der Karte realisiert wird. "eth1" wird nur offline als vorhanden gelistet, wenn keine Verbindung zum Internet besteht, wenn ich online bin, steht an dessen Stelle ppp0. Auch an dieser Tabelle kann ich keine Fehler sehen, und selbstverständlich habe ich schon mehrfach probiert, ob ich eventuell noch irgendeine per "Route add" dazuschreiben sollte. Ein Gateway-Eintrag in /etc/conf.d/net wird für diesen Rechner nicht benötigt, es genügen in diesem Script die Zeilen:
  iface_eth0="192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0"
  iface_eth1="dhcp"
  dhcpcd_eth1="..."
  iface_eth1="up"

Damit die Geschichte mit dem "Forwarding" klappt, wird überall ein Konsolenbefehl
  echo "1" > /proc/sys/net/ipv4/ip_forward
genannt. Nach der Installation von iptables-1.2.11 war mir allerdings gesagt worden, ich solle
  echo "1" > /proc/sys/net/ipv4/conf/all/forwarding
machen. Um möglichen Konflikten zu entgehen, habe ich ganz einfach in /etc/sysctl.conf eine Zeile
  net.ipv4.ip_forward = 1
eingetragen, die denselben Zweck erfüllt, und zwar gleich für beide Pfade. Ich kann das mit einem simplen "cat" für beide Pfade ja unmittelbar nach Systemstart prüfen. Da erhalte ich:
  bash-2.05b# cat /proc/sys/net/ipv4/ip_forward
  1
  bash-2.05b# cat /proc/sys/net/ipv4/conf/all/forwarding
  1
  bash-2.05b#
Einige Quellen, die man online nachlesen kann, behaupten, damit sollte bereits grundsätzlich ein "Routing" möglich sein.

Gut, du siehst, die Hardware arbeitet korrekt und kann angesprochen werden. Ping geht problemlos, auf eine Ausgabe verzichte ich jetzt. "Private" IP-Adressen sind also korrekt verteilt, schließlich kann der lokale Apache, der auf dem "Host-Rechner" läuft, von allen Clients angerufen werden.

(Moment, es geht gleich weiter, ich habe das Limit, wie groß ein posting erreichen darf, überschritten)

[Christoph Schnauß]

(Fortsetzun)

Dann kann es jetzt an das eigentliche Problem mit "iptables" gehen. Voraussetzung, daß es funktionieren könnte, sind ein paar Einträge im Kernelscript. Der Auszug aus /usr/src/linux/.config wird jetzt leider eine etwas längere Liste:
  #
  # Networking options
  #
  CONFIG_PACKET=y
  CONFIG_PACKET_MMAP=y
  CONFIG_NETLINK_DEV=y
  CONFIG_UNIX=y
  CONFIG_INET=y
  CONFIG_IP_MULTICAST=y
  CONFIG_IP_ADVANCED_ROUTER=y
  CONFIG_IP_MULTIPLE_TABLES=y
  CONFIG_IP_ROUTE_FWMARK=y
  CONFIG_IP_PNP=y
  CONFIG_IP_PNP_DHCP=y
  CONFIG_NET_IPIP=m
  CONFIG_NET_IPGRE=m
  CONFIG_NET_IPGRE_BROADCAST=yiptables -t nat -nvL
  CONFIG_IP_MROUTE=y
  CONFIG_SYN_COOKIES=y
  CONFIG_INET_TUNNEL=m
  [...]
  #
  # IP: Netfilter Configuration
  #
  CONFIG_IP_NF_CONNTRACK=y
  CONFIG_IP_NF_CT_ACCT=y
  CONFIG_IP_NF_CT_PROTO_SCTP=m
  CONFIG_IP_NF_FTP=y
  CONFIG_IP_NF_TFTP=m
  CONFIG_IP_NF_QUEUE=m
  CONFIG_IP_NF_IPTABLES=y
  CONFIG_IP_NF_MATCH_LIMIT=y
  CONFIG_IP_NF_MATCH_IPRANGE=y
  CONFIG_IP_NF_MATCH_MAC=y
  CONFIG_IP_NF_MATCH_PKTTYPE=y
  CONFIG_IP_NF_MATCH_MARK=y
  CONFIG_IP_NF_MATCH_MULTIPORT=y
  CONFIG_IP_NF_MATCH_TOS=y
  CONFIG_IP_NF_MATCH_RECENT=y
  CONFIG_IP_NF_MATCH_ECN=y
  CONFIG_IP_NF_MATCH_DSCP=y
  CONFIG_IP_NF_MATCH_AH_ESP=y
  CONFIG_IP_NF_MATCH_LENGTH=y
  CONFIG_IP_NF_MATCH_TTL=y
  CONFIG_IP_NF_MATCH_TCPMSS=y
  CONFIG_IP_NF_MATCH_HELPER=y
  CONFIG_IP_NF_MATCH_STATE=y
  CONFIG_IP_NF_MATCH_CONNTRACK=y
  CONFIG_IP_NF_MATCH_OWNER=y
  CONFIG_IP_NF_MATCH_PHYSDEV=y
  CONFIG_IP_NF_MATCH_ADDRTYPE=y
  CONFIG_IP_NF_MATCH_REALM=y
  CONFIG_IP_NF_MATCH_SCTP=y
  CONFIG_IP_NF_MATCH_COMMENT=y
  CONFIG_IP_NF_FILTER=y
  CONFIG_IP_NF_TARGET_REJECT=y
  CONFIG_IP_NF_TARGET_LOG=y
  CONFIG_IP_NF_TARGET_ULOG=y
  CONFIG_IP_NF_TARGET_TCPMSS=y
  CONFIG_IP_NF_NAT=y
  CONFIG_IP_NF_NAT_NEEDED=y
  CONFIG_IP_NF_TARGET_MASQUERADE=y
  CONFIG_IP_NF_TARGET_REDIRECT=y
  CONFIG_IP_NF_TARGET_NETMAP=y
  CONFIG_IP_NF_TARGET_SAME=y
  CONFIG_IP_NF_NAT_LOCAL=y
  CONFIG_IP_NF_NAT_SNMP_BASIC=m
  CONFIG_IP_NF_NAT_FTP=y
  CONFIG_IP_NF_NAT_TFTP=m
  CONFIG_IP_NF_MANGLE=y
  CONFIG_IP_NF_TARGET_TOS=y
  CONFIG_IP_NF_TARGET_ECN=y
  CONFIG_IP_NF_TARGET_DSCP=y
  CONFIG_IP_NF_TARGET_MARK=y
  CONFIG_IP_NF_TARGET_CLASSIFY=y
  CONFIG_IP_NF_RAW=y
  CONFIG_IP_NF_TARGET_NOTRACK=m
  CONFIG_IP_NF_ARPTABLES=y
  CONFIG_IP_NF_ARPFILTER=m
  CONFIG_IP_NF_ARP_MANGLE=m

Es ist zu sehen, daß ich alles, was mir irgendwie wichtig erschien, vorsichtshalbe fest in den Kernel gepackt und nur ganz wenige Module gebaut habe. Mein Kernel (ich habe es sowohl mit 2.6.9 wie auch mit dem neuen 2.6.10 probiert) _sollte_ also eigentlich alles Wichtige enthalten, oder siehst du das anders?

Selbstverständlich ist ein "emerge iptables" auch gelaufen, das heißt, die iptables-Software (1.2.11) ist vorhanden und korrekt installiert. Und da ich ein "rc-update add iptables default" getippt habe, wird es mir mit "rc-update -s" auch als aktiver Dienst gelistet:
  bash-2.05b# rc-update -s
           [...]
             hotplug |      default
           ip6tables |
            iptables |      default
             keymaps | boot
           [...]

Wenn ich nach dem Kernelbacken und der Software-Installation noch gar nix weiter mache, sondern nur mal den Rechner neu starte, sehe ich unter den Bootmeldungen mit zwei roten Ausrufezeichen als Warnung markiert den Hinweis:
  pc1 rc-scripts: Not starting iptables. First create some
  rules then run
  pc1 rc-scripts: /etc/init.d/iptables save
Das ist prima, weil es zeigt, daß meine iptables-Software zwar loasarbeiten möchte, bisher aber noch gar keine Regeln definiert sind. Wenn ich jetzt wie verlangt einfach nur
  /etc/init.d/iptables save
vorgebe, ohne irgendeine "rule" festzulegen, wird ein gewissermaßen "leeres" Script in /var/lib/iptables/routes-save erzeugt, das allerdings bewirkt, daß ich bei einem unmittelbar folgenden reboot keine solche Fehlermeldungen mehr in den Startanzeigen sehe, sondern stattdessen dort steht:
* Loading iptables state and starting firewall ...
* Restoring iptables ruleset
* Mounting network filesystems ...

Wenn ich jetzt dein gewünschtes "iptables -t nat -vnL" eingebe, bekomme ich selbstverständlich nichts angezeigt, es existieren noch keine Regeln. Ich gebe also einfach mal deinen Vorschlag aus https://forum.selfhtml.org/?t=97300&m=592421 ein:
  iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
  iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
  iptables -A FORWARD -j REJECT --reject-with icmp-net-prohibited
  iptables -P FORWARD DROP
  iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Den Effekt kan ich mit "iptables -t nat -vnL" abfragen:
  bash-2.05b# iptables -t nat -vnL
  Chain PREROUTING (policy ACCEPT 251K packets, 13M bytes)
   pkts bytes target     prot opt in     out     source               destination
  Chain POSTROUTING (policy ACCEPT 131K packets, 7298K bytes)
   pkts bytes target     prot opt in     out     source               destination
      0     0 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0
  Chain OUTPUT (policy ACCEPT 241K packets, 14M bytes)
   pkts bytes target     prot opt in     out     source               destination
  bash-2.05b#
Meine SuSE-Kiste sagt mir bei einem schlichten ping aber:
  pc2:~ # ping www.google.de
  pc2:~ # unknown host www.google.de
Und das wars. Er geht nicht online.

Du hast noch auf die mir bereits bekannte Adresse http://www.gentoo.org/doc/en/home-router-howto.xml verwiesen. Wenn ich das, was dort als funktionierende Lösung vorgeschlagen wird, etwas modifiziere, gebe ich ein:
  iptables -I INPUT 1 -i eth0 -j ACCEPT
  iptables -I INPUT 1 -i lo -j ACCEPT
  iptables -A INPUT -p UDP --dport bootps -i ! eth0 -j REJECT
  iptables -A INPUT -p UDP --dport domain -i ! eth1 -j REJECT
  iptables -I FORWARD -i eth0 -d 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -A FORWARD -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -A FORWARD -i eth1 -d 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
  iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Den Effekt kan ich wieder mit "iptables -t nat -vnL" abfragen:
  bash-2.05b# iptables -t nat -vnL
  Chain PREROUTING (policy ACCEPT 251K packets, 13M bytes)
   pkts bytes target     prot opt in     out     source               destination
  Chain POSTROUTING (policy ACCEPT 131K packets, 7299K bytes)
   pkts bytes target     prot opt in     out     source               destination
      0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
      0     0 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
      0     0 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0
  Chain OUTPUT (policy ACCEPT 241K packets, 14M bytes)
   pkts bytes target     prot opt in     out     source               destination
So weit ich das beurteilen kann, sieht das korrekt aus.
Meine SuSE-Kiste sagt mir bei einem schlichten ping aber wiederum:
  pc2:~ # ping www.google.de
  pc2:~ # unknown host www.google.de
Und das wars dann.

Ich habe mich gewiß an vielen Stellen zu belesen versucht. Aber es steckt irgendwo noch ein Fehler drin, auf den ich nicht komme. Selbstverständlich habe ich auch eine Menge weiterer iptables-Befehlszeilen ausprobiert, alles bisher ohne Erfolg.

Grüße
Christoph S.

[Fabian St.]

Hi Christoph!

[...]

Meine SuSE-Kiste sagt mir bei einem schlichten ping aber:
  pc2:~ # ping www.google.de
  pc2:~ # unknown host www.google.de
Und das wars. Er geht nicht online.

Ich muss gleich nochmal weg, darum konnte ich mir das ganze nicht sehr genau durchlesen, aber das obige deutet mitunter auf einen Fehler in der DNS hin. Kann es sein, dass sowohl beim Client als auch beim Server in der /etc/resolv.conf kein Nameserver drinnen steht?

fabi@erde ~# cat /etc/resolv.conf
nameserver 194.25.2.129 # t-online nameserver

Wenn du dies bereits gemacht hast, so ignoriere bitte mein Posting!

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Wenn du dies bereits gemacht hast, so ignoriere bitte mein Posting!

ok, ich ignoriere mal ganz tapfer drauflos *g*

Grüße aus Berlin

Christoph S.

[Henryk Plötz]

Moin,

* Loading iptables state and starting firewall ...
* Restoring iptables ruleset
* Mounting network filesystems ...

Ok.

Den Effekt kan ich mit "iptables -t nat -vnL" abfragen:
  bash-2.05b# iptables -t nat -vnL
  Chain PREROUTING (policy ACCEPT 251K packets, 13M bytes)
   pkts bytes target     prot opt in     out     source               destination
  Chain POSTROUTING (policy ACCEPT 131K packets, 7298K bytes)
   pkts bytes target     prot opt in     out     source               destination
      0     0 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0
  Chain OUTPUT (policy ACCEPT 241K packets, 14M bytes)
   pkts bytes target     prot opt in     out     source               destination
  bash-2.05b#

Herzlichen Glückwunsch, deine Kiste masqueraded jetzt. Damit ist dein 'Router' funktionsfähig und die Konfiguration abgeschlossen.

Meine SuSE-Kiste sagt mir bei einem schlichten ping aber:
  pc2:~ # ping www.google.de
  pc2:~ # unknown host www.google.de
Und das wars. Er geht nicht online.

Du willst mir doch jetzt nicht sagen dass deine Aussage "er routet nicht" allein darauf basiert dass die Namensauflösung nicht funktioniert? Pinge kurzerhand mal einen Rechner nach IP-Adresse, also zum Beispiel 193.99.144.71 (heise) oder 213.198.84.177 (odin).

Die Namensauflösung musst du natürlich noch konfigurieren, klar. Entweder richtest du deinen 'Router' als DNS ein, indem du eines der vielen dafür gedachten Pakete installierst (zum Beispiel djbdns, und dann http://cr.yp.to/djbdns/run-cache-x.html oder http://cr.yp.to/djbdns/run-cache-x-home.html) und den 'Router' auf den Clients als DNS-Server in die resolv.conf einträgst. Oder (einfacher) indem du einmal nachsiehst welche Server du normalerweise verwendest (wird direkt nach dem Verbindungsaufbau in's Log geschrieben, bzw. steht dann in /etc/resolv.conf) und diese dann auf den anderen Rechnern fest einträgst.

Den Effekt kan ich wieder mit "iptables -t nat -vnL" abfragen:
  bash-2.05b# iptables -t nat -vnL
  Chain PREROUTING (policy ACCEPT 251K packets, 13M bytes)
   pkts bytes target     prot opt in     out     source               destination
  Chain POSTROUTING (policy ACCEPT 131K packets, 7299K bytes)
   pkts bytes target     prot opt in     out     source               destination
      0     0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0
      0     0 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
      0     0 MASQUERADE  all  --  *      ppp0    0.0.0.0/0            0.0.0.0/0
  Chain OUTPUT (policy ACCEPT 241K packets, 14M bytes)
   pkts bytes target     prot opt in     out     source               destination

Hmm, ich weiss nicht was das tun sollte, aber es ist schwerer Unfug am Rande der Gefährlichkeit. Mach das weg.

[Christoph Schnauß]

hallo Henryk,

nur mal so als Schmankerl zwischendurch  -  ich habe mal
  netstat -M
abgefragt. Das Ergebnis, das mich ein paar Stunden lang frustriert hat, ist:
  # netstat -M
  netstat: no support for `ip_masquerade' on this system.
Google hat mich zwar zu beschwichtigen versucht mit dem Hinweis, daß das ein Bug in netstat wäre und also keine Bedeutung hätte  -  aber ich traue dem nicht so recht.

Grrrr. Warum funktioniert es mit Debian und FreeBSD (und übrigens auch mit WindowsXP), aber auf exakt derselben Hardware nun ausgerechnet mit Gentoo nicht?

Grüße
Christoph S.

[Fabian St.]

Hi Christoph!

# netstat -M
  netstat: no support for `ip_masquerade' on this system.
Google hat mich zwar zu beschwichtigen versucht mit dem Hinweis, daß das ein Bug in netstat wäre und also keine Bedeutung hätte  -  aber ich traue dem nicht so recht.

Ich bekomme auf meinem Gentoo-Server übrigens den gleichen Fehler. Wie man auch unter Google _nachlesen_ kann, hängt dies mit der Kernel-Version zusammen: Seit 2.4 endet der Versuch, obigen Befehl abzusetzen, mit der Fehlermeldung.

Eine andere Möglichkeit, an diese Information zu kommen, wäre über /proc/net/ip_conntrack, oder dies sehr schlecht zu lesen ist, über ein Perl-Skript.

Grüße,
Fabian St.

[Christoph Schnauß]

hi,

Herzlichen Glückwunsch, deine Kiste masqueraded jetzt.

Möglicherweise tut sie das.

Damit ist dein 'Router' funktionsfähig und die Konfiguration abgeschlossen.

Nö. Es kommt jedenfalls immer noch nix bei meinem "Client" an.

Du willst mir doch jetzt nicht sagen dass deine Aussage "er routet nicht" allein darauf basiert dass die Namensauflösung nicht funktioniert?

ähm ... Nein, will ich nicht. Obschon das ein sehr guter Hinweis ist. Ich hatte dieses Problem schonmal mit einem anderen System.

Die Namensauflösung musst du natürlich noch konfigurieren, klar.

Klar.

Entweder richtest du deinen 'Router' als DNS ein, indem du eines der vielen dafür gedachten Pakete installierst (zum Beispiel djbdns, und dann http://cr.yp.to/djbdns/run-cache-x.html oder http://cr.yp.to/djbdns/run-cache-x-home.html) und den 'Router' auf den Clients als DNS-Server in die resolv.conf einträgst.

Naja, das ist bei kleineren Netzen mit weniger als zehn angeschlossenen Rechnern (auch im nächsten Kurs habe ich nur dreißig "Schüler"-Arbeitsplätze hinten dranhängen) etwas zuviel Aufwand. Da sollte eigentlich eine einigermaßen korrekt formulierte hosts-Datei noch ausreichen, gemeinsam mit dem korrekten Eintrag in /etc/resolv.conf. Auf Windows-Maschinen ist das etwas aufwendiger, da gibts keinen Resolver. In Win98SE ist es der registry-Schlüssel "NameServer" in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP. Wenn ich einen eigenen DNS auf dem "Server" brauche, dann  versuche ich es immer noch mit dem bind, den kenne ich mittlerweile ganz gut.

Oder (einfacher) indem du einmal nachsiehst welche Server du normalerweise verwendest

Das ist bei t-online zum Beispiel die 217.237.151.33, und selbstverständlich habe ich die an den entsprechenden Stellen eingetragen. Interessant ist vielleicht, daß das nicht bei allen Systemen nötig ist. Wenn ich FreeBSD auf meinem "Router" einsetze, genügt dessen lokale IP, also hier beispielsweise die 192.168.0.1.

iptables -I INPUT 1 -i eth0 -j ACCEPT
  iptables -I INPUT 1 -i lo -j ACCEPT
  iptables -A INPUT -p UDP --dport bootps -i ! eth0 -j REJECT
  iptables -A INPUT -p UDP --dport domain -i ! eth1 -j REJECT
  iptables -I FORWARD -i eth0 -d 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -A FORWARD -i eth0 -s 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -A FORWARD -i eth1 -d 192.168.0.0/255.255.255.0 -j ACCEPT
  iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
  iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Hmm, ich weiss nicht was das tun sollte, aber es ist schwerer Unfug am Rande der Gefährlichkeit. Mach das weg.

Jajaja ... is ja schon weg. Aber "schwerer Unfug" ist es nicht, sondern lediglich die konsequente Umsetzung der Ratschläge, die mir dein weiter oben vermittelter link gegeben hat :-( und außerdem inzwischen auch so etwas wie ein Ausdruck nackter Verzweiflung. Ich dachte eigentlich, ich wüßte beim Aufsetzen von Routing-Geschichten und auch im Umgang mit ipchains bzw. neuerdings eben iptables einigermaßen Bescheid. Siehe da, hier habe ich noch _irgendwas_ im System stecken, was mich Lügen straft.

Grüße aus Berlin

Christoph S.

[Henryk Plötz]

Moin,

Nö. Es kommt jedenfalls immer noch nix bei meinem "Client" an.

Dann hätte ich jetzt gerne mal ein tcpdump -i any -n -s 1500 -vv auf dem Server gestartet während auf dem Client ein Ping nach Name und dann nach IP-Adresse angestoßen wird. Das wird mir hier zu bunt. (Noch praktischer wäre ein -w irgendeinedatei und die dann per Mail zuschicken.)

In Win98SE ist es der registry-Schlüssel "NameServer" in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP.

Äh, bittewas? Was ist aus der guten alten "Eigenschaften von Netzwerk - Eigenschaften von TCP/IP -> Netzwerkadapter - DNS-Konfiguration - Suchreihenfolge für DNS-Server"-Methode geworden? (Screenshot (ganz runterscrollen) freundlicherweise von images.google.com gesponsort)

Wenn ich einen eigenen DNS auf dem "Server" brauche, dann  versuche ich es immer noch mit dem bind, den kenne ich mittlerweile ganz gut.

Na wenn du meinst. Dann kann ich mir aber auch vorstellen warum du es als 'zuviel Aufwand' beschreibst. Bei der erwähnten Software muss man eigentlich nur das Konfigskript starten, sagen "Ja, ich hätt da gerne mal einen DNS-Forwarder an Interface soundso" und gut ist. (Jetzt natürlich ganz davon zu schweigen dass djb-Software gegenüber ISC-Software, insb. Bind, durchaus eine Menge Karma-Bonuspunkte in Richtung Stabilität und Sicherheit gut hat.)

Wenn ich FreeBSD auf meinem "Router" einsetze, genügt dessen lokale IP, also hier beispielsweise die 192.168.0.1.

Dann läuft da offenbar auch ein DNS drauf.

Jajaja ... is ja schon weg. Aber "schwerer Unfug" ist es nicht, sondern lediglich die konsequente Umsetzung der Ratschläge, die mir dein weiter oben vermittelter link gegeben hat :-(

Nein. Ich hab mir das verlinkte Dokument grade nochmal angeschaut und das was du hattest hat subtile (und weniger subtile) Unterschiede gegenüber dem Original die es recht gefährlich machen. Don't try this at home, kids!

[Christoph Schnauß]

äh ...

Dann hätte ich jetzt gerne mal ein tcpdump -i any -n -s 1500 -vv auf dem Server

bash-2.05b# tcpdump -i any -n -s 1500 -vv
  bash: tcpdump: command not found
  bash-2.05b#

Ich habe halt bisher nur ein sehr "schmales" System gebaut, sorry.

In Win98SE ist es der registry-Schlüssel "NameServer" in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP.
Äh, bittewas? Was ist aus der guten alten "Eigenschaften von Netzwerk - Eigenschaften von TCP/IP -> Netzwerkadapter - DNS-Konfiguration - Suchreihenfolge für DNS-Server"-Methode geworden?

Die trägt genau diesen registry-Schlüssel ein ;-)

Wenn ich FreeBSD auf meinem "Router" einsetze, genügt dessen lokale IP, also hier beispielsweise die 192.168.0.1.
Dann läuft da offenbar auch ein DNS drauf.

Na klar.

Gut. Ich will mir in den nächsten Tagen sowieso einen anderen Rechner hierher stellen (Es gibt bei ebay für ganze 25 Euronen im "Sofortkauf" gebrauchte Kisten, die sich als Router/Gateway prima eignen). Da geht sowieso alles mit geringfügig anderer Hardware nochmal völlig von vorne los. Wenn es dann bei der nötigen Software- bzw. Systeminstallation wieder diese Probleme geben sollte, muß ich mich halt damit abfinden, Gentoo vorläufig weiter auf "Clients" einzusetzen  -  da geht ja alles prima. Und mir für die Aufgaben als "Router" ein anderes System nehmen.

Grüße
Christoph S.

[Fabian St.]

hallo,

Dann hätte ich jetzt gerne mal ein tcpdump -i any -n -s 1500 -vv auf dem Server

bash-2.05b# tcpdump -i any -n -s 1500 -vv
  bash: tcpdump: command not found
  bash-2.05b#

Ich habe halt bisher nur ein sehr "schmales" System gebaut, sorry.

Mensch, Christoph, dann merge es halt eben :-/ Die 553kB wird dein System wohl noch verkraften...

Gut. Ich will mir in den nächsten Tagen sowieso einen anderen Rechner hierher stellen (Es gibt bei ebay für ganze 25 Euronen im "Sofortkauf" gebrauchte Kisten, die sich als Router/Gateway prima eignen). Da geht sowieso alles mit geringfügig anderer Hardware nochmal völlig von vorne los. Wenn es dann bei der nötigen Software- bzw. Systeminstallation wieder diese Probleme geben sollte, muß ich mich halt damit abfinden, Gentoo vorläufig weiter auf "Clients" einzusetzen  -  da geht ja alles prima. Und mir für die Aufgaben als "Router" ein anderes System nehmen.

Du wirst doch jetzt nicht aufgeben, oder? Das ist man von dir gar nicht gewohnt! Vielleicht hilft die Ausgabe von tcpdump oder cat /proc/sys/net/ip_conntrack (siehe auch https://forum.selfhtml.org/?t=97300&m=596040) weiter und Henryk kann dir dadurch den entscheidenden Tip geben

Grüße,
Fabian St.

[Christoph Schnauß]

hallo Fabian,

Mensch, Christoph, dann merge es halt eben :-/ Die 553kB wird dein System wohl noch verkraften...

Ja, das System könnte das verkraften. Ich habe aber keine Konsole mehr dafür frei, weil ich grade ohnehin die ganze Welt neu baue und alle Konsolen beschäftigt sind ;-) Ich habe versäumt, mir die Zahl der verfügbaren Konsolen heraufzusetzen. Eine könnte ich noch freimachen, wenn ich die grafische Oberfläche beende, aber dann kann ich das Forum hier nicht mehr aufrufen ... Es macht auch keinen Sinn, noch ein xterm aufzumachen und dort irgendeinen Systemprozeß zu starten, meine CPU-Auslastung liegt bereits deutlich über 90 Prozent und der Reload der Forumshauptseite braucht über eine Minute.

Du wirst doch jetzt nicht aufgeben, oder?

Nix da. Aufgegeben wird nicht. Es ist ja eh peinlich, daß ich gerade bei einem Thema, bei dem ich mich eigentlich schon längere Zeit für ziemlich "sattelfest" gehalten habe, plötzlich Probleme bekomme. Aber ich habe halt _auch_ die Erfahrung gemacht, daß man manchmal besser fährt, wenn wirklich _alles_ von Grund auf wiederholt wird, einschließlich Zusammenschrauben der Hardware. Natürlich habe ich mir Notizen gemacht, natürlich habe ich Teile eurer postings rausgezogen. Neeeeee, also eine Lösung wirds schon geben, schließlich weiß ich, daß das, was ich erreichen will, bei anderen Leuten schon eine Weile problemlos läuft.

Vielleicht hilft die Ausgabe von tcpdump oder cat /proc/sys/net/ip_conntrack (siehe auch https://forum.selfhtml.org/?t=97300&m=596040) weiter

ip_conntrack habe ich selbstverständlich im Kernel, und
   cat /proc/sys/net/ip_conntrack
zeigt mir auch einiges. Der von dir mit dem link empfohlene "Viewer" hat bei mir aber erstmal nur eine unendlich lange Fehlerliste produziert. Das kann daran liegen, daß das Ding eben für einen 2.4er Kernel entwickelt wurde. Ich kenne mich (bekanntlich?) mit Perl gut genug aus, um am Script etwas herumzuschrauben und zu probieren, wie ich es zur Mitarbeitz überreden kann. Aber auch dafür hab ich im Augenblick keine Konsole mehr frei.

und Henryk kann dir dadurch den entscheidenden Tip geben

Der hat ja auch schon leicht genervt reagiert. Was meinst du, wie genervt ich inzwischen bin ;-)

Nein, irgendwie kriege ich das schon noch hin. Möglicherweise muß ich einfach mal zwei Tage was ganz anderes tun  -  Aquarium saubermachen oder Bücherregal einreißen und neu bauen oder sowas

Grüße aus Berlin

Christoph S.

[Fabian St.]

Hi Christoph!

Mensch, Christoph, dann merge es halt eben :-/ Die 553kB wird dein System wohl noch verkraften...

[...] Es macht auch keinen Sinn, noch ein xterm aufzumachen und dort irgendeinen Systemprozeß zu starten, meine CPU-Auslastung liegt bereits deutlich über 90 Prozent und der Reload der Forumshauptseite braucht über eine Minute.

OK, das ist ein Grund, den man gelten lassen kann :-)

Du wirst doch jetzt nicht aufgeben, oder?

Nix da. Aufgegeben wird nicht. Es ist ja eh peinlich, daß ich gerade bei einem Thema, bei dem ich mich eigentlich schon längere Zeit für ziemlich "sattelfest" gehalten habe, plötzlich Probleme bekomme. Aber ich habe halt _auch_ die Erfahrung gemacht, daß man manchmal besser fährt, wenn wirklich _alles_ von Grund auf wiederholt wird, einschließlich Zusammenschrauben der Hardware. Natürlich habe ich mir Notizen gemacht, natürlich habe ich Teile eurer postings rausgezogen. Neeeeee, also eine Lösung wirds schon geben, schließlich weiß ich, daß das, was ich erreichen will, bei anderen Leuten schon eine Weile problemlos läuft.

Auch wenn eine komplette Neuinstallation ziemlich Windows-like ist, so kann dies hier u.U. wirklich erforderlich sein. Ich wünsche dir, dass es mit dem neuen PC klappt!

ip_conntrack habe ich selbstverständlich im Kernel, und
   cat /proc/sys/net/ip_conntrack
zeigt mir auch einiges. Der von dir mit dem link empfohlene "Viewer" hat bei mir aber erstmal nur eine unendlich lange Fehlerliste produziert. Das kann daran liegen, daß das Ding eben für einen 2.4er Kernel entwickelt wurde. Ich kenne mich (bekanntlich?) mit Perl gut genug aus, um am Script etwas herumzuschrauben und zu probieren, wie ich es zur Mitarbeitz überreden kann. Aber auch dafür hab ich im Augenblick keine Konsole mehr frei.

Komisch, bei mir funktioniert es mit dem 2.6.8-gentoo-r7 (gentoo-dev-sources) ohne Probleme. Ich kenne mich jetzt mit Perl nur ziemlich bescheiden aus, aber ich konnte im Sourcecode auf die Schnelle nichts erkennen, was 2.6er spezifisch wäre.
Dieses Skript kann man darüber hinaus sogar Zweck entfremden: Da die Destination-IP aufgelöst wird (gethostbyaddr()), sieht man welche Seiten jeder gerade besucht...

Nein, irgendwie kriege ich das schon noch hin. Möglicherweise muß ich einfach mal zwei Tage was ganz anderes tun  -  Aquarium saubermachen oder Bücherregal einreißen und neu bauen oder sowas

Gar keine schlechte Idee! Die Fische wären dir sicher dankbar ;-)

Grüße,
Fabian St.

[Fabian St.]

Hi Christoph!

Irgendwie ist deine Netzwerk-Struktur nicht zu durchblicken :-/

Es gibt einen onboard-Chip fürs LAN (192.168.0.1, bei allen Clients als Gateway eingetragen) und eine Karte (DHCP), an der das DSL-Modem hängt.
Den Teil nach dem 'und' verstehe ich nicht.

Ich notiere:

[1] LAN (onboard-Chip) --> IP: 192.168.0.1
[2] WAN (PCI-Slot) --> IP: DHCP, hängt am DSL-Modem

Jetzt verstehe ich nicht, was du nicht verstehst. Die RealTek-Karte, die ich in einen Slot gesteckt habe, hat ein Kabel, das zum DSL-Modem führt. Sie ist bei meiner augenblicklichen Gerätekonstellation eth1. dmesg zeigt mir für diese Karte:
  eth1: RealTek RTL8139 at 0xd400, 00:50:bf:91:2a:24, IRQ 177
  eth1:  Identified 8139 chip type 'RTL-8139C'

d.h. die WAN-Karte (PCI) ist eth1 (Begr.: siehe [2]

Darüberhinaus gibts auf dem Mainoard einen Chip, der laut dmesg so gefunden wird:
  eth0: 3Com Gigabit LOM (3C940)
        PrefPort:A  RlmtMode:Check Link State

d.h. die LAN-Karte ist eth0 (Begr.: siehe [1])

Am entsprechenden Ausgang steckt ein Kabel fürs LAN. Auf die Ausgabe von ifconfig darf ich sicher verzichten. eth1 hat die 192.168.0.1 zugewiesen bekommen, eth0 bekommt seine aktuelle IP vom ISP (t-online) zugewiesen. Der Rechner geht online (ich schreibe gerade von ihm aus), im LAN funktioniert alles wie gewünscht. Nur die Sache mit dem Routing klappt eben (noch immer) nicht.

So, und jetzt kann etwas nicht mehr stimmen:

Die __onboard Karte__ ist doch die fürs __LAN__ und hat demnach die IP 192.168.0.1 - und nicht eth1 (WAN).

Kannst du für Aufklärung sorgen?

Grüße,
Fabian St.

[Henryk Plötz]

Moin,

Am entsprechenden Ausgang steckt ein Kabel fürs LAN. Auf die Ausgabe von ifconfig darf ich sicher verzichten. eth1 hat die 192.168.0.1 zugewiesen bekommen, eth0 bekommt seine aktuelle IP vom ISP (t-online) zugewiesen. Der Rechner geht online (ich schreibe gerade von ihm aus), im LAN funktioniert alles wie gewünscht. Nur die Sache mit dem Routing klappt eben (noch immer) nicht.

Genau das meine ich. Hier hast du mindestens ein Verständnisproblem, auf das ich hinweisen wollte: ISPs die tatsächlich DHCP auf der DSL-Strecke machen sind zumindest in Deutschland rar (mir fällt kein einziger ein), und insbesondere T-Online gehört nicht dazu.

Stattdessen wird PPPoE verwendet, welches gewissermaßen über die Ethernetverbindung die das DSL herstellt eine serielle Leitung emuliert auf der man dann ganz normal PPP macht, als wär's ein Modem. Am Ende kriegst du ein stinknormales ppp-Device (ppp0) und das kriegt als einziges Device eine (öffentliche) IP vom ISP zugewiesen. Auf der Strecke zwischen DSL-Modem und Netzwerkkarte wird nur Ethernetverkehr gebraucht und kein IP, es muss also keine IP-Adresse konfiguriert werden und insbesondere kein DHCP. (Der dhcp-Client hat zumindest in allen meinen Versuchen die unangenehme Eigenschaft gehabt das Interface kurzzeitig abzuschalten, wenn er keine Antwort kriegt, was die PPP-Software nicht lustig findet.)

Um das mal zu entwirren: Du hast eth0 und eth1, sowie später ein ppp0. eth0 ist mit dem internen Netz verbunden und kriegt von dir fest die Adresse 192.168.0.1 konfiguriert. eth1 ist mit dem Modem verbunden und darf keine Adresse konfiguriert kriegen, und auch kein DHCP. (Wenn du unbedingt willst kannst du da natürlich auch eine Adresse vergeben, aber sie _darf_ nicht aus dem 192.168.0.1/24-Netz stammen.) ppp0 kriegt später wenn die PPPoE-Verbindung steht eine öffentliche IP-Adresse vom Provider gestellt.

Gut. Das gibt aber nen bissel viel Zeugs ab. Zuerst der Netzwerkclient. Da läuft im Moment eine SuSE 9.2. die aktuelle Routingtabelle sieht so aus:
  pc2:~ # route -n
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
  192.168.0.0     192.168.0.1     255.255.255.0   UG    0      0        0 eth0
  192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
  169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
  127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
  0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
  pc2:~ #
Das ist völlig korrekt.

Nein, ist es nicht. Die erste Zeile ist mindestens überflüssig, eher aber falsch. Man kann schlecht zu 192.168.0.0/24 eine Route über 192.168.0.1 als Gateway setzen, wenn man zum Erreichen von 192.168.0.1 eine Route zu 192.168.0.0/24 bräuchte, da beisst sich die Katze in den Schwanz. Ich weiss nicht ob sie irgendeine Wirkung hat, oder einfach nur ignoriert wird, aber auf jeden Fall kann sie keine gute Wirkung haben und muss ersatzlos gestrichen werden. Die dritte Zeile ... hmm, hast du irgendwo Geräte aus dem APIPA-Bereich (also 169.254.0.0/16). Hat eth0 auf dem Client eine Adresse aus dem Bereich? Wenn nicht, weg damit.

Aktive Routen:
  Netzwerkadresse      Subnet Mask  Gateway-Adresse    Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1      192.168.0.3       1
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.3      192.168.0.3       1
      192.168.0.3  255.255.255.255        127.0.0.1        127.0.0.1       1
    192.168.0.255  255.255.255.255      192.168.0.3      192.168.0.3       1
        224.0.0.0        224.0.0.0      192.168.0.3      192.168.0.3       1
  255.255.255.255  255.255.255.255      192.168.0.3      192.168.0.3       1
Du siehst, auch das ist korrekt.

Das ist etwas unübersichtlich, aber korrekt (wenn ich nichts übersehen habe).

So, und jetzt zum Router/Host mit seinen beiden Schnittstellen. Statt "route -n" nehme ich gewohnheitsmäßig lieber netstat. Das liefert folgendes bei bestehender online-Verbindung:
  bash-2.05b# netstat -nr
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
  217.5.98.87     0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
  192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
  127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
  0.0.0.0         217.5.98.87     0.0.0.0         UG        0 0          0 ppp0
  bash-2.05b#

Ok, das stimmt.

iface_eth0="192.168.0.1 broadcast 192.168.0.255 netmask 255.255.255.0"
  iface_eth1="dhcp"
  dhcpcd_eth1="..."
  iface_eth1="up"

Wie gesagt, mach das dhcp da weg, das bringt nichts, ausser eventuellen Problemen.

Einige Quellen, die man online nachlesen kann, behaupten, damit sollte bereits grundsätzlich ein "Routing" möglich sein.

Ist es auch. Herzlichen Glückwunsch dein Rechner routet jetzt.

(Moment, es geht gleich weiter, ich habe das Limit, wie groß ein posting erreichen darf, überschritten)

[Christoph Schnauß]

hallo Henryk,

[...]

iface_eth1="dhcp"
  dhcpcd_eth1="..."
  iface_eth1="up"
mach das dhcp da weg, das bringt nichts, ausser eventuellen Problemen.

ups. Du widersprichst _allen_ Anleitungen, die ich bisher gelesen habe. Ich probiers aber mal.

Einige Quellen, die man online nachlesen kann, behaupten, damit sollte bereits grundsätzlich ein "Routing" möglich sein.
Ist es auch. Herzlichen Glückwunsch dein Rechner routet jetzt.

Nee, tut er immer noch nicht, weil ich mir jetzt grade eben noch irgendwas andres zerschossen habe und mit dem Teil gar nicht mehr online komme. Sobald er wieder online gehen kann, probiere ich mal  -  dabei sollte ja egal sein, ob ich einen 2.6.9-Kernel oder einen 2.6.10-Kernel benutze.

Grüße
Christoph S.