Verständnis Route oder Problem
Hallo Leute folgendes Problem stellt sich mir schon seit gestern.
Im Bild anbei ist unsere aktuelle Konfig der Firewall abgebildet.
Der blaue Teil ist der Teil der problemlos funktioniert. Dieser steht bei uns im Haus.
Um die Hochverfügbarkeit sicher zu stellen verlagern wir Teile der DMZ und des Intranets in ein RZ (lila).
Der Anbieter des RZ hat uns dazu einen Router konfiguriert und wir mussten diesen nur noch anstecken.
Hier im Haus sollte ich nur zwei Routen einrichten (siehe Bild) damit alles wieder wie gewohnt funktioniert.
Leider war dies dank "Murphy" nicht so.
Jetzt weiss ich nicht genau wo das Problem liegt.
Auf den Rechner im Netz 192.168.10.x kann ich problemlos zugreifen.
Auf den Rechner im Netz 172.20.10.x nicht.
Anbei die Routen der Firewall:
default via 192.168.0.60 dev eth1 table 1
default via 172.20.0.10 dev eth2 table 2
default via 213.x.x.A dev eth0 table 200 proto static onlink
default via 213.x.x.A dev eth0 table default proto kernel onlink
10.242.2.2 dev tun0 proto kernel scope link src 10.242.2.1
172.20.0.0/28 dev eth2 proto kernel scope link src 172.20.0.1
213.x.x.C /28 dev eth0 proto kernel scope link src 213.x.x.B
10.242.2.0/24 via 10.242.2.2 dev tun0
192.168.0.0/23 dev eth1 proto kernel scope link src 192.168.0.2
127.0.0.0/8 dev lo scope link
local 10.242.2.1 dev tun0 table local proto kernel scope host src 10.242.2.1
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.20.0.0 dev eth2 table local proto kernel scope link src 172.20.0.1
local 172.20.0.1 dev eth2 table local proto kernel scope host src 172.20.0.1
broadcast 172.20.0.15 dev eth2 table local proto kernel scope link src 172.20.0.1
broadcast 192.168.0.0 dev eth1 table local proto kernel scope link src 192.168.0.2
local 192.168.0.2 dev eth1 table local proto kernel scope host src 192.168.0.2
broadcast 192.168.1.255 dev eth1 table local proto kernel scope link src 192.168.0.2
broadcast 213.x.x.C dev eth0 table local proto kernel scope link src 213.x.x.B
local 213.x.x.B dev eth0 table local proto kernel scope host src 213.x.x.B
broadcast 213.x.x.D dev eth0 table local proto kernel scope link src 213.x.x.B
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
Im Bild anbei ist unsere aktuelle Konfig der Firewall abgebildet.
Der blaue Teil ist der Teil der problemlos funktioniert. Dieser steht bei uns im Haus.
Um die Hochverfügbarkeit sicher zu stellen verlagern wir Teile der DMZ und des Intranets in ein RZ (lila).
Der Anbieter des RZ hat uns dazu einen Router konfiguriert und wir mussten diesen nur noch anstecken.
Hier im Haus sollte ich nur zwei Routen einrichten (siehe Bild) damit alles wieder wie gewohnt funktioniert.
Leider war dies dank "Murphy" nicht so.
Jetzt weiss ich nicht genau wo das Problem liegt.
Auf den Rechner im Netz 192.168.10.x kann ich problemlos zugreifen.
Auf den Rechner im Netz 172.20.10.x nicht.
Anbei die Routen der Firewall:
default via 192.168.0.60 dev eth1 table 1
default via 172.20.0.10 dev eth2 table 2
default via 213.x.x.A dev eth0 table 200 proto static onlink
default via 213.x.x.A dev eth0 table default proto kernel onlink
10.242.2.2 dev tun0 proto kernel scope link src 10.242.2.1
172.20.0.0/28 dev eth2 proto kernel scope link src 172.20.0.1
213.x.x.C /28 dev eth0 proto kernel scope link src 213.x.x.B
10.242.2.0/24 via 10.242.2.2 dev tun0
192.168.0.0/23 dev eth1 proto kernel scope link src 192.168.0.2
127.0.0.0/8 dev lo scope link
local 10.242.2.1 dev tun0 table local proto kernel scope host src 10.242.2.1
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 172.20.0.0 dev eth2 table local proto kernel scope link src 172.20.0.1
local 172.20.0.1 dev eth2 table local proto kernel scope host src 172.20.0.1
broadcast 172.20.0.15 dev eth2 table local proto kernel scope link src 172.20.0.1
broadcast 192.168.0.0 dev eth1 table local proto kernel scope link src 192.168.0.2
local 192.168.0.2 dev eth1 table local proto kernel scope host src 192.168.0.2
broadcast 192.168.1.255 dev eth1 table local proto kernel scope link src 192.168.0.2
broadcast 213.x.x.C dev eth0 table local proto kernel scope link src 213.x.x.B
local 213.x.x.B dev eth0 table local proto kernel scope host src 213.x.x.B
broadcast 213.x.x.D dev eth0 table local proto kernel scope link src 213.x.x.B
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 142273
Url: https://administrator.de/forum/verstaendnis-route-oder-problem-142273.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
6 Kommentare
Neuester Kommentar
hallo,
ich sehe keine routen zu eurem provider
192.168.10.x /24
172.20.10.x/24
und auch nicht die zwei ports des vpn-routers1
oder fehlt da nur was in dem post ?
gw1 192.168.0.60
gw2 172.20.0.10
über die vlan´s nehme ich mal an kümmern sich die router selber im vpn-netz
wenn die routen drin sind sollte es auch funktionieren
gruß
oh standen ganz oben überlesen
nur die frage warum euer netz 172.20.0.x /28 und nicht wie beim 192.168.0.x /23 ( ich meine die maske )
ich sehe keine routen zu eurem provider
192.168.10.x /24
172.20.10.x/24
und auch nicht die zwei ports des vpn-routers1
oder fehlt da nur was in dem post ?
gw1 192.168.0.60
gw2 172.20.0.10
über die vlan´s nehme ich mal an kümmern sich die router selber im vpn-netz
wenn die routen drin sind sollte es auch funktionieren
gruß
oh standen ganz oben überlesen
nur die frage warum euer netz 172.20.0.x /28 und nicht wie beim 192.168.0.x /23 ( ich meine die maske )
genau das hatte ich ja zu shluss geschrieben, hate ich überlesen mit gw.
aber die maske des 172.20.0.x netzes wird das problem sein.
im 192.168.0.x hast du ja eine maske die das providernetz zeigt und im 172.20.0.x nicht
da slltest du entweder ein zusätzlichen eintrag im routig machen oder einfach die maske gleich ziehen.
wenn ich deine frage richtig verstanden habe, konntest du ja aus dem 192. segmen in das 192. segment vom provider.
nur vom 172.20.0.x nicht in das 172.20.10.x . stimmt doch oder ?
gruss
aber die maske des 172.20.0.x netzes wird das problem sein.
im 192.168.0.x hast du ja eine maske die das providernetz zeigt und im 172.20.0.x nicht
da slltest du entweder ein zusätzlichen eintrag im routig machen oder einfach die maske gleich ziehen.
wenn ich deine frage richtig verstanden habe, konntest du ja aus dem 192. segmen in das 192. segment vom provider.
nur vom 172.20.0.x nicht in das 172.20.10.x . stimmt doch oder ?
gruss