Hallo Liste :) ich beschäftige mich seit geraumer Zeit an der Lösung eines "kleinen" LAN / Routing-Problems … jedoch ohne Erfolg :(( System : PC1 : Opensuse PC2 : Opensuse PC3 : Opensuse ( geplanter PC ) Laptop : Windows XP LAN Aufbau : Internet -> Speedport-Router -> PC1 = funktioniert Internet -> Speedport-Router -> PC2 = funktioniert Internet -> Speedport-Router -> PC2 -> Laptop/PC3 = funktioniert nicht PC1 und PC 2 sind direkt an den Speedport angeschlossen, NFS / SSH / CUPS-LAN laufen problemlos haben aber keine direktverbindung. PC 3 "soll" via PC 2 geroutet werden - wenn das läuft wird PC 2 mit squid usw aufgepeppt PC 3 = aktuell ein XP-Laptop, soll später mit einem Desktop ergänzt werden IP's : Speedport : 192.168.2.1 PC1: eth0 -> 192.168.2.11 /24 PC2 : eth0 -> 192.168.2.21 /27 (anschluss zum speedport ) eth1 -> 192.168.2.40 /27 ( routing zu PC3 später) eth2 -> 192.168.2.121 /27 ( routing zu Laptop ) PC3 : geplante IP : 192.168.2.44 Speedport "vergibt" via DHCP die IP's 100- 120 an Laptop wenn ich den Laptop direkt an den Speedport anbinde = verbindung klappt Laptop an PC 2 = keinerlei verbindung - nicht mal ping 192.168.2.121 geht - weder an eth 1, noch an der (richtigen) eth2 Da ich FTP / IRC auf Laptop / PC3 nicht benötige, kann ich meines Wissens auf masquerading verzichten = Routing "pur" da das ganze nicht klappen (möchte), vermute ich einen fehler in meiner Routing-Tabelle … aber ich finde ihn trotz intensivser suche nicht :( (Rounting via Yast eingestellt ) hier die ausgaben von PC 2 -> cpu2:~ # ifconfig eth0 Link encap:Ethernet Hardware Adresse 00:10:5A:F0:CA:C3 inet Adresse:192.168.2.21 Bcast:192.168.2.31 Maske:255.255.255.224 inet6 Adresse: fe80::210:5aff:fef0:cac3/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4330710 errors:2 dropped:0 overruns:0 frame:3 TX packets:3802816 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:2977275487 (2839.3 Mb) TX bytes:576559064 (549.8 Mb) Interrupt:19 Basisadresse:0x2f80 eth1 Link encap:Ethernet Hardware Adresse 00:50:04:32:51:BB inet Adresse:192.168.2.40 Bcast:192.168.2.63 Maske:255.255.255.224 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:16 Basisadresse:0xaf00 eth2 Link encap:Ethernet Hardware Adresse 00:13:8F:23:7D:91 inet Adresse:192.168.2.121 Bcast:192.168.2.127 Maske:255.255.255.224 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) lo Link encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:38819 errors:0 dropped:0 overruns:0 frame:0 TX packets:38819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:4321915 (4.1 Mb) TX bytes:4321915 (4.1 Mb) cpu2:~ # route -vne Kernel IP Routentabelle Ziel Router Genmask Flags MSS Fenster irtt Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0 192.168.2.32 0.0.0.0 255.255.255.224 U 0 0 0 eth1 192.168.2.44 192.168.2.40 255.255.255.255 UGH 0 0 0 eth1 192.168.2.96 192.168.2.121 255.255.255.224 UG 0 0 0 eth2 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 27/04/14 17:04, Marco Jäger wrote:
Hallo Liste :)
ich beschäftige mich seit geraumer Zeit an der Lösung eines "kleinen" LAN / Routing-Problems … jedoch ohne Erfolg :((
System : PC1 : Opensuse PC2 : Opensuse PC3 : Opensuse ( geplanter PC ) Laptop : Windows XP
LAN Aufbau :
Internet -> Speedport-Router -> PC1 = funktioniert Internet -> Speedport-Router -> PC2 = funktioniert Internet -> Speedport-Router -> PC2 -> Laptop/PC3 = funktioniert nicht
PC1 und PC 2 sind direkt an den Speedport angeschlossen, NFS / SSH / CUPS-LAN laufen problemlos haben aber keine direktverbindung.
PC 3 "soll" via PC 2 geroutet werden - wenn das läuft wird PC 2 mit squid usw aufgepeppt
PC 3 = aktuell ein XP-Laptop, soll später mit einem Desktop ergänzt werden
IP's : Speedport : 192.168.2.1
PC1: eth0 -> 192.168.2.11 /24
PC2 : eth0 -> 192.168.2.21 /27 (anschluss zum speedport ) eth1 -> 192.168.2.40 /27 ( routing zu PC3 später) eth2 -> 192.168.2.121 /27 ( routing zu Laptop )
PC3 : geplante IP : 192.168.2.44
Speedport "vergibt" via DHCP die IP's 100- 120 an Laptop
wenn ich den Laptop direkt an den Speedport anbinde = verbindung klappt Laptop an PC 2 = keinerlei verbindung - nicht mal ping 192.168.2.121 geht - weder an eth 1, noch an der (richtigen) eth2
Da ich FTP / IRC auf Laptop / PC3 nicht benötige, kann ich meines Wissens auf masquerading verzichten = Routing "pur"
da das ganze nicht klappen (möchte), vermute ich einen fehler in meiner Routing-Tabelle … aber ich finde ihn trotz intensivser suche nicht :(
(Rounting via Yast eingestellt )
hier die ausgaben von PC 2 ->
cpu2:~ # ifconfig eth0 Link encap:Ethernet Hardware Adresse 00:10:5A:F0:CA:C3 inet Adresse:192.168.2.21 Bcast:192.168.2.31 Maske:255.255.255.224 inet6 Adresse: fe80::210:5aff:fef0:cac3/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4330710 errors:2 dropped:0 overruns:0 frame:3 TX packets:3802816 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:2977275487 (2839.3 Mb) TX bytes:576559064 (549.8 Mb) Interrupt:19 Basisadresse:0x2f80
eth1 Link encap:Ethernet Hardware Adresse 00:50:04:32:51:BB inet Adresse:192.168.2.40 Bcast:192.168.2.63 Maske:255.255.255.224 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:16 Basisadresse:0xaf00
eth2 Link encap:Ethernet Hardware Adresse 00:13:8F:23:7D:91 inet Adresse:192.168.2.121 Bcast:192.168.2.127 Maske:255.255.255.224 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:38819 errors:0 dropped:0 overruns:0 frame:0 TX packets:38819 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:4321915 (4.1 Mb) TX bytes:4321915 (4.1 Mb)
cpu2:~ # route -vne Kernel IP Routentabelle Ziel Router Genmask Flags MSS Fenster irtt Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0 192.168.2.32 0.0.0.0 255.255.255.224 U 0 0 0 eth1 192.168.2.44 192.168.2.40 255.255.255.255 UGH 0 0 0 eth1 192.168.2.96 192.168.2.121 255.255.255.224 UG 0 0 0 eth2
Hallo Marco. Dir ist schon klar, dass Deine Subnetz-Aufteilung so nicht richtig Sinn macht. Der Speedport sieht _ein_ Netz 192.168.2.0/24, während die anderen Hosts in den Netzen 192.168.2.0/27, 192.168.2.32/27 bzw. 192.168.2.64/27 hängen. Entscheide Dich, in welchem der Subnetze der Speedport hängen soll. G, C* -- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Sonntag, 27. April 2014, 18:27:51 schrieb Carsten Neumann: [...]
Hallo Marco.
Dir ist schon klar, dass Deine Subnetz-Aufteilung so nicht richtig Sinn macht. Der Speedport sieht _ein_ Netz 192.168.2.0/24, während die anderen Hosts in den Netzen 192.168.2.0/27, 192.168.2.32/27 bzw. 192.168.2.64/27 hängen. Entscheide Dich, in welchem der Subnetze der Speedport hängen soll.
G, C*
Hallo was würdest du denn vorschlagen als alternative ? eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24 wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht … zumal : - sich PC3 & Laptop ja "sehen" sollen später ( stichwort Samba / NTFS ), bzw vermutlich, aber noch nicht sicher dort mehr "zusammenkommt" ( auch rein organisatorisch / Realer Platz ) -> ggf 2ter Laptop ( abwechselnd mit Laptop 1) und zu 60% ein weiteres Gerät - das aber von Haus aus NUR DHCP auf dem 192.168.2.x erkennt & akzeptiert - und 1 laptop bzw PC ( PC3 ) je ein subnet ? wäre doch mit ner SS 22 auf nen Spatz gefeuert *g* - dann bräuchte man subnets nur bis /24 … es wäre mir neu das folgende konstellation auch nur ansatzweise theoretisch klappen würde : eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 -> pc3 & ggf 192.168.2.50-55 ( extra gerät ) eth2 auf 192.168.4.21/24 -> laptops im subnet 192.168.2.100 - 120 und wozu gibt es routing wenn man damit nicht einen / mehrere PC's über einen anderen "weiterleiten" kann? Für ist es für mein Verständnis so : speedport "sieht" ja nicht ob nun eth[0-2] ein 24er , 27er oder 30er subnet ist … und ist ihm auch völlig egal das eingestellte subnet betrifft NUR den PC auf dem es entsprechend eingestellt ist … damit dieser PC weiss "ok verbindung zu 192.2.21 -> eth0, "verbindung zu 192.168.2.101 -> eth 2" und das geht soweit ich weiß nur mit entsprechender zuweisung … ich denke mal kaum das ein eth0 auf 192.168.2.21/24 eth1 auf 192.168.2.22/24 eth2 auf 192.168.2.23/24 sinn machen würde -> da wüsste PC 2 ja nicht welche verbindung nun in welche richtung führt (also zum speedport, zu PC 1, zu PC 3, zum Laptop, sonstwohin) Ping von PC 1 auf alle 3 !!!! eth adressen von PC 2 gehen … cpu1:~ # ping 192.168.2.21 PING 192.168.2.21 (192.168.2.21) 56(84) bytes of data. 64 bytes from 192.168.2.21: icmp_seq=1 ttl=64 time=0.212 ms 64 bytes from 192.168.2.21: icmp_seq=2 ttl=64 time=0.222 ms 64 bytes from 192.168.2.21: icmp_seq=3 ttl=64 time=0.199 ms ^C --- 192.168.2.21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.199/0.211/0.222/0.009 ms cpu1:~ # ping 192.168.2.121 PING 192.168.2.121 (192.168.2.121) 56(84) bytes of data. 64 bytes from 192.168.2.121: icmp_seq=1 ttl=64 time=0.318 ms 64 bytes from 192.168.2.121: icmp_seq=2 ttl=64 time=0.199 ms 64 bytes from 192.168.2.121: icmp_seq=3 ttl=64 time=0.202 ms 64 bytes from 192.168.2.121: icmp_seq=4 ttl=64 time=0.229 ms ^C --- 192.168.2.121 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.199/0.237/0.318/0.048 ms cpu1:~ # ping 192.168.2.40 PING 192.168.2.40 (192.168.2.40) 56(84) bytes of data. 64 bytes from 192.168.2.40: icmp_seq=1 ttl=64 time=0.277 ms 64 bytes from 192.168.2.40: icmp_seq=2 ttl=64 time=0.195 ms 64 bytes from 192.168.2.40: icmp_seq=3 ttl=64 time=0.232 ms 64 bytes from 192.168.2.40: icmp_seq=4 ttl=64 time=0.244 ms ^C --- 192.168.2.40 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.195/0.237/0.277/0.029 ms cpu1:~ # ( das zum thema das speedport spezielle einstellungen benötigt, da ja PC 1 und PC 2 nur via Speedport verbunden sind … … … ) was PC 1 "sieht" und ansprechen kann, kann meines wissens auch der Speedport - über den ja diese 2 Rechner verbunden sind P.S. : 192.168.2.64/27 wird nicht benötigt, bzw angesprochen 192.168.2.0/27 auf eth0 192.168.2.32/27 auf eth1 192.168.2.96/27 auf eth2 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo was würdest du denn vorschlagen als alternative ?
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24
wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht …
ich bin kein Spezialist und überlasse die finale Antwort den Profis, aber das hier kann nicht gehen denn die Rechner befinden sich dann in unterschiedlichen Subnetzen. Die sehen sich da gar nicht mehr. Ich meine beide Kommentare zielten lediglich darauf ab, dass Du die IP-Adressen wie gehabt lässt aber dieses eine 27 in ein 24 verwandelst. Hast Du das versucht? Hat es geklappt? Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 28/04/14 16:07, Marco Jäger wrote:
Am Sonntag, 27. April 2014, 18:27:51 schrieb Carsten Neumann:
[...]
Hallo Marco.
Dir ist schon klar, dass Deine Subnetz-Aufteilung so nicht richtig Sinn macht. Der Speedport sieht _ein_ Netz 192.168.2.0/24, während die anderen Hosts in den Netzen 192.168.2.0/27, 192.168.2.32/27 bzw. 192.168.2.64/27 hängen. Entscheide Dich, in welchem der Subnetze der Speedport hängen soll.
G, C*
Hallo was würdest du denn vorschlagen als alternative ?
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24
wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht …
Muss speedport überhaupt von 192.168.3.0/24 oder 192.168.4.0/24 Kenntnis haben? Das ist doch nur der WAN-Router, gell? Lediglich die Hosts in ihren jeweiligen Netzen müssen wissen, über welches Gateway sie gehen müssen, um in ein anderes Netz zu gelangen. Also die Hosts in 192.168.2.0/24 müssen für die Netze 192.168.3.0/24 und 192.168.4.0/24 das Gateway 192.168.2.22 eingetragen haben. Für die Hosts in den anderen Netzen gilt entsprechendes. Und das kannst Du ja auf den jeweiligen Hosts in ihren Routing-Regeln festlegen. Mich erinnert das an mein eigenes Setup, wobei ich allerdings nur zwei Netze habe: 192.168.2.0/24 mit Vodafone Easybox (mit Firewall & NAT) als WAN-Router (eth:192.168.2.1), hier liegt dann auch das WLAN mit drin. Das ist sozusagen mein "externes" lokales Netz. 192.168.1.0/24 mit einem openSUSE-PC als Router (ebenfalls mit Firewall und NAT) (eth0:192.168.2.100 und eth1:192.168.1.10). Das ist mein internes lokales Netz. Verbindungen vom WAN müssen dann zweimal mit Port-Fowarding weitergeleitet werden, weil sie durch zwei Brandmauern müssen. :-)
zumal :
- sich PC3 & Laptop ja "sehen" sollen später ( stichwort Samba / NTFS ), bzw vermutlich, aber noch nicht sicher dort mehr "zusammenkommt" ( auch rein organisatorisch / Realer Platz ) -> ggf 2ter Laptop ( abwechselnd mit Laptop 1) und zu 60% ein weiteres Gerät - das aber von Haus aus NUR DHCP auf dem 192.168.2.x erkennt & akzeptiert
- und 1 laptop bzw PC ( PC3 ) je ein subnet ? wäre doch mit ner SS 22 auf nen Spatz gefeuert *g* - dann bräuchte man subnets nur bis /24 …
es wäre mir neu das folgende konstellation auch nur ansatzweise theoretisch klappen würde :
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 -> pc3 & ggf 192.168.2.50-55 ( extra gerät )
eth2 auf 192.168.4.21/24 -> laptops im subnet 192.168.2.100 - 120
und wozu gibt es routing wenn man damit nicht einen / mehrere PC's über einen anderen "weiterleiten" kann?
Für ist es für mein Verständnis so : speedport "sieht" ja nicht ob nun eth[0-2] ein 24er , 27er oder 30er subnet ist … und ist ihm auch völlig egal das eingestellte subnet betrifft NUR den PC auf dem es entsprechend eingestellt ist … damit dieser PC weiss "ok verbindung zu 192.2.21 -> eth0, "verbindung zu 192.168.2.101 -> eth 2" und das geht soweit ich weiß nur mit entsprechender zuweisung … ich denke mal kaum das ein
eth0 auf 192.168.2.21/24 eth1 auf 192.168.2.22/24 eth2 auf 192.168.2.23/24
sinn machen würde -> da wüsste PC 2 ja nicht welche verbindung nun in welche richtung führt (also zum speedport, zu PC 1, zu PC 3, zum Laptop, sonstwohin)
Ping von PC 1 auf alle 3 !!!! eth adressen von PC 2 gehen …
cpu1:~ # ping 192.168.2.21 PING 192.168.2.21 (192.168.2.21) 56(84) bytes of data. 64 bytes from 192.168.2.21: icmp_seq=1 ttl=64 time=0.212 ms 64 bytes from 192.168.2.21: icmp_seq=2 ttl=64 time=0.222 ms 64 bytes from 192.168.2.21: icmp_seq=3 ttl=64 time=0.199 ms ^C --- 192.168.2.21 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.199/0.211/0.222/0.009 ms cpu1:~ # ping 192.168.2.121 PING 192.168.2.121 (192.168.2.121) 56(84) bytes of data. 64 bytes from 192.168.2.121: icmp_seq=1 ttl=64 time=0.318 ms 64 bytes from 192.168.2.121: icmp_seq=2 ttl=64 time=0.199 ms 64 bytes from 192.168.2.121: icmp_seq=3 ttl=64 time=0.202 ms 64 bytes from 192.168.2.121: icmp_seq=4 ttl=64 time=0.229 ms ^C --- 192.168.2.121 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.199/0.237/0.318/0.048 ms cpu1:~ # ping 192.168.2.40 PING 192.168.2.40 (192.168.2.40) 56(84) bytes of data. 64 bytes from 192.168.2.40: icmp_seq=1 ttl=64 time=0.277 ms 64 bytes from 192.168.2.40: icmp_seq=2 ttl=64 time=0.195 ms 64 bytes from 192.168.2.40: icmp_seq=3 ttl=64 time=0.232 ms 64 bytes from 192.168.2.40: icmp_seq=4 ttl=64 time=0.244 ms ^C --- 192.168.2.40 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.195/0.237/0.277/0.029 ms cpu1:~ #
( das zum thema das speedport spezielle einstellungen benötigt, da ja PC 1 und PC 2 nur via Speedport verbunden sind … … … ) was PC 1 "sieht" und ansprechen kann, kann meines wissens auch der Speedport - über den ja diese 2 Rechner verbunden sind
P.S. : 192.168.2.64/27 wird nicht benötigt, bzw angesprochen
192.168.2.0/27 auf eth0 192.168.2.32/27 auf eth1 192.168.2.96/27 auf eth2
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Montag, 28. April 2014, 16:57:28 schrieb Carsten Neumann: [...]
Muss speedport überhaupt von 192.168.3.0/24 oder 192.168.4.0/24 Kenntnis haben? Das ist doch nur der WAN-Router, gell? Lediglich die Hosts in ihren jeweiligen Netzen müssen wissen, über welches Gateway sie gehen müssen, um in ein anderes Netz zu gelangen. Also die Hosts in 192.168.2.0/24 müssen für die Netze 192.168.3.0/24 und 192.168.4.0/24 das Gateway 192.168.2.22 eingetragen haben. Für die Hosts in den anderen Netzen gilt entsprechendes. Und das kannst Du ja auf den jeweiligen Hosts in ihren Routing-Regeln festlegen.
Habe mal testweise eth2 nach 192.168.3.121 geändert … wie erwartet keine änderung des ganzen … der Fehler muss also woanders zu suchen sein … NAT ist soweit erforderlich eingerichtet, dhcrelay ist konfiguriert und eingerichtet - sogar ein testweise gestarteter DHCP server auf PC2 brachte nichts -> laptop bekommt keine info über seine ip …
On 28/04/14 23:45, Marco Jäger wrote:
Am Montag, 28. April 2014, 16:57:28 schrieb Carsten Neumann:
[...]
Muss speedport überhaupt von 192.168.3.0/24 oder 192.168.4.0/24 Kenntnis haben? Das ist doch nur der WAN-Router, gell? Lediglich die Hosts in ihren jeweiligen Netzen müssen wissen, über welches Gateway sie gehen müssen, um in ein anderes Netz zu gelangen. Also die Hosts in 192.168.2.0/24 müssen für die Netze 192.168.3.0/24 und 192.168.4.0/24 das Gateway 192.168.2.22 eingetragen haben. Für die Hosts in den anderen Netzen gilt entsprechendes. Und das kannst Du ja auf den jeweiligen Hosts in ihren Routing-Regeln festlegen.
Habe mal testweise eth2 nach 192.168.3.121 geändert … wie erwartet keine änderung des ganzen …
der Fehler muss also woanders zu suchen sein … NAT ist soweit erforderlich eingerichtet, dhcrelay ist konfiguriert und eingerichtet - sogar ein testweise gestarteter DHCP server auf PC2 brachte nichts -> laptop bekommt keine info über seine ip …
Wenn der Laptop noch nicht mal seine IP-Konfiguration von "seinem" DHCP-Server auf PC2 bekommt, hast Du irgendwas auf diesem falsch konfiguriert. Läuft der DHCP-Server auch auf der Schnittstelle, an der der Laptop hängt? Ich weiß jetzt nicht mehr, welche(n) Server das betrifft, aber beim DNS- und/oder DHCP-Server musst du die Interfaces angeben, auf denen er/sie laufen soll. Ist dieses Interface auch in der internen Zone, sind also alle Ports offen (Firewall)? Mein Setup läuft seit Jahren problemlos: DHCP-Server und DNS-Server laufen auf openSUSE-PC und versorgen mein internes Netzwerk. Sowas wie dhcp-relay oder dhcrelay habe ich noch nicht eingesetzt, weil der DHCP-Server auf der von mir verwendeten Easybox zu primitiv ist, um alle nötigen Informationen zu liefern. Ich verwende mein openSUSE-Gateway auch um Hosts per TFTP oder HTTP auch mit Bootimages - z.B. zur Installation - zu versorgen. Den DHCP-Server der Easybox, also dem WAN-Router, verwende ich nur, um die Geräte im externen Netz (192.168.2.0/24) mit IP-Konfigurationen zu versorgen. -- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Montag, 28. April 2014, 16:07:51 schrieb Marco Jäger:
Hallo was würdest du denn vorschlagen als alternative ?
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24
wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht …
zumal :
das obere szenario ist auch nicht allzu viel anderst als das szenario oben, macht für den speedport keinen unterschied, er kann damit nicht umgehen. Was genau willst Du mit dem beschriebenen routing erreichen, wenn sich alle Geräte sehen sollen und ins Internet gehen sollen? Zu den Problemen: DHCP läuft nicht automatisch über einen router. Der muss dafür konfiguiert sein, dass er die Pakete durchreicht, und der DHCP-Server muss das entsprechend behandeln können, dass er die richtigen Adressen ausliefert. Des weiteren hast du 2 Router in deinem Netzwerk, und damit mit diesen Komponenten ein Problem. Der Speedport kann keine manuellen routing-einträge, du kannst dem also nicht sagen, dass du in dem Netz einen weiteren Router hast, der in die Subnetze weiterleitet. Damit müsstest Du also NAT auf dem Linux-router machen. Damit sind die Rechner dahinter aber nicht mehr von den Rechnern vor dem Router aus erreichbar. Die einzige Alternative hier wäre, den Linux-Rechner als Default-router einzurichten, den Speedport in ein eigenes Netz, und der Linux Router macht NAT dorthin. Dann muss aber der Linux Router immer Laufen, wenn ein Rechner Internet braucht. In deinem Szenario wissen die Rechner vor dem Linux-router nichts von den Subnetzen dahinter, können also keine Pakete zurückschichen. Kann so also nicht funktionieren. Du könntest die Route fest in den Rechnern davor einrichten, aber der Speedport kann das nicht. gruß Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 28. April 2014, 17:52:09 schrieb Harald Stürmer:
Am Montag, 28. April 2014, 16:07:51 schrieb Marco Jäger:
Hallo was würdest du denn vorschlagen als alternative ?
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24
wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht …
zumal : das obere szenario ist auch nicht allzu viel anderst als das szenario oben, macht für den speedport keinen unterschied, er kann damit nicht umgehen.
Was genau willst Du mit dem beschriebenen routing erreichen, wenn sich alle Geräte sehen sollen und ins Internet gehen sollen?
Zu den Problemen: DHCP läuft nicht automatisch über einen router. Der muss dafür konfiguiert sein, dass er die Pakete durchreicht, und der DHCP-Server muss das entsprechend behandeln können, dass er die richtigen Adressen ausliefert.
dafür git es das nette Tool dhcprelay ;)
Des weiteren hast du 2 Router in deinem Netzwerk, und damit mit diesen Komponenten ein Problem. Der Speedport kann keine manuellen routing-einträge, du kannst dem also nicht sagen, dass du in dem Netz einen weiteren Router hast, der in die Subnetze weiterleitet. Damit müsstest Du also NAT auf dem Linux-router machen. Damit sind die Rechner dahinter aber nicht mehr von den Rechnern vor dem Router aus erreichbar. Die einzige Alternative hier wäre, den Linux-Rechner als Default-router einzurichten, den Speedport in ein eigenes Netz, und der Linux Router macht NAT dorthin. Dann muss aber der Linux Router immer Laufen, wenn ein Rechner Internet braucht.
NAT ist wegen obigem Programm eh eingerichtet - allerdings, da zb ftp usw nicht benötigt werden eher minimalistisch
In deinem Szenario wissen die Rechner vor dem Linux-router nichts von den Subnetzen dahinter, können also keine Pakete zurückschichen. Kann so also nicht funktionieren. Du könntest die Route fest in den Rechnern davor einrichten, aber der Speedport kann das nicht.
wenn dann kann ich die routings im PC 3 einrichten - da der Laptop in mehreren Netzen aktiv ist ( zuhause, büro, schule ) geht das bei diesem weniger -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Dienstag, 29. April 2014, 00:09:46 schrieb Marco Jäger:
wenn dann kann ich die routings im PC 3 einrichten - da der Laptop in mehreren Netzen aktiv ist ( zuhause, büro, schule ) geht das bei diesem weniger Wie gesagt, das wäre das Problem nicht, läßt sich über Profile oder Networkmanager konfigurieren. Der Punkt ist, alle betroffenen PCs brauchen in der Routing-list den PC 2 als Router in die entsprechenden Subnetze, um Pakete an den PC3 oder den Laptop zu senden. Auch der Speedport. Die PCs kannst Du entsprechend einrichten, sollte kein Problem sein. Beim Speedport geht das nicht. D.h. Du kommst dann ohne NAT von PC3 und Laptop aus nur über Proxy ins Internet, oder, mit NAT, von PC1 aus nicht auf PC3 und Laptop, aber umgekehrt würde gehen. Heißt: Freigaben des PC1 wären erreichbar, Freigaben des PC3 und Laptop jedoch nicht. Das Routing-problem lässt sich am einfachsten lösen, wenn Du das interne Routing über PC2 machen würdest, der macht dann auch DNS und DHCP, und über NAT wird an den PC2 der Speedport angeschlossen. Dann ist PC2 für alle Rechner der Default-Router, und für PC2 ist der Speedport der Default-Router und DNS- forward.
gruß Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Mon, 28 Apr 2014 17:52:09 +0200
schrieb Harald Stürmer
Zu den Problemen: DHCP läuft nicht automatisch über einen router. Der muss dafür konfiguiert sein, dass er die Pakete durchreicht, und der DHCP-Server muss das entsprechend behandeln können, dass er die richtigen Adressen ausliefert.
Außerdem benötigen Server und Client am Ende der Zuweisung (und für renewals auch danach) eine funktionierende IP-connectivity. Solange statisches routing nicht funktioniert wie hier, braucht man über DHCP gar nicht erst nachzudenken.
müsstest Du also NAT auf dem Linux-router machen. Damit sind die Rechner dahinter aber nicht mehr von den Rechnern vor dem Router aus erreichbar.
Naja, er könnte noch port-forwarding alias Dest-NAT machen. Vom public Internet aus würde das auf doppeltes port-forwarding hinauslaufen, wie Carsten schon illustrierte. Das ist dann irgendwie schon mindestens so kaputt, wie wenn man auf dem Router-PC eine bridge einrichten würde... Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 28/04/14 17:52, Harald Stürmer wrote:
Am Montag, 28. April 2014, 16:07:51 schrieb Marco Jäger:
Hallo was würdest du denn vorschlagen als alternative ?
eth0 auf 192.168.2.21/24 eth1 auf 192.168.3.21/24 eth2 auf 192.168.4.21/24
wäre in meinen Augen nicht besser -> speedport sieht eth 1 & 2 erst recht nicht …
zumal :
das obere szenario ist auch nicht allzu viel anderst als das szenario oben, macht für den speedport keinen unterschied, er kann damit nicht umgehen.
Was genau willst Du mit dem beschriebenen routing erreichen, wenn sich alle Geräte sehen sollen und ins Internet gehen sollen?
Zu den Problemen: DHCP läuft nicht automatisch über einen router. Der muss dafür konfiguiert sein, dass er die Pakete durchreicht, und der DHCP-Server muss das entsprechend behandeln können, dass er die richtigen Adressen ausliefert.
Des weiteren hast du 2 Router in deinem Netzwerk, und damit mit diesen Komponenten ein Problem. Der Speedport kann keine manuellen routing-einträge, du kannst dem also nicht sagen, dass du in dem Netz einen weiteren Router hast, der in die Subnetze weiterleitet. Damit müsstest Du also NAT auf dem Linux-router machen. Damit sind die Rechner dahinter aber nicht mehr von den Rechnern vor dem Router aus erreichbar. Die einzige Alternative hier wäre, den
Ich kann das z.Z. nicht prüfen, da ich gerade keinen direkten Zugriff auf mein Netzwerk habe. Aber ich meine mich zu erinnern, dass ich vom "externen" LAN durch den Linux-Router ohne NAT in das interne LAN gekommen bin. Das bedeutet, dass das Routing in benachbarte Netze _ohne_ NAT gemacht wird. Damit das funktioniert, muss das "externe" LAN zur internen Zone gehören und für das interne LAN der Linux-Router als Gateway in die "externen" Hosts eingetragen sein. Ich hoffe, das war jetzt auch für andere verständlich. :-) Also mit "externem" LAN meine ich das Netz, in dem sich der WAN-Router und der Linux-Router befinden, also 192.168.2.0/24. Das interne LAN ist das hinter dem Linux-Router. Mit "externen" Host sind die Rechner gemeint, die sich im "externen" LAN befinden. Vielleicht geht auch folgendes. Der DHCP-Server des WAN-Routers - Speedport. Easybox oder wer auch immer - wird ausgeschaltet. Der Linux-Router versorgt _alle_ Netze, also auch 192.168.2.0/24 mit DHCP und wählt für _seine_ Default-Route den Speedport. Die Hosts in _allen_ Netzen gehen dann über den Linux-Router als Gateway. Der Speedport bleibt in seinem Netz 192.168.2.0/24. Das wäre fast dieselbe Konfiguration wie von Harald weiter unten beschrieben, jedoch muss der Speedport nicht in ein eigenes Netz. Bei mir war übrigens die Motivation, das "externe" LAN zu nutzen, dass ich so das eingebaute WLAN meiner Easybox nutzen kann. So kann ich meinen RaspberryPi ohne störendes Netzwerkkabel quer durch's Wohnzimmer am Fernseher betreiben. :-)
Linux-Rechner als Default-router einzurichten, den Speedport in ein eigenes Netz, und der Linux Router macht NAT dorthin. Dann muss aber der Linux Router immer Laufen, wenn ein Rechner Internet braucht.
In deinem Szenario wissen die Rechner vor dem Linux-router nichts von den Subnetzen dahinter, können also keine Pakete zurückschichen. Kann so also nicht funktionieren. Du könntest die Route fest in den Rechnern davor einrichten, aber der Speedport kann das nicht.
gruß Harald
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Dienstag, 29. April 2014, 20:36:59 schrieb Carsten Neumann:
On 28/04/14 17:52, Harald Stürmer wrote:
Vielleicht geht auch folgendes. Der DHCP-Server des WAN-Routers - Speedport. Easybox oder wer auch immer - wird ausgeschaltet. Der Linux-Router versorgt _alle_ Netze, also auch
Ist wohl die beste Lösung.
192.168.2.0/24 mit DHCP und wählt für _seine_ Default-Route den Speedport. Die Hosts in _allen_ Netzen gehen dann über den Linux-Router als Gateway. Der Speedport bleibt in seinem Netz 192.168.2.0/24. Das ist das Problem. Der Speedport kann die Pakete nur zu den Hosts zurückschicken, wenn die in dem gleichen Netz sind wie er, oder mit NAT die Adresse umgeschrieben wurde, da man keine manuelle Route eintragen kann. D.h. er muss für NAT in einem eigenem Netz hängen. Alternativ böte sich höchstens die möglichkeit an, den Speedport mit z.B. openWRT zu versehen, dann ist da deutlich mehr möglich. Ist aber auch kein einfacher Weg, der im schlimmsten Fall den Speedport unbrauchbar macht. Da der PC1 im selben Netz hängt wie der Speedport, macht in dem Fall der Linux-router kein NAT für den. Es müsste aber funktionieren, wenn der PC manuell mit den Routen konfiguriert wird, d.h. routing in die Subnetze mit der Adresse vom Linux-router, und Default Gateway der Speedport. Dann bleibt an der Stelle nur das Problem, dass PC1 nicht auf die "internen" PCs zugreifen kann, sondern nur auf die antworten, da das NAT einen Verbindungsaufbau verhindert, wenn kein Port forwarding konfiguriert ist. Des weiteren müssen alle Clients im selben Subnetz die gleiche Netzmaske haben, alles andere führt zu Problemen, da die richtige Route nicht ermittelt werden kann.
Das wäre fast dieselbe Konfiguration wie von Harald weiter unten beschrieben, jedoch muss der Speedport nicht in ein eigenes Netz.
Bei mir war übrigens die Motivation, das "externe" LAN zu nutzen, dass ich so das eingebaute WLAN meiner Easybox nutzen kann. So kann ich meinen RaspberryPi ohne störendes Netzwerkkabel quer durch's Wohnzimmer am Fernseher betreiben. :-) Die Frage war an der Stelle mehr, wozu das interne Netz abtrennen willst in eigene Subnetze, wenn der Zugriff sowieso in alle Richtungen funktionieren soll. Oder habe ich da was übersehen? Proxy macht heutzutage nur noch Sinn, wenn Du den Zugang zu bestimmten Seiten oder zu bestimmten Zeiten beschränken willst.
gruß Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 29/04/14 23:42, Harald Stürmer wrote:
Am Dienstag, 29. April 2014, 20:36:59 schrieb Carsten Neumann:
On 28/04/14 17:52, Harald Stürmer wrote:
Vielleicht geht auch folgendes. Der DHCP-Server des WAN-Routers - Speedport. Easybox oder wer auch immer - wird ausgeschaltet. Der Linux-Router versorgt _alle_ Netze, also auch
Ist wohl die beste Lösung.
192.168.2.0/24 mit DHCP und wählt für _seine_ Default-Route den Speedport. Die Hosts in _allen_ Netzen gehen dann über den Linux-Router als Gateway. Der Speedport bleibt in seinem Netz 192.168.2.0/24. Das ist das Problem. Der Speedport kann die Pakete nur zu den Hosts zurückschicken, wenn die in dem gleichen Netz sind wie er, oder mit NAT die Adresse umgeschrieben wurde, da man keine manuelle Route eintragen kann. D.h. er muss für NAT in einem eigenem Netz hängen. Alternativ böte sich höchstens die möglichkeit an, den Speedport mit z.B. openWRT zu versehen, dann ist da deutlich mehr möglich. Ist aber auch kein einfacher Weg, der im schlimmsten Fall den Speedport unbrauchbar macht. Da der PC1 im selben Netz hängt wie der Speedport, macht in dem Fall der Linux-router kein NAT für den. Es müsste aber funktionieren, wenn der PC
Deswegen meinte ich, dass der Speedport seinen DHCP-Server abgeschaltet haben sollte. Dann kann der DHCP-Server des Linux-Routers sagen, das er als alleiniges Gateway zuständig ist. Dann macht der das NAT (das hatte ich vergessen, zu erwähnen) für _alle_ Netze und reicht sie an sein Default-Gateway, den Speedport, weiter. Wenn der Speedport kein WLAN hat, kann der natürlich alleine - neben dem Linux-Router - in seinem Netz hängen. Ansonsten spielt der Speedport WLAN<->Ethernet Bridge. Auf dem Linux-Router kann man dann auch noch einen Radius-Server unterbringen.
manuell mit den Routen konfiguriert wird, d.h. routing in die Subnetze mit der Adresse vom Linux-router, und Default Gateway der Speedport. Dann bleibt an der Stelle nur das Problem, dass PC1 nicht auf die "internen" PCs zugreifen kann, sondern nur auf die antworten, da das NAT einen Verbindungsaufbau verhindert, wenn kein Port forwarding konfiguriert ist. Des weiteren müssen alle Clients im selben Subnetz die gleiche Netzmaske haben, alles andere führt zu Problemen, da die richtige Route nicht ermittelt werden kann.
Das wäre fast dieselbe Konfiguration wie von Harald weiter unten beschrieben, jedoch muss der Speedport nicht in ein eigenes Netz.
Bei mir war übrigens die Motivation, das "externe" LAN zu nutzen, dass ich so das eingebaute WLAN meiner Easybox nutzen kann. So kann ich meinen RaspberryPi ohne störendes Netzwerkkabel quer durch's Wohnzimmer am Fernseher betreiben. :-) Die Frage war an der Stelle mehr, wozu das interne Netz abtrennen willst in eigene Subnetze, wenn der Zugriff sowieso in alle Richtungen funktionieren soll. Oder habe ich da was übersehen? Proxy macht heutzutage nur noch Sinn, wenn Du den Zugang zu bestimmten Seiten oder zu bestimmten Zeiten beschränken willst.
Nen Proxy habe ich nur für TOR und Squid halte ich auch vor, aber das ist 'ne andere Geschichte. :-) Das mit den unterschiedlichen Netzen ist bei mir evolutionär gewachsen. Eigentlich wollte ich mein internes Gigabit-Netzwerk vom äußeren langsameren mit WLAN aus Geschwindigkeits- und Sicherheitsgründen trennen und habe trotz WPA2 das externe auch in die external zone gelegt. Als ich begann immer mehr Geräte über WLAN anzubinden, die auch auf mein internes Netz Zugriff haben sollten, habe ich dann die Sicherheitsbedenken fallen gelassen und das externe Netz auch in die interne Zone verlagert. Es bleibt der Geschwindigkeitsaspekt: intern habe ich Gigabit und extern nur 100Mbit. Es ist klar für das vorgeschlagene Setup: der Linux-Router muss im Prinzip immer laufen.
gruß Harald
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Mittwoch, 30. April 2014, 02:38:25 schrieb Carsten Neumann:
Deswegen meinte ich, dass der Speedport seinen DHCP-Server abgeschaltet haben sollte. Dann kann der DHCP-Server des Linux-Routers sagen, das er als alleiniges Gateway zuständig ist. Dann macht der das NAT (das hatte ich vergessen, zu erwähnen) für _alle_ Netze und reicht sie an sein Default-Gateway, den Speedport, weiter.
Da bin ich mir jetzt nicht sicher, ob das so geht. NAT heißt ja im Endeffekt, eine private IP auf eine öffentliche umzuschreiben. Wenn die IP aus dem gleichen Adressraum kommt wie die öffentliche, wird die nicht umgeschrieben. Es würde auch die anderen genannten Probleme nicht lösen, sondern den Zugriff weiter erschweren. Beispiel: PC1 -- Router mit NAT -- PC3 ext. intern PC1 braucht die route in das Netz von PC3. Dann bin ich mir schon nicht sicher, ob der Router das nach innen durchroutet, aufgrund des aktiven NAT. Nehmen wir an, ja. PC3 sendet eine Antwort. Auf dem Router wird die Sourceadresse von PC3 umgeschrieben wegen NAT. PC1 erhält dann zwar die Antwort, kann die aber nicht zuordnen, weil die Sourceadresse nicht übereinstimmt. NAT dürfte, damit das Szenario funktionieren kann, nur in das Subnetz mit dem Router angeschaltet sein. Alle Hosts in dem selben Netz haben o.g. Problem mit dem NAT. Das betrifft dann auch die WLAN Clients des Speedports.
Wenn der Speedport kein WLAN hat, kann der natürlich alleine - neben dem Linux-Router - in seinem Netz hängen. Ansonsten spielt der Speedport WLAN<->Ethernet Bridge.
Auf dem Linux-Router kann man dann auch noch einen Radius-Server unterbringen.
Nen Proxy habe ich nur für TOR und Squid halte ich auch vor, aber das ist 'ne andere Geschichte. :-) Das mit den unterschiedlichen Netzen ist bei mir evolutionär gewachsen. Eigentlich wollte ich mein internes Gigabit-Netzwerk vom äußeren langsameren mit WLAN aus Geschwindigkeits- und Sicherheitsgründen trennen und habe trotz WPA2 das externe auch in die external zone gelegt. Als ich begann immer mehr Geräte über WLAN anzubinden, die auch auf mein internes Netz Zugriff haben sollten, habe ich dann die Sicherheitsbedenken fallen gelassen und das externe Netz auch in die interne Zone verlagert. Es bleibt der Geschwindigkeitsaspekt: intern habe ich Gigabit und extern nur 100Mbit.
Es ist klar für das vorgeschlagene Setup: der Linux-Router muss im Prinzip immer laufen.
Das genannte Setup bringt für Geschwindigkeit keinen Vorteil. An einem Switch wird jedes Device mit der Geschwindigkeit betrieben, die eben dieses Device kann. Gigbit Devices werden die Daten mit eben dieser Geschwindigkeit austauschen, und wenn von einenm Gigbit auf ein 100MBit device zugegriffen wird, dann läuft ›diese‹ Übertragung mit der langsameren Geschwindigkeit. Wenn das so nur aus den o.g. Gründen gemacht werden soll, solltest Du erwägen, diese Trennung aufzugeben, weil das geplante Setup weder für Sicherheit noch für die Performance etwas bringt. Es ist im Endeffekt "nur" eine zusäzliche Fehlerquelle. Den Radiusserver kannst Du ja trotz allem aufsetzen, und das sogar auf dem Pi, ist wesentlich zuträglicher für den Geldbeutel ;-) gruß Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 30/04/14 08:14, Harald Stürmer wrote:
Am Mittwoch, 30. April 2014, 02:38:25 schrieb Carsten Neumann:
Deswegen meinte ich, dass der Speedport seinen DHCP-Server abgeschaltet haben sollte. Dann kann der DHCP-Server des Linux-Routers sagen, das er als alleiniges Gateway zuständig ist. Dann macht der das NAT (das hatte ich vergessen, zu erwähnen) für _alle_ Netze und reicht sie an sein Default-Gateway, den Speedport, weiter.
Da bin ich mir jetzt nicht sicher, ob das so geht. NAT heißt ja im Endeffekt, eine private IP auf eine öffentliche umzuschreiben. Wenn die IP aus dem gleichen Adressraum kommt wie die öffentliche, wird die nicht umgeschrieben.
Was auch immer jetzt mit "Adressraum" gemeint ist. :-) Dass ich, wie ich schon in einer anderen Mail beschrieb, vom externen Netz in das interne ohne NATing trotz eingeschalteter NAT routen konnte, zeigt, dass in benachbarte Netze anscheinend keine Address-Translation erfolgt. Probier das doch einfach mal aus. Dann kannst Du Dir sicher sein, ob das so geht. :-) Das ganze lief mit - ich glaube - openSUSE 11.2 - noch mit iptables. Durch die Umstellung auf nftables in neueren Kernels haben sich möglicherweise irgendwelche Defaults geändert. Aber dazu kann ich jetzt auch nichts weiter sagen.
Es würde auch die anderen genannten Probleme nicht lösen, sondern den Zugriff weiter erschweren.
Beispiel: PC1 -- Router mit NAT -- PC3 ext. intern
Wie gesagt, das sind benachbarte Netze. Somit sollte das NATing nicht zuschlagen.
PC1 braucht die route in das Netz von PC3. Dann bin ich mir schon nicht sicher, ob der Router das nach innen durchroutet, aufgrund des aktiven NAT. Nehmen wir an, ja. PC3 sendet eine Antwort. Auf dem Router wird die Sourceadresse von PC3 umgeschrieben wegen NAT. PC1 erhält dann zwar die Antwort, kann die aber nicht zuordnen, weil die Sourceadresse nicht übereinstimmt.
NAT dürfte, damit das Szenario funktionieren kann, nur in das Subnetz mit dem Router angeschaltet sein. Alle Hosts in dem selben Netz haben o.g. Problem mit dem NAT. Das betrifft dann auch die WLAN Clients des Speedports.
Wenn der Speedport kein WLAN hat, kann der natürlich alleine - neben dem Linux-Router - in seinem Netz hängen. Ansonsten spielt der Speedport WLAN<->Ethernet Bridge.
Auf dem Linux-Router kann man dann auch noch einen Radius-Server unterbringen.
Nen Proxy habe ich nur für TOR und Squid halte ich auch vor, aber das ist 'ne andere Geschichte. :-) Das mit den unterschiedlichen Netzen ist bei mir evolutionär gewachsen. Eigentlich wollte ich mein internes Gigabit-Netzwerk vom äußeren langsameren mit WLAN aus Geschwindigkeits- und Sicherheitsgründen trennen und habe trotz WPA2 das externe auch in die external zone gelegt. Als ich begann immer mehr Geräte über WLAN anzubinden, die auch auf mein internes Netz Zugriff haben sollten, habe ich dann die Sicherheitsbedenken fallen gelassen und das externe Netz auch in die interne Zone verlagert. Es bleibt der Geschwindigkeitsaspekt: intern habe ich Gigabit und extern nur 100Mbit.
Es ist klar für das vorgeschlagene Setup: der Linux-Router muss im Prinzip immer laufen.
Das genannte Setup bringt für Geschwindigkeit keinen Vorteil. An einem Switch
Doch, selbstverständlich! Es handelt sich um physikalisch völlig getrennte Netze. Wenn ich das interne (Gigabit) Interface mit Kopieraktionen voll auslaste, geht mir von der Performance am externen (100Mbit) nix verloren.
wird jedes Device mit der Geschwindigkeit betrieben, die eben dieses Device kann. Gigbit Devices werden die Daten mit eben dieser Geschwindigkeit austauschen, und wenn von einenm Gigbit auf ein 100MBit device zugegriffen wird, dann läuft ›diese‹ Übertragung mit der langsameren Geschwindigkeit. Wenn das so nur aus den o.g. Gründen gemacht werden soll, solltest Du erwägen, diese Trennung aufzugeben, weil das geplante Setup weder für Sicherheit noch für die Performance etwas bringt. Es ist im Endeffekt "nur" eine zusäzliche Fehlerquelle. Den Radiusserver kannst Du ja trotz allem aufsetzen, und das sogar auf dem Pi, ist wesentlich zuträglicher für den Geldbeutel ;-)
gruß Harald
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Da bin ich mir jetzt nicht sicher, ob das so geht. NAT heißt ja im Endeffekt, eine private IP auf eine öffentliche umzuschreiben. Wenn die IP aus dem gleichen Adressraum kommt wie die öffentliche, wird die nicht umgeschrieben. Was auch immer jetzt mit "Adressraum" gemeint ist. :-)
Hier war das selbe Netzwerk gemeint.
Das genannte Setup bringt für Geschwindigkeit keinen Vorteil. An einem Switch Doch, selbstverständlich! Es handelt sich um physikalisch völlig getrennte Netze. Wenn ich das interne (Gigabit) Interface mit Kopieraktionen voll auslaste, geht mir von der Performance am externen (100Mbit) nix verloren. Wenn Du derart hohe Lasten an dem Linuxrechner fährst und die Hardware das hergibt, mag es vielleicht etwas bringen. Ich würde dann aber eher die 2 oder 3 Netzwerkkarten in dem Rechner bonden und wieder nur ein Netz machen. Ist einfacher in der Konfiguration, weniger fehleranfällig und hat als Nebeneffekt auch noch Redundanz statt single point of failure.
gruß Harald -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 30/04/14 16:41, Harald Stürmer wrote:
Da bin ich mir jetzt nicht sicher, ob das so geht. NAT heißt ja im Endeffekt, eine private IP auf eine öffentliche umzuschreiben. Wenn die IP aus dem gleichen Adressraum kommt wie die öffentliche, wird die nicht umgeschrieben. Was auch immer jetzt mit "Adressraum" gemeint ist. :-)
Hier war das selbe Netzwerk gemeint.
Das genannte Setup bringt für Geschwindigkeit keinen Vorteil. An einem Switch Doch, selbstverständlich! Es handelt sich um physikalisch völlig getrennte Netze. Wenn ich das interne (Gigabit) Interface mit Kopieraktionen voll auslaste, geht mir von der Performance am externen (100Mbit) nix verloren. Wenn Du derart hohe Lasten an dem Linuxrechner fährst und die Hardware das hergibt, mag es vielleicht etwas bringen. Ich würde dann aber eher die 2 oder 3 Netzwerkkarten in dem Rechner bonden und wieder nur ein Netz machen. Ist einfacher in der Konfiguration, weniger fehleranfällig und hat als Nebeneffekt auch noch Redundanz statt single point of failure.
Gigabit und 100Mbit Karte bonden, wobei eine zum Switch geht und die andere zur Easybox! Alles Klar!!! Sonst noch sinnlosere Vorschläge? Einfachere Konfiguration? Ähem.... ;-) G, C*
gruß Harald
-- "Seit die Mathematiker über die Relativitätstheorie hergefallen sind, verstehe ich sie selbst nicht mehr." (“Since the mathematicians have invaded the theory of relativity I do not understand it myself any more.”) - Albert Einstein
Am Wed, 30 Apr 2014 08:14:38 +0200
schrieb Harald Stürmer
Beispiel: PC1 -- Router mit NAT -- PC3 ext. intern
PC1 braucht die route in das Netz von PC3. Dann bin ich mir schon nicht sicher, ob der Router das nach innen durchroutet, aufgrund des aktiven NAT. Nehmen wir an, ja. PC3 sendet eine Antwort. Auf dem Router wird die Sourceadresse von PC3 umgeschrieben wegen NAT. PC1 erhält dann zwar die Antwort, kann die aber nicht zuordnen, weil die Sourceadresse nicht übereinstimmt.
Unpraktisch ist, dass alle PC im Netz wie PC1 eine separate Route ins PC3-LAN brauchen. Flexibler ist dagegen, wenn man auf dem Router-PC port-forwarding macht, weil dann muss nur der Router-PC erreichbar sein und das ist er für PC1 immer direkt. Man kann das auch für alle Ports erreichen, wenn man ein IP-alias auf dem Router-PC (ext. Seite) anlegt und alle Pakete an diese Adresse an PC3 weiterleitet. Wenn dieses IP-Alias auch für ausgehende Pakete von PC3 als Source-IP verwendet wird, dann erscheint PC3 wie ein Host im "ext."-Netz. Wenn man PC1 eine Route nach PC3 via Router-PC beibringt, dann wird das Paket ankommen, aber ohne gefiltertes NAT wird ein Paket von PC3 nach PC1 mit der ext. Adresse vom Router-PC ankommen. Das kann akzeptabel sein, kann bei Applikationen mit potentiell beidseitigem Verbindungsaufbau aber auch Chaos verursachen. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Sun, 27 Apr 2014 17:04:34 +0200
schrieb Marco Jäger
Internet -> Speedport-Router -> PC2 -> Laptop/PC3 = funktioniert nicht
Wenn PC2 kein NAT alias IP-masquerading macht, dann muss dem Speedport eine Route zum Laptop-Netz via PC2 eingetragen werden. Und: Bitte lass das Rumgewürge mit /27-Subnetzen. Alle an Speedport angeschlossenen Hosts bekommen Adressen aus 192.168.2.0/24 und das neue Laptop-Netz bekommt z.B. 192.168.3.0/24. Theoretisch funktioniert es zwar auch mit einer /27-Route via PC2, aber nur, wenn die routing-engine spezifischere Netzadressen mit /27 denen mit /24 im selben Netz vorzieht. Sonstige Kommunikation vom Laptop zu etwaigen anderen Hosts im 192.168.2.0/24 würde auf keine Fall funktionieren, weil denen die spezifischere Route fehlt und sie den Laptop als direkt erreichbar erwarten würden. Gruß, Tobias. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (5)
-
Carsten Neumann -
Harald Stürmer -
Karl Sinn -
Marco Jäger -
Tobias Crefeld