ip routing (Cisco Packet Tracer)

[Kazuma]

Hallo liebe Community,

ich experimentiere wieder einmal mit dem Cisco Packet Tracer herum und siehe da, irgendwas läuft wieder nicht.

Aber damit das Problem auch behoben wird, hoffe ich auf Hilfe.

Das Szenario ist simpel:

Der Rechner aus dem 100er Netz, soll mit dem Webserver aus dem 200er Netz kommunizieren. Dabei hängt der Webserver direkt an einem Router. 

Interface des Routers Richtung Webserver: GigabitEthernet0/0............ 192.168.200.20/24

IP des Webservers: 192.168.200.35

Der Router hängt an einem anderen Router und ist via Serial angebunden.

Router Webserver:  S0/0/0.............20.20.20.20/24

Router PC: S0/0/0.................10.10.10.10/24

Und wie man schon vermutet, hängt der Rechner an dem zweiten Router:

Interface des Routers Richtung Rechner: GigabitEthernet0/0.................192.168.100.10/24

 

Was trage ich nun in die Routing Tabellen ein, damit die Anfrage rüber geroutet wird?

Kann das Szenario auch mit einem Router abgebildet werden?

Anmerkung: Ja, die Adressen sind aus Privat und öffentlich gemischt und ja, die Simulation im Tracer ist auch nicht die Schönste. 

 

Danke im Voraus!

 

 

Mit freundlichen Grüßen

Kazuma 

[Crash2001]

Am ‎13‎.‎04‎.‎2017 um 15:57 schrieb Kazuma:

[...]Was trage ich nun in die Routing Tabellen ein, damit die Anfrage rüber geroutet wird?

Na du musst die Netze bekannt machen, die nicht direkt mit dem Router verbunden sind und die er somit noch nicht kennt, und bei der Route den nächsten Hop (also die IP des anderen Routers) angeben. Alternativ kannst du auch eine Nullroute auf den nächsten Hop zeigen lassen, da am einen Ende ja nur dem Router bekannte Netze hängen. Und natürlich muss das IP Routing aktiviert sein.
Oder aber du nimmst ein Routingprotokoll (RIPv2, EIGRP, OSPF, BGP, ...) und lässt die Geräte die Routen miteinander austauschen.

Damit das Routing generell funktioniert, müssen aber die Interface der beiden Router miteinander sprechen können, was sie laut deiner Zeichnung vermutlich nicht können (10.10.10.10/16 (?) mit 20.20.20.20/16 (?)) Die beiden Interface müssen in einem (Transfer)Netz liegen. Ansonsten ist keine Kommunikation zwischen den beiden Routern möglich.

Am ‎13‎.‎04‎.‎2017 um 15:57 schrieb Kazuma:

Kann das Szenario auch mit einem Router abgebildet werden?[...]

Wieso sollte das denn nicht gehen können? Vor allem hast du zwischen den beiden Routern ja kein weiteres Netzsegment, an dem GEräte hängen.

[Kazuma]

Hallo Crash2001.

Danke für deine Antwort!

 

Folgendes war das Problem:

Die beiden Interfaces waren in zwei unterschiedlichen Netzen. Diese sind nun im selben Netz und können miteinander kommunizieren.

 

Dann musste ich ja noch die Routing Tabelle vervollständigen:

"Router4" -> ip route 192.168.200.0 255.255.255.0 10.10.10.20

"Router3" -> ip route 192.168.100.0 255.255.255.0 10.10.10.10

 

Beide Seiten können sich jetzt gegenseitig erreichen.

 

Mit freundlichen Grüßen

Kazuma

 

Bearbeitet 18. April 2017 von Kazuma

[RipperFox]

vor 4 Stunden schrieb Crash2001:

Damit das Routing generell funktioniert, müssen aber die Interface der beiden Router miteinander sprechen können, was sie laut deiner Zeichnung vermutlich nicht können (10.10.10.10/16 (?) mit 20.20.20.20/16 (?)) Die beiden Interface müssen in einem (Transfer)Netz liegen. Ansonsten ist keine Kommunikation zwischen den beiden Routern möglich.

Nicht unbedingt:

Ein beherztes "ip route 0.0.0.0 0.0.0.0 S0/0/0 auf beiden Routern weist diese an, einfach alles über die Serielle Schnittstelle zu ballern. Alternativ kann man auch die richtigen Routen statisch eintragen.

Das hätte sogar mit 10.10.10.10/24 und 20.20.20.20/24 funktioniert.

Natürlich müssen die Router an den Hosts in ihrem Netz-Segment als Default-Gateway eingetragen sein..

Btw: Der Packet Tracer kann wohl keine /31 Transfernetze (RFC 3021) und unnumbered ging bei meinem Test eben auch nicht..

 

 

Bearbeitet 18. April 2017 von RipperFox

[Crash2001]

@RipperFox:
Bist du sicher, dass das geht? Das wäre eine ziemliche Sicherheitslücke. Oder geht das nur im Packet Tracer und ist einer von tausenden Bugs?

Sollte das gehen, sollte man sich so einen Mist aber gar nicht erst angewöhnen, sondern lieber die Verbindung sauber aufbauen und nicht mit Krücken, Workarounds, Ausnahmen und sonst was schon als Standard rumfrickeln.

Die Pakete gehen dann zwar in Richtung anderer Router, aber ob dieser sie auch annimmt, ist eine andere Sache. Ich meine - ich kann dem Router ja auch sagen, dass das Netz x.x.x.x/y über den entsprechenden Router zu erreichen ist. Nur weil der Router weiß, dass er die Pakete für die entsprechende IP-Adresse über ein bestimmtes Interface herausschicken soll, kann er aber trotzdem nicht mit dem anderen Router sprechen. Rein theoretisch müsste der andere Router das Paket verwerfen.

Man kann ja auch zwei PCs in unterschiedlichen Subnetzen an einen Switch oder auch Hub anstecken und sie können dennoch nicht miteinander kommunizieren, außer es gibt ein entsprechendes Routing zwischen den beiden Netzen, obwohl der Switch weiß, welche MAC-Adresse auf welchem Port hängt.

[RipperFox]

Das geht - vor meinem Beitrag in PT 7 hatte ich das getestet - natürlich geht das auch im realen Internet und es ist auch keine spezielle Krücke.  Nur normales Routing: Router X bekommt ein Packet auf Interface A und schickt es nach Konsultation seiner Routingtabelle z.B. auf Interface B wieder raus. Standardmäßig interessiert einen Router die Zieladresse - nicht viel mehr.

Ob der Router einen "Rückweg" kennt um mit dem anderen Router zu sprechen ist völlig egal - der Rückweg kann auch auch über einen völlig anderen Weg erfolgen. Oder auch kaputt sein - d.h. die Pakete erreichen ihr Ziel, aber es kommt dann halt keine Antwort..

Das Verwerfen von Paketen mit gültiger Zieladresse und vorhandener Zielroute ist imho Aufgabe eines Firewallkonzepts, das natürlich auch in einem Router umgesetzt werden kann - um zu verhindern das Pakete weitergeleitet werden, von denen sicher auszugehen ist, das sie niemals legithim über ein definiertes Interface eingehen. Denn sicherheitstechnisch interessant wird es, wenn man es mit "Endkunden" zu tun hat.  IP Spoofing z.B. von Hetzner oder einem Telekomanschluss aus dürfte heute nicht mehr funktionieren, da deren Layer 3 Router (hoffentlich) nur Traffic von eigenen IPs durchlassen. Ein Corerouter von einem ISP frisst aber vermutlich alles was man ihm hinwirft und leitet schön weiter..

Bei dynamischen Routingprotokollen werden übrigens auch Regelwerke genutzt, um zu kontrollieren ob empfangene Routen vertrauenswürdig/plausibel sind und ob dann ggf. Routinginformationen verworfen werden. Aber Routinginformationen sind nicht gleichzusetzten mit Paketen..

Der von mit erwähnte RFC3021 existiert seit dem Jahr 2000 - er beschreibt, wie man ein Transfernetz aus einem /31 mit lediglich 2 Adressen bildet (Netz- und Broadcastadresse fallen weg) - das "übliche" /30 verschwendet ja 50% der Adressen.

Das serielle Kabel zwischen den Routern im Beispiel entspricht übrigens einer Punkt zu Punkt Verbindung - da reicht es wirklich zu sagen: Schicke Pakete für Netz X über diese Leitung..

Grundsätzlich ist es nur Aufgabe des sendenden Hosts anhand seiner Routingtabelle zu bestimmen, auf welchem Interface er ein Paket versendet..

[Crash2001]

vor 15 Stunden schrieb RipperFox:

Das geht - vor meinem Beitrag in PT 7 hatte ich das getestet - natürlich geht das auch im realen Internet und es ist auch keine spezielle Krücke.  Nur normales Routing: Router X bekommt ein Packet auf Interface A und schickt es nach Konsultation seiner Routingtabelle z.B. auf Interface B wieder raus. Standardmäßig interessiert einen Router die Zieladresse - nicht viel mehr.

Ob der Router einen "Rückweg" kennt um mit dem anderen Router zu sprechen ist völlig egal - der Rückweg kann auch auch über einen völlig anderen Weg erfolgen. Oder auch kaputt sein - d.h. die Pakete erreichen ihr Ziel, aber es kommt dann halt keine Antwort..[...]

Selbst wenn es funktioniert, sollte es so eigentlich standardmäßig nicht so verwendet werden, sondern es sollte schon eine Kommunikationsverbindung zwischen den beiden Routern auf Layer 3 aufgebaut werden können. Alles andere ist in meinen Augen Flickwerk. So knapp sollten IP-Adressen auch wieder nicht sein. Alleine schon ein kleiner Test, ob das Interface per Ping erreichbar ist, kann so komplett in die Hose gehen, da dafür wieder Routen benötigt werden, anstatt dass man das gegenüberliegende Interface auf direktem Wege erreicht. Das macht das Debugging nur UNNÖTIG kompliziert.

Wenn ein Polizist dich falsch herum in eine Einbahnstraße schickt als Umleitung, macht man das zwar, und es funktioniert auch, der Normalfall sollte es aber definitiv nicht sein, sondern nur im Ausnahmefall.

RFC3021 kenne ich und habe ich auch schon eingesetzt.

Bearbeitet 19. April 2017 von Crash2001

[RipperFox]

vor 33 Minuten schrieb Crash2001:

Selbst wenn es funktioniert, sollte es so eigentlich standardmäßig nicht so verwendet werden, sondern es sollte schon eine Kommunikationsverbindung zwischen den beiden Routern auf Layer 3 aufgebaut werden können.

Es existiert doch eine symmetische Punkt-zu-Punkt Verbindung 10.10.10.10 kann 20.20.20.20 anpingen und umgekehrt - die seriellen Interfaces haben sogar eine eigene IP (die bei unnumbered nicht mal nötig wäre). Es ist auch üblich Hostrouten zu verwenden, wenn man einen Haufen Kunden einzeln anbindet (bei PPP routet man z.B. ja auch nur ein /32).

Selbst auf Ethernet kann man Point-to-Point Links nutzen - z.B. nutzt Hetzner auch Hostrouten (/32) bei der Verteilung von zusätzlichen IPs - IPv4 Adressen sind halt knapp.

Zu asymmetrisches Routing nochmal: Heute seltener in Gebrauch, aber kennst Du noch Internet über Sat mit Backchannel z.B. via ISDN? Da war es immer so, dass der Router in der Uplinkstation des Satelliten niemals Pakete vom Endkunden Router über das Sat-Interface bekommen hat (Weil der Rückkanal über ISDN erfolgt). Damals gab es bei den ISDN Dialups teilweise keinen Spoofing-Schutz, so dass das ohne VPN zum Satprovider funktioniert hat. Heute würde der ISDN Kanal-ISP Pakete mit ihm ungültig vorkommender IP verwerfen, so dass man einen Tunnel zum Satprovider braucht, um seine Uplinkpakete abzukippen.

 

 

[Bitjunkie78]

Am 18.4.2017 um 11:32 schrieb Kazuma:

Hallo Crash2001.

Danke für deine Antwort!

 

Folgendes war das Problem:

Die beiden Interfaces waren in zwei unterschiedlichen Netzen. Diese sind nun im selben Netz und können miteinander kommunizieren.

 

Dann musste ich ja noch die Routing Tabelle vervollständigen:

"Router4" -> ip route 192.168.200.0 255.255.255.0 10.10.10.20

"Router3" -> ip route 192.168.100.0 255.255.255.0 10.10.10.10

 

Beide Seiten können sich jetzt gegenseitig erreichen.

 

Mit freundlichen Grüßen

Kazuma

 

Hi Kazuma.

Statisches Routing wird in RL wirklich sehr selten angewendet.

Wenn ich mir vorstelle das ich im Netz meiner Firma auf über 30 Nodes mit  +80  Netzen statische Routen konfigurieren müsste, würde ich glaube ich durchdrehen :-)

Natürlich geht das in deinem Fall ohne Probleme. Optional kann man natürlich auch dynamisch Routen. Dies wird dann in form von RIP, OSPF, BGP etc. parametriert.

Bearbeitet 16. Mai 2017 von Bitjunkie78