6
IP Adressproblem
Ich habe zwei PCs an einer Steuerung.
Ebenso sind diese PCs über einen zweiten LAN-Port mit dem Internet verbunden (etwas verschachtelt, funktioniert aber zumindest).
Jetzt habe ich folgendes Problem:
Wenn ich entweder den Internetport am PC1 oder PC2 verbinde, fällt mit die jewelige andere Verbindung Richtung Steuerung runter (kein Ping mehr).
Die IP-Adressen sowohl der Steuerung als auch des WLAN-Routers liegen im gleichen Adressbereich.
Leider kann ich die IP-Adressen seitens der Steuerung und des WLAN-Routers nicht ändern (Kundenausrüstung, der will nichts ändern).
Kann ich über IP-Routen das Problem lösen? Wenn ja, wie genau?
Ebenso sind diese PCs über einen zweiten LAN-Port mit dem Internet verbunden (etwas verschachtelt, funktioniert aber zumindest).
Jetzt habe ich folgendes Problem:
Wenn ich entweder den Internetport am PC1 oder PC2 verbinde, fällt mit die jewelige andere Verbindung Richtung Steuerung runter (kein Ping mehr).
Die IP-Adressen sowohl der Steuerung als auch des WLAN-Routers liegen im gleichen Adressbereich.
Leider kann ich die IP-Adressen seitens der Steuerung und des WLAN-Routers nicht ändern (Kundenausrüstung, der will nichts ändern).
Kann ich über IP-Routen das Problem lösen? Wenn ja, wie genau?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 495471
Url: https://administrator.de/contentid/495471
Printed on: April 24, 2024 at 11:04 o'clock
6 Comments
Latest comment
Leider gibts du keinerlei Subnetzmasken an was hier aber zielführend wäre für eine sinnvolle Hilfestellung !! 
Auffällig ist deshalb das der Control Server und die beiden PCs 1 und 2 in 2 unterschiedlichen IP Netzen liegen wenn man mal einen klassischen 24 Bit Prefix bei 192.168er IP Adressen annimmt hier !
192.168.1.0 /24 und 192.168.0.0 /24 liegen ja NICHT in einem gemeinsamen IP Netz wenn man mal von einem 24er Prefix ausgeht. Sie wären bei 24 Bit also getrennt.
Das kann dann also niemals klappen. Oder nutzt du hier einen größeren CIDR Prefix mit 23 oder 22 Bit z.B. bei den 192er Adressen auf Control Server Seite ??
Knackpunkt sind aber deine beiden PCs. Wenn das ein Winblows als OS ist, dürfen die keine Gateway IPs auf der Control Server Seite definiert haben ! Es ist ja mal davon auszugehen das sie ein Default Gateway per DHCP auf der "anderen Seite" bekommen. Damit hätten sie dann aber 2 Default Gateways was so nicht supportet ist.
Winblows kann mit mehreren Gateway nicht umgehen bzw. dann greift die Bindungsreihenfolge der NICs um zu entscheiden welches das aktive ist !!
Sprich das Gateway was in der Bindungsreihenfolge der NICs vorne liegt gewinnt und das andere ist dann tot. Das könnte bei dir ein Grund dieses Verhaltens sein !
Siehe dazu auch das Routing Tutorial hier im Forum das dir alles zu dem Thema erklärt:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Du hast also 2 Baustellen:
Müssen diese PCs als Router zwingend sein ?
Generell ist es besser das mit 2 mal 30 Euro Router zu machen die eine Gateway Redundanz mit VRRP zum Control Server abbilden.
So hast du ein ausfallsicheres Design sofern Ausfallsicherheit überhaupt ein Kriterium für dich ist in diesem Design ?
Denn der Controlserver hat ja den Nachteil das du ihm ja nur entweder PC 1 oder PC 2 als Gateway nach draußen eintragen kannst. Niemals aber beide.
Das bedeutet dann das wenn der eingetragene Gateway PC mal ausfällt oder ausgeschaltet ist, der Control Server nirgendwo mehr rauskommt ohne das du manuell intervenierst und ihm das Gateway umprogrammierst.
Eine lästige und kaum managebare Geschichte die man in heutiger Netzwerk Infrastruktur auch niemals mehr so macht.
Auffällig ist deshalb das der Control Server und die beiden PCs 1 und 2 in 2 unterschiedlichen IP Netzen liegen wenn man mal einen klassischen 24 Bit Prefix bei 192.168er IP Adressen annimmt hier !
192.168.1.0 /24 und 192.168.0.0 /24 liegen ja NICHT in einem gemeinsamen IP Netz wenn man mal von einem 24er Prefix ausgeht. Sie wären bei 24 Bit also getrennt.
Das kann dann also niemals klappen. Oder nutzt du hier einen größeren CIDR Prefix mit 23 oder 22 Bit z.B. bei den 192er Adressen auf Control Server Seite ??
Knackpunkt sind aber deine beiden PCs. Wenn das ein Winblows als OS ist, dürfen die keine Gateway IPs auf der Control Server Seite definiert haben ! Es ist ja mal davon auszugehen das sie ein Default Gateway per DHCP auf der "anderen Seite" bekommen. Damit hätten sie dann aber 2 Default Gateways was so nicht supportet ist.
Winblows kann mit mehreren Gateway nicht umgehen bzw. dann greift die Bindungsreihenfolge der NICs um zu entscheiden welches das aktive ist !!
Sprich das Gateway was in der Bindungsreihenfolge der NICs vorne liegt gewinnt und das andere ist dann tot. Das könnte bei dir ein Grund dieses Verhaltens sein !
Siehe dazu auch das Routing Tutorial hier im Forum das dir alles zu dem Thema erklärt:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Du hast also 2 Baustellen:
- IP Adressierung der NICs zum Controll Server
- Keine Gateway IPs dort an den PCs !
Müssen diese PCs als Router zwingend sein ?
Generell ist es besser das mit 2 mal 30 Euro Router zu machen die eine Gateway Redundanz mit VRRP zum Control Server abbilden.
So hast du ein ausfallsicheres Design sofern Ausfallsicherheit überhaupt ein Kriterium für dich ist in diesem Design ?
Denn der Controlserver hat ja den Nachteil das du ihm ja nur entweder PC 1 oder PC 2 als Gateway nach draußen eintragen kannst. Niemals aber beide.
Das bedeutet dann das wenn der eingetragene Gateway PC mal ausfällt oder ausgeschaltet ist, der Control Server nirgendwo mehr rauskommt ohne das du manuell intervenierst und ihm das Gateway umprogrammierst.
Eine lästige und kaum managebare Geschichte die man in heutiger Netzwerk Infrastruktur auch niemals mehr so macht.
Ich bin kein Netzwerkexperte, daher ein paar "einfache" Kommentare.
Die Subnetzmasken sind jeweils 255.255.255.0.
Zum Control Server sind noch Routen eingetragen, damit sich beide kennen ... habe leider den "route add" Befehl nicht mehr parat, sind auf jedem Fall persistente Routen.
Auf den PC-Ports sind Richtung Control-Server keine Default-Gateways eingetragen.
Richtung INET schon, da über DHCP.
Die zwei Pcs haben jeweils eine Anwendung laufen. Diese Anwendung redet mit dem Control-Server. Ich haben den INET Zugang "lediglich" zum Fernzugriff auf TeamViewer. Ich brauche diesen halt parallel, was momentan nicht funktioniert.
Ich hoffe, damit mehr Licht ins dunkel gebracht zu haben.
Die Subnetzmasken sind jeweils 255.255.255.0.
Zum Control Server sind noch Routen eingetragen, damit sich beide kennen ... habe leider den "route add" Befehl nicht mehr parat, sind auf jedem Fall persistente Routen.
Auf den PC-Ports sind Richtung Control-Server keine Default-Gateways eingetragen.
Richtung INET schon, da über DHCP.
Die zwei Pcs haben jeweils eine Anwendung laufen. Diese Anwendung redet mit dem Control-Server. Ich haben den INET Zugang "lediglich" zum Fernzugriff auf TeamViewer. Ich brauche diesen halt parallel, was momentan nicht funktioniert.
Ich hoffe, damit mehr Licht ins dunkel gebracht zu haben.
Die Subnetzmasken sind jeweils 255.255.255.0.
Dann siehst du schon deinen Kardinalsfehler hoffentlich selber !! Wie oben schon vermutet...Control Server und die beiden PCs 1 und 2 sind in unterschiedlichen IP Netzen. 192.168.1.0 /24 und 192.168.0.0 /24 sind ja dann 2 verschiedene IP Netze und eine Connectivität dann vollkommen ausgeschlossen !
Wie sollte das also gehen. Bei einem /24er Prefix sind die ersten 3 Bytes der IP Adresse das Netzwerk.
Genau die sind unterschiedlich so das deine Control Server Ports NICHT im gleichen IP Netz liegen wie die NICs der PCs.
Das springt aber auch einem Nicht Netzwerker sofort ins Auge !
Das musst du korrigieren !
So sähe ein sauberes und korrektes IP Adressdesign aus:
Auch das .1.0er Netz darfst du nicht doppelt verwenden. Das verstösst gegen fundamentale IP Adressierungsregeln. IP Netze müssen einzigartig sein !
Sinnfreie Argumente des Kunden (Leider kann ich die IP-Adressen seitens der Steuerung und des WLAN-Routers nicht ändern (Kundenausrüstung, der will nichts ändern)) helfen da nichts wie du dir denken kannst.
Wäre er in diesem Punkt "beratungsresitent", dann musst du ein sehr aufwendiges 1:1 NAT (IP Adress Translation) Konzept auf dem davor liegenden Router umsetzen. Sowas ist immer schwer managebar, gerade wenn der Kunde es selber nicht durchschaut. Ob du dir das aufhalsen willst mit deinem Kentnissstand musst du natürlich selber entscheiden. Technisch machbar wäre es. Ob es sinnvoll ist ist deine Entscheidung oder die des Kunden. Der Weg eines sauberen IP Adressdesigns in dem Umfeld wäre sicher der intelligentere Weg.
Nebenbei:
Hier sieht man leider mal wieder was passiert wenn man in Firmenumgebungen diese dümmliche 192.168.er Allerwelts Consumer IP Adressierung kritiklos und ohne Nachdenken beibehält !
Siehe dazu auch hier.Auf den beiden PCs muss ebenso zwingend IPv4 Forwarding in der Registry aktiviert sein wenn der Control Server auch in den anderen Netzen erreichbar sein muss und/oder ins Internet muss (Updates etc.) ! (Siehe Tutorial oben !)
Ggf. solltest du dir da besser jemanden an die Hand nehmen der weiss was er da Netzwerk technisch macht ?!
1
Hallo,
außer den richtigen Ratschlägen von @aqui hättest du noch die Möglichkeit auf einem der beiden PC's eine VNC Server oder ähnliches zu installieren und vom anderen PC per VNC zugreifen, dann benötigst du nicht 2 Teamviewer Sessions.
brammer
außer den richtigen Ratschlägen von @aqui hättest du noch die Möglichkeit auf einem der beiden PC's eine VNC Server oder ähnliches zu installieren und vom anderen PC per VNC zugreifen, dann benötigst du nicht 2 Teamviewer Sessions.
brammer
Moin,
Der erste Fehler ist, daß der Control-Server und die PCs in verschiedenen Netzen sind, wenn man davon ausgeht, daß die üblichen /24-Masken verwendet werden. das sollte als erstes "klargezogen" werden.
Wenn Die kaskadierter Route NAT macht, und Eure PCs kein routing machen, sollte es kein Problem sein, daß so zu betreiben. Das einzige ist hat. daß die PCs 1 und 2 nciht auf den WLAN-Router zugreifen können.
Du könntest natürlich auch zum Control-Server hin Hostrouten in den PCs setzen und den Rest der 192.168.1.0/24-Adressen als statische Route in den PCs eintragen.
Das sind aber alles nur Krücken, das sinnvollste wäre natürlich einfach den Control-Server oder den WLAN-Router "richtig" zu konfigurieren.
lks
Der erste Fehler ist, daß der Control-Server und die PCs in verschiedenen Netzen sind, wenn man davon ausgeht, daß die üblichen /24-Masken verwendet werden. das sollte als erstes "klargezogen" werden.
Wenn Die kaskadierter Route NAT macht, und Eure PCs kein routing machen, sollte es kein Problem sein, daß so zu betreiben. Das einzige ist hat. daß die PCs 1 und 2 nciht auf den WLAN-Router zugreifen können.
Du könntest natürlich auch zum Control-Server hin Hostrouten in den PCs setzen und den Rest der 192.168.1.0/24-Adressen als statische Route in den PCs eintragen.
Das sind aber alles nur Krücken, das sinnvollste wäre natürlich einfach den Control-Server oder den WLAN-Router "richtig" zu konfigurieren.
lks
Stimmt, das sind die vielen weiteren Punkte in dem Design die leider etwas unklar sind.
Fraglich auch was der "Control Server" für Hardware ist und wie die 2 NICs dort arbeiten.
Wie gesagt: NAT oder kein NAT der Router Kaskade ? Und die Hostrouten sind auch eine Option.
Um das aber alles umfassend und zielführend beantworten zu können bräuchte man mehr Informationen zu dem Design und vor allem was das Ziel ist.
Auch ob dieser Kunde bei seinen stringenten und wenig hilfreichen Forderungen bleibt was das gesamte Netz Setup weiter aufbläht und schwerer managebar machen würde.
Ein sauberes IP Design wäre da, wie schon gesagt, der weitaus bessere Weg. Das alles und die Tatsache das der TO kein Netzwerker ist macht die gesamte Sache nicht gerade einfach von extern zu lösen.
Obwohl eine Lösung mit allen diesen Informationen und entsprechender Flexibilität des Kunden im Grunde eigentlich sehr einfach und schnell umsetzbar ist.
Fraglich auch was der "Control Server" für Hardware ist und wie die 2 NICs dort arbeiten.
- 2 NICs in 2 Netzen
- Gebündelt als LACP LAG (Teaming) in einem Netz
Wie gesagt: NAT oder kein NAT der Router Kaskade ? Und die Hostrouten sind auch eine Option.
Um das aber alles umfassend und zielführend beantworten zu können bräuchte man mehr Informationen zu dem Design und vor allem was das Ziel ist.
Auch ob dieser Kunde bei seinen stringenten und wenig hilfreichen Forderungen bleibt was das gesamte Netz Setup weiter aufbläht und schwerer managebar machen würde.
Ein sauberes IP Design wäre da, wie schon gesagt, der weitaus bessere Weg. Das alles und die Tatsache das der TO kein Netzwerker ist macht die gesamte Sache nicht gerade einfach von extern zu lösen.
Obwohl eine Lösung mit allen diesen Informationen und entsprechender Flexibilität des Kunden im Grunde eigentlich sehr einfach und schnell umsetzbar ist.
