Ergebnis 1 bis 8 von 8

Thema: Routing über zweite Netzwerkkarte

  1. #1

    Routing über zweite Netzwerkkarte

    Moin,
    ich stehe hier auf der Arbeit gerade vor einer Problematik.
    Hoffe es gibt hier ein paar Experten.

    Folgendes Problem:

    Ein Win7-Client hat zwei Netzwerkkarten. Über LAN1 soll er sich ins Hausnetz einwählen, über LAN2 in ein privates Netz.
    LAN 1 hat eine IP aus dem Hausnetz und als Gateway halt den Router des Hausnetzes, funktioniert auch super.
    In LAN 2 allerdings befindet sich kein Router, zu dem man weiterrouten könnte, sondern nur die einzelnen Clients. Die Karte hat ansonsten die IP 172.16.1.160/24 und kein Gateway.
    route add 172.16.1.0 mask 255.255.255.0 172.16.1.160 -p
    Das wurde von meinem Kollegen als Route eingetragen, macht aber lt. meiner Logik wenig Sinn, da die Route ja einfach nur auf die zweite Netzwerkkarte verweist und die keine Ahnung hat, was sie damit anfangen soll. Funktionieren tut es jedenfalls so nicht.
    Denke ich da richtig? Und wenn ja, wie müsste ich weiter vorgehen?

    Geändert von Eisbaer (01.06.2016 um 12:35 Uhr)

  2. #2
    Im Grunde ist es nicht falsch, seine eigene Adresse als Gateway zu nehmen, wenn kein Router oder so in Benutzung ist.
    Das Problem liegt eventuell darin, dass die Pakete garnicht wissen, über welche Karte sie raus sollen.
    Sind die anderen Rechner, aus dem 172.16.1.0/24 ebenfalls so konfiguriert, dass sie selbst das Gateway sind?
    Aber damit habe ich bislang ebenfalls keine Erfahrung, da wir alles über Routing/Switching realisieren^^

    EDIT: Das hier könnte dir helfen Klick!

    Geändert von Dizzy (01.06.2016 um 12:49 Uhr)

  3. #3
    Eventuell hast du mich gerade schon etwas weitergebracht, da ich vermute, dass auf den Clients gar nicht der Router-PC als Gateway eingetragen ist, da ja bisher überhaupt kein Router existierte, also auch kein Gateway. Da warte ich gerade noch auf Rückruf.

    Und ja, mein Gedanke ist, dass jetzt alle Pakete zur zweiten Netzwerkkarte eilen und dann dort stehen und sich fragen, was sie dort sollen, denn sie werden ja gar nicht weitergeleitet an den entsprechenden Client. Als würde man einem Passanten bei der Wegbeschreibung einfach nur sagen, dort drüben ist der Bahnhof, aber nicht welcher Zug.

    Achja, beide Netze sollen übrigens nix miteinander zu tun haben, bzw. nur einseitig aus dem Hausnetz ins private Netz und nicht umgekehrt.

    Geändert von Eisbaer (01.06.2016 um 13:04 Uhr)

  4. #4
    Nachtrag: Meine Vermutung ist jetzt, dass die Clients im privaten Netzwerk schlichtweg nicht wissen, wem sie antworten sollen, da sie kein Gateway eingetragen haben und damit Anfragen aus dem Hausnetz zwar vom Router erhalten, aber nicht beantworten können.

  5. #5
    Eigentlich steht ja in so einem Paket sowohl Source als auch Destination drin. Und die direkte Antwort geht eig immer an die Source zurück, über denselben Weg der Anfrage.

  6. #6
    Zitat Zitat von Dizzy Beitrag anzeigen
    Eigentlich steht ja in so einem Paket sowohl Source als auch Destination drin. Und die direkte Antwort geht eig immer an die Source zurück, über denselben Weg der Anfrage.
    So wie ich das - auch aus deinem Link - verstanden habe, müsste die ICMP-Antwort, also bei nem simplen Ping, aber abschmieren, weil der Client zwar weiß, dass er von IP X etwas beantworten soll, aber diese IP aus dem Fremdnetz gar nicht kennt. Der natürliche Weg wäre dann, beim Gateway nachzufragen, aber das gibt es ja nicht, also wirds verworfen. Dafür sind ja Router da. Käme mir jetzt als Lösung aber auch zu einfach vor, da einfach die Netzwerkbrücke als Gateway einzutragen. Stand jetzt ist, dass man zwar aus dem Hausnetz auf die Brücke kommt, aber von dort nicht weiter. Die zweite Netzwerkkarte lässt sich nicht einmal anpingen. Leider hatte ich noch keine Möglichkeit, da Sachen auszuprobieren und ich werde den Kunden da morgen nochmal über die Konfiguration genauer ausquetschen.

  7. #7
    Das ist ein interessanter Fall, für den ich so spontan auch keine Lösung parat habe^^.

    Allerdings: Auf meine Arbeitsstelle habe ich den umgekehrten Fall: Es gibt eine IT-Abteilung, die in einem eigenen Netzwerk innerhalb des Arbeitsnetzwerks liegt. Der WAN-Port des Routers der IT-Abteilung führt dann ins restliche Arbeitsnetzwerk und führt vorher noch ein SNAT durch. Dadurch kann die IT-Abteilung in ihrem Netzwerk problemlos auf das Arbeitsnetzwerk zugreifen, da - aus Sicht der anzufragenden Clients im Arbeitsnetzwerk - die Anfrage vom Router der IT-Abteilung stammt, dessen WAN-Port eine IP-Adresse aus demselben Subnetz besitzt wie das Arbeitsnetzwerk (und somit auch Teil des Arbeitsnetzwerks ist). Die Antwort landet wieder zurück zum IT-Router, ändert die Ziel-IP in jene des anfragenden Clients in der IT-Abteilung (wie bei NAT üblich) und leitet besagte Antwort auch dorthin weiter. Umgekehrt kann niemand vom Arbeitsnetzwerk auf das IT-Netzwerk zugreifen, da 1) eben absichtlich nirgends im Arbeitsnetzwerk hinterlegt ist, wohin Anfragen zum Netz der IT-Abteilung landen sollen (außer im Default-Gateway und damit zu einem anderen Router, der damit auch nichts anfangen kann) und 2) der Router der IT-Abteilung aufbauende Verbindungsversuche auf dem WAN-Port direkt blockiert.

    Ob dein Aufbau innerhalb der Routing-Tabelle auch funktioniert, kann ich mangels Erfahrung nicht sagen. Falls die Pakete aber wirklich den Router-PC erreichen (wie gesagt, ich weiß es nicht), dürfte meiner Vermutung nach auch NAT die Lösung deines Problems sein (vorausgesetzt, ich habe dein Problem auch richtig verstanden^^). Anfragen von einem IP-Subnetz auf ein anderes IP-Subnetz kann mit IPv4 ohne NAT garnicht funktionieren (falls doch, habe ich ein massives Verständnisproblem mit IPv4-Adressen^^).

  8. #8
    NAT war auch mein Gedanke. Hier sind meine Kenntnisse aber auch schon wieder vorbei. Eigentlich sollte ich sowas wissen als Fachinformatiker, aber ich hab damit seit meiner Ausbildung einfach nix zu tun gehabt.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •