5
Routingprobleme
Hallo zusammen,
ich hab ein Problem, bei dem ich nicht genau weiß, wie ich das lösen kann.
Aktuell existiert folgendes Netz:
Dazu noch folgende "Kleinigkeiten":
Der IPcop2 existiert noch nicht, soll aber noch dazu kommen.
Am Standort1 ist als default-Route x.x.10.250 eingetragen und das darf auch nicht geändert werden.
Die Konfiguration der Router kann ich nicht verändern.
Und jetzt zum eigentlichen Problem:
Wenn ich vom Server1 zum Client2 pinge, gehen die Pakete ja folgenden Weg
Server1 -> IPcop1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Das klappt alles wunderbar
Andersrum sollte der Weg folgender sein :
Client2 -> Router2 -> Router1 -> Server1 -- Server1 -> IPcop1 -> Router1 -> Router2 -> Client2
Der Weg klappt aber nicht.
Wenn ich am Server1 in der routing-Tabelle folgende Router eintrage klappts doch:
Netz : x.x.2.0
Gateway : x.x.10.247
Ich vermuter das der IPcop1 Packete verwirft, wenn er nur die Antwort vom Ping mitbekommt, aber den ursprünglichen REQUEST nicht.
Kann ich die iptables so verdrehen, das die Netze x.x.10.0/24 und x.x.2.0/24 uneingeschränkt miteinander kommunizieren können?
Oder liegt das Problem wo ganz anders?
Mir ist klar, das man das eigentlich eh anders macht. Aber im Monent kann z.B. an der Verkabelung nichts ändern
Ich bin für jede Hilfe danke
ich hab ein Problem, bei dem ich nicht genau weiß, wie ich das lösen kann.
Aktuell existiert folgendes Netz:
internet
|
|
Standort1 IPcop1 Server1 Standort2 IPcop2 Client2
x.x.10.0/24 x.x.10.250 x.x.10.249 x.x.2.0/24 x.x.2.? x.x.2.3
| | | | | |
| | | | | |
+------------------+--------------+ +---------------+----------+
| |
| |
ROUTER1 ROUTER2
x.x.10.247 x.x.1.254
| |
| |
+-----------------------------------------------+Dazu noch folgende "Kleinigkeiten":
Der IPcop2 existiert noch nicht, soll aber noch dazu kommen.
Am Standort1 ist als default-Route x.x.10.250 eingetragen und das darf auch nicht geändert werden.
Die Konfiguration der Router kann ich nicht verändern.
Und jetzt zum eigentlichen Problem:
Wenn ich vom Server1 zum Client2 pinge, gehen die Pakete ja folgenden Weg
Server1 -> IPcop1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Das klappt alles wunderbar
Andersrum sollte der Weg folgender sein :
Client2 -> Router2 -> Router1 -> Server1 -- Server1 -> IPcop1 -> Router1 -> Router2 -> Client2
Der Weg klappt aber nicht.
Wenn ich am Server1 in der routing-Tabelle folgende Router eintrage klappts doch:
Netz : x.x.2.0
Gateway : x.x.10.247
Ich vermuter das der IPcop1 Packete verwirft, wenn er nur die Antwort vom Ping mitbekommt, aber den ursprünglichen REQUEST nicht.
Kann ich die iptables so verdrehen, das die Netze x.x.10.0/24 und x.x.2.0/24 uneingeschränkt miteinander kommunizieren können?
Oder liegt das Problem wo ganz anders?
Mir ist klar, das man das eigentlich eh anders macht. Aber im Monent kann z.B. an der Verkabelung nichts ändern
Ich bin für jede Hilfe danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 60743
Url: https://administrator.de/contentid/60743
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
5 Kommentare
Neuester Kommentar
Erstmal hast du wahrscheinlich einen Fehler in deiner Schemazeichnung gemacht !!! Router 2 kann ja nicht die x.x.1.254 haben sondern vermutlich x.x.10.254, oder ??? Oder benutzt du auf dem Routerlink eine 16 Bit Adressmaske, dann würde es wieder klappen und wäre natürlich richtig ??!!
Du schreibst das dein Default Gateway die .250 ist. Warum konfigurierst du dann Einzelrouten auf Endsystemen wie dem Server 1 in das .2er Netz ?? Das ist doch Unsinn !
Wenn dein Default Gateway der IPCop mit der .250 ist dann wird das hier gemacht.
Dort muss eine zusätzliche statische Route eingetragen werden und nicht am Server, da dies das zentrale Gateway im Netzwerk ist !! Ein
route add x.x.2.0 <Maske> <Gateway>
sollte das Problem sofort lösen !
Es ist auch irrig anzunehmen der Hinweg wäre:
Server1 -> IPcop1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Der ist ebenfalls:
Server1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Der IPCop merkt beim Verbindungsaufbau das der Next Hop Router ins .2er Zielnetz am IPCop im selben Segment liegt und schickt daraufhin eine ICMP Type 5 Message (ICMP redirect) an den Server1 mit der IP Adresse des direkten Gateways an Router 1. Server 1 trägt daraufhin diese Route zum .2er Netz direkt in seine Routing Tabelle ein. (Das hast du übrigens statisch gekillt mit deiner falschen statischen Route an Server1 !)
Der Server wiederum startet dann seinen Sessionaufbau direkt mit dem Router 1 zum Zielnetz.
(Infos zum Redirect siehe hier: http://www.heise.de/security/artikel/44824/1)
Wenn du deine Routen richtig implementierst (Gleiches gilt für Standort 2 !!!) Also
Wenn du übrigens ein Traceroute ins Zielnetz machst kannst du den Weg mitverfolgen.
Bei Windows heisst das Kommando tracert oder pathping.
Du schreibst das dein Default Gateway die .250 ist. Warum konfigurierst du dann Einzelrouten auf Endsystemen wie dem Server 1 in das .2er Netz ?? Das ist doch Unsinn !
Wenn dein Default Gateway der IPCop mit der .250 ist dann wird das hier gemacht.
Dort muss eine zusätzliche statische Route eingetragen werden und nicht am Server, da dies das zentrale Gateway im Netzwerk ist !! Ein
route add x.x.2.0 <Maske> <Gateway>
sollte das Problem sofort lösen !
Es ist auch irrig anzunehmen der Hinweg wäre:
Server1 -> IPcop1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Der ist ebenfalls:
Server1 -> Router1 -> Router2 -> Client2 -- Client2 -> Router2 -> Router1 -> Server1
Der IPCop merkt beim Verbindungsaufbau das der Next Hop Router ins .2er Zielnetz am IPCop im selben Segment liegt und schickt daraufhin eine ICMP Type 5 Message (ICMP redirect) an den Server1 mit der IP Adresse des direkten Gateways an Router 1. Server 1 trägt daraufhin diese Route zum .2er Netz direkt in seine Routing Tabelle ein. (Das hast du übrigens statisch gekillt mit deiner falschen statischen Route an Server1 !)
Der Server wiederum startet dann seinen Sessionaufbau direkt mit dem Router 1 zum Zielnetz.
(Infos zum Redirect siehe hier: http://www.heise.de/security/artikel/44824/1)
Wenn du deine Routen richtig implementierst (Gleiches gilt für Standort 2 !!!) Also
- löschen der Route am Server und
- Eintragen der statischen Route am IPCop
Wenn du übrigens ein Traceroute ins Zielnetz machst kannst du den Weg mitverfolgen.
Bei Windows heisst das Kommando tracert oder pathping.
Hi,
als Ersten Danke für die ausführliche Antwort.
In das Schema hat sich wirklich ein Fehler eingeschlichen. Deswegen nochmal eine korrigierte und aktualisierte Version
Auf dem IPcop1 ist die Route ins Netz x.x.2.0 mit dem Gateway x.x.10.247 eingetragen.
Dennoch funktoniert ein ping von Client2 auf Server1 nicht.
Erst nachdem die Route, wie im IPcop, im Server1 eingetragen ist funtioniert es.
Das der IPcop1 eigentlich die Route via ICMP an den Server1, und jeden anderen Rechner auch, melden sollte ist klar. Aber er tut es nicht ... warum auch immer.
Ich könnte mir vorstellen, das der IPcop garnicht für einen solchen Aufbau gedacht und daher diese Funktionalität garnicht implementiert ist.
als Ersten Danke für die ausführliche Antwort.
In das Schema hat sich wirklich ein Fehler eingeschlichen. Deswegen nochmal eine korrigierte und aktualisierte Version
internet internet
| |
| |
Standort1 IPcop1 Server1 Standort2 IPcop2 Client2
x.x.10.0/24 x.x.10.250 x.x.10.249 x.x.2.0/24 x.x.2.? x.x.2.3
| | | | | |
| | | | | |
+------------------+--------------+ +---------------+----------+
| |
| |
x.x.10.247 x.x.2.254
ROUTER1 ROUTER2
| |
| |
+------------- x.x.250.0/30--------------------+Auf dem IPcop1 ist die Route ins Netz x.x.2.0 mit dem Gateway x.x.10.247 eingetragen.
Dennoch funktoniert ein ping von Client2 auf Server1 nicht.
Erst nachdem die Route, wie im IPcop, im Server1 eingetragen ist funtioniert es.
Das der IPcop1 eigentlich die Route via ICMP an den Server1, und jeden anderen Rechner auch, melden sollte ist klar. Aber er tut es nicht ... warum auch immer.
Ich könnte mir vorstellen, das der IPcop garnicht für einen solchen Aufbau gedacht und daher diese Funktionalität garnicht implementiert ist.
Was sagt denn ein traceroute (tracert) oder pathping von Client 2 auf Server 1. Wo bleibt der hängen. Auch bei IPCop2 muss natürlich eine statische Route mit
route add x.x.10.0 mask 255.255.255.0 gateway x.x.2.254
eingetragen sein, was du vermutlich aber gemacht hast ??!!
Wichtig wäre mal zu sehen wo der Traceroute hängenbleibt, denn da ist auch der Routingfehler.
Auch wenn der IPCop1 kein ICMP Typ5 Packet (redirect) sendet muss es klappen !!! Dann rennt das Packet zwar immer erst über den IPCop und dann zum Router und hat einen Hop mehr aber letztlich wäre das kein Problem und MUSS trotzdem funktionieren.
Es ist zu vermuten das am IPCop irgendein Packetfilter erstens ICMP Packete verhindert und zweitens wohl auch ein korrektes Forwarding. Sehr wahrscheinlich lässt er nur Packete durch sich durch supported aber kein rerouting auf demselben Interface.
Also vermutlich ein reines IPCop Problem.
Das solltest du aber mithilfe der Doku sehr leicht in den Griff bekommen, da IPCop da sehr flexibel ist. Linux verhält sich mit ICMPs standardkonform !
Ein Traceroute Output wäre aber spannend...
route add x.x.10.0 mask 255.255.255.0 gateway x.x.2.254
eingetragen sein, was du vermutlich aber gemacht hast ??!!
Wichtig wäre mal zu sehen wo der Traceroute hängenbleibt, denn da ist auch der Routingfehler.
Auch wenn der IPCop1 kein ICMP Typ5 Packet (redirect) sendet muss es klappen !!! Dann rennt das Packet zwar immer erst über den IPCop und dann zum Router und hat einen Hop mehr aber letztlich wäre das kein Problem und MUSS trotzdem funktionieren.
Es ist zu vermuten das am IPCop irgendein Packetfilter erstens ICMP Packete verhindert und zweitens wohl auch ein korrektes Forwarding. Sehr wahrscheinlich lässt er nur Packete durch sich durch supported aber kein rerouting auf demselben Interface.
Also vermutlich ein reines IPCop Problem.
Das solltest du aber mithilfe der Doku sehr leicht in den Griff bekommen, da IPCop da sehr flexibel ist. Linux verhält sich mit ICMPs standardkonform !
Ein Traceroute Output wäre aber spannend...
hi,
hier mal ein Ergebisse von tracert:
... und in die andere Richtung :
und jetzt noch ein rechner auf dem die route nicht von Hand eingetragen wurde:
hier mal ein Ergebisse von tracert:
tracert x.x.2.4
1 <1 ms <1 ms <1 ms x.x.10.250
2 <1 ms 20 ms <1 ms x.x.1.254
3 5 ms 7 ms 5 ms x.x.250.2
4 5 ms 5 ms 5 ms x.x.2.4... und in die andere Richtung :
tracert x.x.10.230
1 <1 ms <1 ms <1 ms x.x.2.254
2 5 ms 5 ms 5 ms x.x.250.1
3 5 ms 5 ms 5 ms x.x.10.230und jetzt noch ein rechner auf dem die route nicht von Hand eingetragen wurde:
tracert x.x.10.251
1 <1 ms <1 ms <1 ms x.x.2.254
2 5 ms 5 ms 5 ms x.x.250.1
3 * * * Zeitüberschreitung der Anforderung.
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
.
.
.
Mmmmhhh..DAS zeigt eigentlich das du ein Routing Problem beim Router x.x.250.1 hast. Der kennt den next Hop ins .10er Netz nicht. Die .250.1 hat das der Router1 oder der Router2 auf dem WAN konfiguriert ??? Eigentlich kann es nur der Router 2 sein denn am Router 1 wäre das unmöglich weil das .10er Netz direkt an ihm angeschlossen ist.
Ausnahme dann wenns doch Router1 ist, wäre das Endgerät wenn es mit dem default gateway auf eine andere Adresse als die .247 zeigt. Ich meine das war bei dir der Fall oder ?? Die zeigen auf die .250 oder ??
Das beweist dann aber ganz klar das der IPCop ein Problem mit dem lokalen Routing hat. Der reroutet dann nicht auf dem lokalen Interface und schickt auch keine ICMP redirects was er normalerweise sofort standardkonform tuen müsste !!!
Das liegt vermutlich daran das ihm das mit der Firewall SW die er ja draufhat abgeschaltet worden ist. Das ist bei FWs sehr häufig der Fall.
Da der IPCop aber customizable ist wie alles unter Linux solltest du das eigentlich wieder reaktiviert bekommen, so das er sich wieder normal Layer 3 konform verhält.
Ausnahme dann wenns doch Router1 ist, wäre das Endgerät wenn es mit dem default gateway auf eine andere Adresse als die .247 zeigt. Ich meine das war bei dir der Fall oder ?? Die zeigen auf die .250 oder ??
Das beweist dann aber ganz klar das der IPCop ein Problem mit dem lokalen Routing hat. Der reroutet dann nicht auf dem lokalen Interface und schickt auch keine ICMP redirects was er normalerweise sofort standardkonform tuen müsste !!!
Das liegt vermutlich daran das ihm das mit der Firewall SW die er ja draufhat abgeschaltet worden ist. Das ist bei FWs sehr häufig der Fall.
Da der IPCop aber customizable ist wie alles unter Linux solltest du das eigentlich wieder reaktiviert bekommen, so das er sich wieder normal Layer 3 konform verhält.
