Telekom-DSL-Router, Netzwerkeinstellungen

[fischig]

Mein Frage war wahrscheinlich ungenau gestellt, worauf ich abzielte war etwas Allgemeineres: Sind für Routerbetrieb iptables-Regeln zwingend erforderlich. Ich habe bisher keine formuliert, ergo hat es noch keinen Sinn, Regeln abzufragen. Wenn ich weiß, dass Sie nötig sind ist, werde ich das umgehend nachholen.

Ich versuche, das Ganze halt Stück für Stück aufzubauen vom Notwendigen hin zum „nice to have“. Ich versuche, die Begriffe: Router und Firewall auseinanderzuhalten. Erst mal möchte ich lediglich meine Rechner im Heimnetz ins Internet kriegen. Eine Firewall hat auch schon mein Telekom-Router und ob ich dahinter noch was Besseres fabriziert kriege, ist noch nicht raus.

[MSfree]

Sind für Routerbetrieb iptables-Regeln zwingend erforderlich.

Nein. Das, was du oben mit den NAT-Regeln eingerichtet hast, ist nicht nötig, das geht effizienter (im Sinne von weniger CPU- und speicherintensiv) mit normalen Routen.

[mat6937]

Ich habe bisher keine formuliert, ergo hat es noch keinen Sinn, Regeln abzufragen. ...

OK, dann zeige doch von deinem Client den Weg (traceroute, hops, gateway), den die Datenpakete beim erfolgreichen Ping (siehe oben dein Beitrag) zur IP-Adresse 192.168.3.250 gehen.

[fischig]

Code: Alles auswählen

# traceroute -I 192.168.3.250
traceroute to 192.168.3.250 (192.168.3.250), 30 hops max, 60 byte packets
 1  192.168.3.250 (192.168.3.250)  0.386 ms  0.362 ms  0.356 ms

Das Kommando wurde eingegeben auf 192.168.100.151 Was genau ich da gemacht habe weiß ich nicht. Info zu traceroute einschließlich manpage für mich nicht erhellend. Das -I habe ich benutzt in der Hoffnung, dass ich damit sowas Ähnliches wie ping gemacht habe.

@MSfree

Nein. Das, was du oben mit den NAT-Regeln eingerichtet hast, ist nicht nötig

Kannst du das bitte direkt zitieren, ich finde mich leider nicht wieder. Hast vielleicht Beiträge meinerseits mit sochen von mat6972 verwechselt?

[mat6937]

Code: Alles auswählen

# traceroute -I 192.168.3.250
traceroute to 192.168.3.250 (192.168.3.250), 30 hops max, 60 byte packets
 1  192.168.3.250 (192.168.3.250)  0.386 ms  0.362 ms  0.356 ms

Das Kommando wurde eingegeben auf 192.168.100.151 Was genau ich da gemacht habe weiß ich nicht. Info zu traceroute einschließlich manpage für mich nicht erhellend. Das -I habe ich benutzt in der Hoffnung, dass ich damit sowas Ähnliches wie ping gemacht habe.

Versuch mal auf dem Client auch mit:

Code: Alles auswählen

route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.3.250 dev eth0

und danach:

Code: Alles auswählen

route -n
ping -c 3 192.168.3.1

[fischig]

Gleiches Spiel wie oben mit dem letzten „route add ...“: Netzwerk nich erreichbar.

[mat6937]

Gleiches Spiel wie oben mit dem letzten „route add ...“: Netzwerk nich erreichbar.

Versuch mal für den host (d. h. für eine IP-Adresse statt dem Subnetz):

Code: Alles auswählen

route add -host 192.168.3.1 gw 192.168.3.250 dev eth0

[fischig]

Es dauert immer einige Zeit, bis ich Anregungen umsetzen kann, weil ich immer einen Router ab-. und dann den anderen anklemmen muss (und squid nimmt sich auf dem alten beträchtliche Auszeiten beim Runterfahren ) Beide simultan ans Kabel anzuschließen geht hier nicht, schon wegen der räumlichen Gegebenheiten.

edit:
wieder Netzwerk nicht erreichbar.

[mat6937]

edit:
wieder Netzwerk nicht erreichbar.

Machst Du _vor_ dem Eintrag der route, auch den Ping zur IP-Adresse 192.168.3.250?
Denn evtl. hat es auch etwas mit deiner Konstellation zu tun, bei der:

... weil ich immer einen Router ab-. und dann den anderen anklemmen muss (und squid nimmt sich auf dem alten beträchtliche Auszeiten beim Runterfahren ...

[fischig]

Machst Du _vor_ dem Eintrag der route, auch den Ping zur IP-Adresse 192.168.3.250?

Ja.
Es hilft nichts, bisher kommen wir nicht weiter, warum die vermaledeite Maschine einerseits sowohl mit einem LAN-Klienten als auch mit dem Internet kommuniziert, aber andererseits den Klienten partout noicht an den Speedport lassen will. Nichtsdestotrotz: ich setze jede weitere Anregung von dir um. Aber vielleicht brauchen wir frische Kräfte.

So, für mich ist für heute Schluss. Gute Nacht und einstweilen danke für deine Anregungen!

[mat6937]

Es hilft nichts, bisher kommen wir nicht weiter, warum die vermaledeite Maschine einerseits sowohl mit einem LAN-Klienten als auch mit dem Internet kommuniziert, aber andererseits den Klienten partout noicht an den Speedport lassen will.

Teste mal auf dem Linux-Router auch mit:

Code: Alles auswählen

sysctl -w net.ipv4.conf.eth0.rp_filter=1
sysctl -w net.ipv4.conf.eth1.rp_filter=1

Danach auf dem Client:

Code: Alles auswählen

ping -c 3 192.168.3.250

[fischig]

So, durchgeführt. Auf dem Linux-Router meine ich nur zu erkennen, dass er die beiden Kommandos ausgeführt hat. Meldung:

Code: Alles auswählen

net.ipv4.conf.eth0.rp_filter=1

eth1 entsprechend.
Ping vom Klienten aus auf 192.168.3.250 funktioniert - aber das tat er doch auch vorher schon.

[mat6937]

So, durchgeführt. Auf dem Linux-Router meine ich nur zu erkennen, dass er die beiden Kommandos ausgeführt hat. Meldung:

Code: Alles auswählen

net.ipv4.conf.eth0.rp_filter=1

eth1 entsprechend.
Ping vom Klienten aus auf 192.168.3.250 funktioniert - aber das tat er doch auch vorher schon.

OK, dann starte auf dem Linux-Router:

Code: Alles auswählen

tcpdump -c 200 -vvveni eth0 net 192.168.3.0/24

mach danach vom Client die Pings:

Code: Alles auswählen

ping -c 1 192.168.3.250
ping -c 2 192.168.3.1

und poste nach den Pings, die Ausgabe des tcpdump vom Linux-Router.

[fischig]

Ok, dauert wieder ein wenig. Mir fiel beim Booten gerade die Meldung auf: „KVM disabled by BIOS“ und mir ging durch den Kopf, ob das bei meinen Problemen beteiligt sein könnte. Eine erste, oberflächliche Recherche lässt mich vermuten: eher nicht - richtig?
Noch was: Da tcpdump nicht installiert war, habe ich versucht es nachzuinstallieren - ohne Probleme. Er pingt also nicht nur ins Internet, er läd auch runter.
Dann will ich mal wieder wechseln.

[fischig]

Ich hab's ein wenig anders gemacht, weil ich nicht umgehen kann mit Meldungen die nach oben aus der Konsole laufen. Deswegen habe ich versucht, die Meldungen in eine Datei zu schreiben (die ich dann auf den Klienten verschoben, von dem dann auf einen Stick und vom Stick aus dann auf einem Klienten der am alten Router hängt, hier in den Browser ). Hoffe damit nichts falsch gemacht zu haben.

Code: Alles auswählen

# tcpdump -c 200 -vvveni eth0 net 192.168.3.0/24 > tcpdump.txt
[  597.867303] device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

Vorstehend die Meldungen die auf dem Routerbildschirm erscheinen nach Eingabe deines Kommandos.
Nachstehend die Meldungen die nur in die Datei gelangten:

Code: Alles auswählen

19:42:57.747881 00:1d:72:82:33:95 > 28:92:4a:40:19:db, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 56579, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.250: ICMP echo request, id 4646, seq 1, length 64
19:42:57.747964 28:92:4a:40:19:db > 00:1d:72:82:33:95, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 45021, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.3.250 > 192.168.100.151: ICMP echo reply, id 4646, seq 1, length 64
19:43:04.332507 00:1d:72:82:33:95 > 28:92:4a:40:19:db, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 30953, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4648, seq 1, length 64
19:43:05.349355 00:1d:72:82:33:95 > 28:92:4a:40:19:db, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 30973, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4648, seq 2, length 64

Diese Meldungen erschienen wieder am Bildschirm nach der Beendigung des Kommandos mit Strg+C

Code: Alles auswählen

^C4 packets captured
4 packets received by filter
0 packets dropped by kernel
[  638.843048] device eth0 left promiscuous mode

[mat6937]

Ich hab's ein wenig anders gemacht, weil ich nicht umgehen kann mit Meldungen die nach oben aus der Konsole laufen.

Code: Alles auswählen

    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4648, seq 1, length 64
19:43:05.349355 00:1d:72:82:33:95 > 28:92:4a:40:19:db, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 30973, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4648, seq 2, length 64

Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?

Teste jetzt auf dem Linux-Router mit dem eth1-Interface und einem andern Filter für tcpdump:

Code: Alles auswählen

tcpdump -c 20 -vvveni eth1 host 192.168.3.1

danach vom Client den Ping:

Code: Alles auswählen

ping -c 3 192.168.3.1

durchführen.

[fischig]

Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?

Na ja, ich wusste ja nicht, wie viele Meldungszeilen ausgegeben werden und wenn der (Konsolen/tty-)Bildschirm voll ist, verschwinden die ersten Meldungen am oberen Bildschirmrand und die neuen erscheinen in der unteren letzten Bildschirmzeile. Es sieht dann aus, als ob die Meldungen „nach oben aus der Konsole laufen“.

Ansonsten : Geduld

[mat6937]

Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?

Na ja, ich wusste ja nicht, wie viele Meldungszeilen ausgegeben werden ...

Naja, lt. dem "-c 200" beim tcpdump, maximal 203:

-c count
Exit after receiving count packets.

und lt. den "-c"s beim Ping, maximal 6 Meldungen (= 12 Zeilen).

[fischig]

Router:

Code: Alles auswählen

# tcpdump -c 20 -vvveni eth1 host 192.168.3.1 > tcpdump.txt
[  163.028537] device eth1 entered promiscuous mode
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes

20:39:43.123718 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:39:44.133258 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:39:45.158263 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:39:53.102325 44:fe:3b:e7:6c:ac > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 1, id 8378, offset 0, flags [none], proto IGMP (2), length 36, options (RA))
    192.168.3.1 > 224.0.0.1: igmp query v3
20:39:57.637626 44:fe:3b:e7:6c:ac > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    192.168.3.1 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 is_ex { }]
20:39:58.124878 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:39:59.173516 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:00.197523 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:13.124721 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:14.149798 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:15.174789 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:28.144829 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:28.201736 44:fe:3b:e7:6c:ac > 01:00:5e:00:00:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 1, id 8379, offset 0, flags [none], proto IGMP (2), length 36, options (RA))
    192.168.3.1 > 224.0.0.1: igmp query v3
20:40:29.190035 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:30.214078 44:fe:3b:e7:6c:ac > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.101 tell 192.168.3.1, length 46
20:40:35.011911 00:50:b6:11:5a:43 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.3.1 tell 192.168.3.250, length 28
20:40:35.012743 44:fe:3b:e7:6c:ac > 00:50:b6:11:5a:43, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 192.168.3.1 is-at 44:fe:3b:e7:6c:ac, length 46
20:40:35.012780 00:50:b6:11:5a:43 > 44:fe:3b:e7:6c:ac, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51979, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4639, seq 1, length 64
20:40:36.028821 00:50:b6:11:5a:43 > 44:fe:3b:e7:6c:ac, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51999, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4639, seq 2, length 64
20:40:36.550324 44:fe:3b:e7:6c:ac > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    192.168.3.1 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 239.255.255.250 is_ex { }]
    
20 packets captured
20 packets received by filter
0 packets dropped by kernel
[  217.297776] device eth1 left promiscuous mode   

Klient:
[code# ping -c 3 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.

--- 192.168.3.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 44ms][/code]

[mat6937]

Router:

Code: Alles auswählen

# tcpdump -c 20 -vvveni eth1 host 192.168.3.1 

20:40:35.012780 00:50:b6:11:5a:43 > 44:fe:3b:e7:6c:ac, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51979, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4639, seq 1, length 64
20:40:36.028821 00:50:b6:11:5a:43 > 44:fe:3b:e7:6c:ac, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 51999, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.100.151 > 192.168.3.1: ICMP echo request, id 4639, seq 2, length 64

Jetzt noch mit folgenden iptables-Regeln auf dem Linux-Router:

Code: Alles auswählen

iptables -I FORWARD 1 -o eth1 -i eth0 -s 192.168.3.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -I POSTROUTING 1 -o eth1 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o eth0 -j MASQUERADE

und nach dem Ping vom Client, folgende Ausgaben vom Linux-Router posten:

Code: Alles auswählen

iptables -nvx -L FORWARD
iptables -nvx -L POSTROUTING -t nat

[fischig]

Mir schwante schon die ganze Zeit, dass MSfree da womöglich falsch lag und iptables-Regeln eben doch für Routerbetrieb nötig seien!

Schau'n mer mal.

Aber bis heute nachmittag bin ich dann erst mal wieder Fliesenleger.

[MSfree]

Mir schwante schon die ganze Zeit, dass MSfree da womöglich falsch lag und iptables-Regeln eben doch für Routerbetrieb nötig seien!

Du hast mit iptables aus deiner Linuxkiste einen NAT-Router gemacht. NAT ist aber zu Kommunikation zwischen deinem Linuxrouter und dem Telekomrouter nicht nötig.

Für deine Geräte hinter dem Linuxrouter würde ich erstmal von den festen IPs weggehen. Die haben zwar nicht unmittelbar mit dem Problem zu tun, erschweren aber die Einrichtung generell. Setze auf dem Linuxrouter einen dnsmasq auf, der sich um DHCP für die Rechner hinter dem Linuxrouter kümmert. Dann stellst du alle Geräte in dem LAN hinter dem Linuxrouter ahf DHCP um, und wenn ich sage alle, dann meine ich alle. Die Rechner können danach viel einfacher über ihren Rechnernamen gefunden werden, die lassen sich viel einfacher merken als IP-Adressen. dnsmasq bringt einen DNS mit, der sich um die Namensauflösung (Übersetzgun von IP in Rechnernamen und umgekehrt kümmert).

Warum DHCP? Ganz einfach, DHCP vergibt nicht nur IP-Adressen an die Clients sondern auch die Defaultroute, die Netmask und auf Wunsch noch andere Informationen wie die IP-Adresse des Netzwerkzeitservers oder auch Windows-Domainservers etc, was du sonst bei jedem Client hinter dem Linuxrouter zu Fuß eintragen müßetest.

Dem Linuxrouter selbst gibts du allerdings zwei feste IP-Adressen, einmal die IP-Adresse für das Subnetz, mit dem du mit dem Telekomrouter verbunden bist und zum anderen die IP-Adresse für die Netzwerkkarte, die dein LAN hinter dem Linuxrouter aufspannt.

Das einzige was dann zu tun ist, du mußt eine statische Route im Telekomrouter eintragen, damit der weiß, wohin der die Antwortpakete schicken muß. Das geht irgendwo im Telekomrouter, möglicherweise nur im Expertenmodus. Die Definition dieser Router umfaßt das Subnetz, das hinterdem Linuxrouter aufgespannt ist und die IP-Adresse (Telekomrouterseite) des Linuxrouters.

Quasi statische IP-Adressen kannst du den Rechnern im LAN hinter dem Linuxrouter per Konfiguration in dnsmasq einrichten. Der Client macht dann zwar immer noch DHCP, bekommt aber vom DHCP-Server garantiert immer die selbe IP-Adresse zugewiesen. Wichtig ist eine absolut statische IP aber nur für Server, die per Portforwarding über den Telekomrouter aus dem Internet erreichbar sein sollen.

[mat6937]

... iptables-Regeln eben doch für Routerbetrieb nötig seien!

Naja, jetzt geht es erstmal, raus zu finden ob bzw. wie es geht. Wenn es dann mit iptables-Regeln funktioniert, kannst Du dir noch immer zeigen lassen, wie es ohne iptables-Regeln (d. h. mit Routing-Regeln und ohne S-NAT/FORWARD-Regeln) geht.

[fischig]

Ich bin drihin!!!

Irgendwann beiß' ich nochmal in den Rechner, weil dieses verfluchte nano nicht orizontal srollen kann und mcedit kein Klemmbrett außerhalb des mc hat!

Also nach Eingabe von

Code: Alles auswählen

iptables -I FORWARD 1 -o eth1 -i eth0 -s 192.168.3.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -I POSTROUTING 1 -o eth1 -j MASQUERADE
iptables -t nat -I POSTROUTING 2 -o eth0 -j MASQUERADE

konnte ich vom Klienten aus 192.168.3.1 anpingen, und auch via Browser das Debianforum erreichen.
Ich habe mir deine Kommandos in eine Textdatei kopiert. Dabei musste ich das erste Kommando der Länge wegen mit einem Backslash umbrechen, um es aus nano für den prompt herauskopieren zu können. Für mich war das eine Premiere und ich hoffe, das hat keine Fehler bewirkt.
Ich schreibe gerade auf dem Klienten.
Also doch iptables!?

Gehe ich recht in der Annahme, dass die zuletzt davor versuchten Kommandos keinen Erkenntnisgewinn brachten? Für mich waren die Ausgaben „böhmische Dörfer“, sprich ich habe 0 verstanden.

Hier die Meldungen für

Code: Alles auswählen

iptables -nvx -L FORWARD
iptables -nvx -L POSTROUTING -t nat

Den Ping am Klienten hatte ich vor diesen Kommandos beendet.

Code: Alles auswählen

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     all  --  eth0   eth1    192.168.3.0/24       0.0.0.0/0            ctstate NEW
      35     2940 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Code: Alles auswählen

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       1       84 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
       0        0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

dnsmasq werde ich wohl nicht auf dem Linux-Router als DHCP-Server einrichten. 1. Hätte ich dann zwei hier zuhause (dnsmasq auf dem Linux-Router und noch einen auf dem DSL-Router). Von zwei DHCP-Servern im Heimnetz wurde hier im DF immer abgeraten. Den auf dem DSL-Router will ich nicht abschalten, weil ich den für das Gäste-WLAN benötige.
2. komme ich bei meinen fünf bis sechs Klienten im Heimnetz ganz gut mit festen IPs zurecht.

[mat6937]

Gehe ich recht in der Annahme, dass die zuletzt davor versuchten Kommandos keinen Erkenntnisgewinn brachten?

Für mich waren die Tests mit tcpdump schon OK.

Hier die Meldungen für

Code: Alles auswählen

iptables -nvx -L FORWARD
iptables -nvx -L POSTROUTING -t nat

Den Ping am Klienten hatte ich vor diesen Kommandos beendet.

Code: Alles auswählen

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     all  --  eth0   eth1    192.168.3.0/24       0.0.0.0/0            ctstate NEW
      35     2940 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Code: Alles auswählen

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       1       84 MASQUERADE  all  --  *      eth1    0.0.0.0/0            0.0.0.0/0
       0        0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Lt. den Zählern der iptables-Regeln, sind 2 Regeln (bei denen 0 0 angezeigt werden) bis jetzt zumindest, nicht erforderlich:

Code: Alles auswählen

 0        0 ACCEPT     all  --  eth0   eth1    192.168.3.0/24       0.0.0.0/0            ctstate NEW

Code: Alles auswählen

 0        0 MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Kannst die zwei ja mal kommentieren und weiter testen.