6
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
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: 142273
Url: https://administrator.de/contentid/142273
Printed on: April 23, 2024 at 10:04 o'clock
6 Comments
Latest comment
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 )
Also die Routen stehen alle oben 
213.x.x.x ist unser Provider
Die Vlans baue ich zwar hier auf einem Switch aber der Tunnel und die zwei VLANS kommen auch auf der anderen Seite an.
Das 172.20.0.0 Netz ist ein DMZ Netz und das wollte ich so klein wie möglich halten.
Das 192.168.0.0 Netz musste ich bereits aufbohren da wir die Anzahl der 254 Geräte überschritten haben.
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 213.x.x.x ist unser Provider
Die Vlans baue ich zwar hier auf einem Switch aber der Tunnel und die zwei VLANS kommen auch auf der anderen Seite an.
Das 172.20.0.0 Netz ist ein DMZ Netz und das wollte ich so klein wie möglich halten.
Das 192.168.0.0 Netz musste ich bereits aufbohren da wir die Anzahl der 254 Geräte überschritten haben.
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
Ja das stimmt.
Ich komme aber auch von meinem 192.168.0.0 in mein 172.20.0.0 Netz
Sollte ich da von dort aus nicht auch das 172.20.10.0 Netz erreichen.
Der Provider hat zumindest nichts wegen den Netzwerksegmenten gesagt. Immerhin planen wir den Umzug schon seit Wochen mit Checklisten.
Ich komme aber auch von meinem 192.168.0.0 in mein 172.20.0.0 Netz
Sollte ich da von dort aus nicht auch das 172.20.10.0 Netz erreichen.
Der Provider hat zumindest nichts wegen den Netzwerksegmenten gesagt. Immerhin planen wir den Umzug schon seit Wochen mit Checklisten.
muss er auch nicht, da du für das routing aus deiner dmz verantwortlich bist.
deine beiden netze kennt ja auch der router nur eben das 172.20.10.x netz nicht.
na änder doch nur zum test die maske aus deiner dmz oder trage die route ein.
deine beiden netze kennt ja auch der router nur eben das 172.20.10.x netz nicht.
na änder doch nur zum test die maske aus deiner dmz oder trage die route ein.
Threat kann geschlossen werden.
Entweder haben die Jungs vom RZ etwas gemacht, wo mir noch das Feedback fehlt, oder es lang am Richtlinienrouting vs. statisches Routing.
Wobei mir nicht klar ist wo der Unterschied ist.
Zumindest geht es jetzt
Danke trotzdem fürs Feedback.
Entweder haben die Jungs vom RZ etwas gemacht, wo mir noch das Feedback fehlt, oder es lang am Richtlinienrouting vs. statisches Routing.
Wobei mir nicht klar ist wo der Unterschied ist.
Zumindest geht es jetzt
Danke trotzdem fürs Feedback.
