Telekom-DSL-Router, Netzwerkeinstellungen
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Gleiches Spiel wie oben mit dem letzten „route add ...“: Netzwerk nich erreichbar.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Versuch mal für den host (d. h. für eine IP-Adresse statt dem Subnetz):fischic hat geschrieben:14.04.2021 20:43:08Gleiches Spiel wie oben mit dem letzten „route add ...“: Netzwerk nich erreichbar.
Code: Alles auswählen
route add -host 192.168.3.1 gw 192.168.3.250 dev eth0
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.
edit:
wieder Netzwerk nicht erreichbar.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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 ...
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Ja.Machst Du _vor_ dem Eintrag der route, auch den Ping zur IP-Adresse 192.168.3.250?
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!
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Teste mal auf dem Linux-Router auch mit:fischic hat geschrieben:14.04.2021 23:13:08Es 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.
Code: Alles auswählen
sysctl -w net.ipv4.conf.eth0.rp_filter=1
sysctl -w net.ipv4.conf.eth1.rp_filter=1
Code: Alles auswählen
ping -c 3 192.168.3.250
Re: Telekom-DSL-Router, Netzwerkeinstellungen
So, durchgeführt. Auf dem Linux-Router meine ich nur zu erkennen, dass er die beiden Kommandos ausgeführt hat. Meldung: eth1 entsprechend.
Ping vom Klienten aus auf 192.168.3.250 funktioniert - aber das tat er doch auch vorher schon.
Code: Alles auswählen
net.ipv4.conf.eth0.rp_filter=1
Ping vom Klienten aus auf 192.168.3.250 funktioniert - aber das tat er doch auch vorher schon.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
OK, dann starte auf dem Linux-Router:fischic hat geschrieben:15.04.2021 15:29:32So, durchgeführt. Auf dem Linux-Router meine ich nur zu erkennen, dass er die beiden Kommandos ausgeführt hat. Meldung:eth1 entsprechend.Code: Alles auswählen
net.ipv4.conf.eth0.rp_filter=1
Ping vom Klienten aus auf 192.168.3.250 funktioniert - aber das tat er doch auch vorher schon.
Code: Alles auswählen
tcpdump -c 200 -vvveni eth0 net 192.168.3.0/24
Code: Alles auswählen
ping -c 1 192.168.3.250
ping -c 2 192.168.3.1
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.
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.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.
Vorstehend die Meldungen die auf dem Routerbildschirm erscheinen nach Eingabe deines Kommandos.
Nachstehend die Meldungen die nur in die Datei gelangten:
Diese Meldungen erschienen wieder am Bildschirm nach der Beendigung des Kommandos mit Strg+C
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
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
Code: Alles auswählen
^C4 packets captured
4 packets received by filter
0 packets dropped by kernel
[ 638.843048] device eth0 left promiscuous mode
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?fischic hat geschrieben:15.04.2021 19:41:41Ich 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
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
Code: Alles auswählen
ping -c 3 192.168.3.1
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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“.Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?
Ansonsten : Geduld
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Naja, lt. dem "-c 200" beim tcpdump, maximal 203:fischic hat geschrieben:15.04.2021 20:07:29Na ja, ich wusste ja nicht, wie viele Meldungszeilen ausgegeben werden ...Was genau meinst Du mit "Meldungen die nach oben aus der Konsole laufen"?
und lt. den "-c"s beim Ping, maximal 6 Meldungen (= 12 Zeilen).-c count
Exit after receiving count packets.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Router:
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]
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
[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]
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Jetzt noch mit folgenden iptables-Regeln auf dem Linux-Router:fischic hat geschrieben:15.04.2021 20:37:44Router: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
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
Code: Alles auswählen
iptables -nvx -L FORWARD
iptables -nvx -L POSTROUTING -t nat
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.
Schau'n mer mal.
Aber bis heute nachmittag bin ich dann erst mal wieder Fliesenleger.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.fischic hat geschrieben:16.04.2021 08:31:41Mir schwante schon die ganze Zeit, dass MSfree da womöglich falsch lag und iptables-Regeln eben doch für Routerbetrieb nötig seien!
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.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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.fischic hat geschrieben:16.04.2021 08:31:41... iptables-Regeln eben doch für Routerbetrieb nötig seien!
Re: Telekom-DSL-Router, Netzwerkeinstellungen
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
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
Den Ping am Klienten hatte ich vor diesen Kommandos beendet.
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.
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
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
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
2. komme ich bei meinen fünf bis sechs Klienten im Heimnetz ganz gut mit festen IPs zurecht.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Für mich waren die Tests mit tcpdump schon OK.fischic hat geschrieben:16.04.2021 19:14:26Gehe ich recht in der Annahme, dass die zuletzt davor versuchten Kommandos keinen Erkenntnisgewinn brachten?
Lt. den Zählern der iptables-Regeln, sind 2 Regeln (bei denen 0 0 angezeigt werden) bis jetzt zumindest, nicht erforderlich:fischic hat geschrieben:16.04.2021 19:14:26Hier die Meldungen fürDen Ping am Klienten hatte ich vor diesen Kommandos beendet.Code: Alles auswählen
iptables -nvx -L FORWARD iptables -nvx -L POSTROUTING -t nat
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
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
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Mach ich glatt!
Erst mal ein goßes Dankeschön für deine große Geduld und deine Hilfe!
Erst mal ein goßes Dankeschön für deine große Geduld und deine Hilfe!
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Zwei DHCP-Server sind in diesem Fall sogar notwendig.fischic hat geschrieben:16.04.2021 19:14:261. Hätte ich dann zwei hier zuhause (dnsmasq auf dem Linux-Router und noch einen auf dem DSL-Router).
Jein. Ein DHCP-Server pro Subnetz ist überhaupt keine Problem. Wenn du 5 Subnetze betriebst, brauchst du sogar 5 DHCP-Server. Wenn alle 5 Subnetze vom selben Router ausgehen, kann in diesem Sonderfall auch ein einzelner DHCP-Server alle Subnetze versorgen. Du hast aber zwei Router kaskadiert, folglich brauchst du auch zwei DHCP-Server, auf jedem Router einen.Von zwei DHCP-Servern im Heimnetz wurde hier im DF immer abgeraten.
Von was hier im DF immer abgeraten wird ist, zwei DHCP-Server im selben Subnetz zu betreiben. Das geht auf jeden Fall schief. Auch zwei Subnetze auf dem selben Kabel zu betreiben, läßt sich nicht sauber mit DHCP lösen.
Gäste-WLAN = anderes Subnetz.Den auf dem DSL-Router will ich nicht abschalten, weil ich den für das Gäste-WLAN benötige
Ein DHCP-Server lohnt sich bereits für nur einen einziegen Client.2. komme ich bei meinen fünf bis sechs Klienten im Heimnetz ganz gut mit festen IPs zurecht.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Danke für die Klarstellung!
Offtopic:
Ist so'n bisschen wie mit grub: jeder nutzt ihn aber keiner braucht ihn wirklich. Sagt man was Abweichendes, kommt das Totschlagargument: „veraltet“.
Offtopic:
Zugegeben, händische IP-Verwaltung ist etwas aufwendiger zu pflegen. Aber DHCP für ein im Prinzip statisches kleines Heimnetz hat mir nie eingeleuchtet und leuchtet mir auch jetzt nicht ein. Bei meinen Nachforschungen konnte ich mich nie des Eindrucks erwehren: Jeder macht's, weil's halt da ist. Vorteile, die mich beeindruckt hätten, sind mir nie aufgefallen. Etwas anderes ist es natürlich schon, wenn man sich mobil in unterschiedlichen Netzen bewegt. Da wird dann - weil da DHCP-Server werkeln - gar nichts anderes übrig bleiben. Uns so ist der WoMo-Klapprechner auch konfiguriert: zu Hause hat der eine feste IP und unterwegs bezieht er sie halt via DHCP - ganz ohne wicd, Netzwerkmanager, etc. Hat hier immer problemlos funktioniert.Ein DHCP-Server lohnt sich bereits für nur einen einzigen Client.
Ist so'n bisschen wie mit grub: jeder nutzt ihn aber keiner braucht ihn wirklich. Sagt man was Abweichendes, kommt das Totschlagargument: „veraltet“.
Zuletzt geändert von fischig am 16.04.2021 20:46:33, insgesamt 1-mal geändert.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Ich vermute mal, man braucht deshalb iptables (NAT), da der Telekom-router keine "fremden Netze" weiterroutet,
sondern nur solche aus seinem "client-netz".
Reine Vermutung von mir.
sondern nur solche aus seinem "client-netz".
Reine Vermutung von mir.
Re: Telekom-DSL-Router, Netzwerkeinstellungen
Aber eine ziemlich plausible, finde ich! Mal schauen, ob jemand Besseres oder Genaueres weiß.Ich vermute mal, man braucht deshalb iptables (NAT), da der Telekom-router keine "fremden Netze" weiterroutet,
sondern nur solche aus seinem "client-netz".
Reine Vermutung von mir.