gi-networx
Goto Top

Bekannte Netze mit Distance 1 routen, Rest mit Distance 2 ins Blackhole?

Hi,

folgende Situation:

Ich habe verschiedene 192.168.x.0/24-Netze im Einsatz, sagen wir 192.168.1.0/24 bis 192.168.10.0/24. Diese Netze sind alle direkt an einen zentralen Router angeschlossen, welcher in jedem Netz eine Gateway-IP hat und zwischen den Netzen routet. Zusätzlich sind die Netze 192.168.50.0/24 bis 192.168.60.0/24 über einen 2. Router erreichbar. Die Routen dorthin sind statisch im zentralen Router eingetragen.

Als Default-Route ist im zentralen Router die Gateway-IP meiner Firewall eingetragen, also die Route ins Internet. Ich möchte jetzt allerdings vermeiden, dass der zentrale Router Pakete für z.B. 192.168.90.0/24 unnützerweise an die Firewall sendet, da er dieses Netz nicht kennt. Da es ja vorhersehbar ist, dass die Firewall mit diesen Paketen auch nichts anfangen kann möchte ich unnütze Load auf der Firewall vermeiden.

Die oben genannten Routen in die direkt angeschlossenen Netze und in die Netze die über den 2. Router erreichbar sind, sind alle mit einer administrativen Distanz 1 konfiguriert. Ich habe mir jetzt überlegt, dass ich auf dem Zentralrouter eine Blackhole- bzw. Reject-Route nach 192.168.0.0/16 mit einer administrativen Distanz von 2 (oder höher) einrichte. Davon erwarte ich mir das der Router alle Pakete in die vorhandenen Netze über die jeweilige Route mit der Distanz 1 sendet und die Pakete für die nicht vorhandenen Netze via der /16-Route mit der Distanz 2 verwirft, weil er keine andere Route in diese Netze hat.

Habe ich mir das richtig vorgestellt, oder habe ich hier irgendwo einen Denkfehler drin???

Viele Grüße,
MIchl

Content-ID: 135857

Url: https://administrator.de/forum/bekannte-netze-mit-distance-1-routen-rest-mit-distance-2-ins-blackhole-135857.html

Ausgedruckt am: 22.12.2024 um 20:12 Uhr

datasearch
datasearch 12.02.2010 um 22:05:12 Uhr
Goto Top
Wenn dein Router richtig arbeitet wird das so funktionieren und ist eine übliche Konfiguration. Du musst nur beim konfigurieren aufpassen, nicht das du dich absägst.
dog
dog 13.02.2010 um 00:48:59 Uhr
Goto Top
Ich möchte jetzt allerdings vermeiden, dass der zentrale Router Pakete für z.B. 192.168.90.0/24 unnützerweise an die Firewall sendet, da er dieses Netz nicht kennt.

Was auf jedem besseren Router mit einer Firewall / ACL Regel erledigt ist...
gi-networx
gi-networx 13.02.2010 um 09:11:20 Uhr
Goto Top
Aber dann müsste ich ja für jedes nicht vorhandene Netz einen eigenen Eintrag in einer ACL machen, oder? Ich möchte eigentlich vermeiden, dass wenn ich z.B. ein neues Netz anlege, ich noch zusätzlich an anderen Stellen (z.B. in der ACL) irgendwas ändern muss. So könnte ich halt einfach auf dem Router ein neues Interface im neuen Netz konfigurieren und die Sache wäre damit gegessen...
aqui
aqui 13.02.2010 um 13:10:42 Uhr
Goto Top
Nein ! Du kannst doch CIDR Masken benutzen was deine Firewall problemlos supporten sollte !!
Die Firewall wird ja niemals RFC 1918 Netze ins Internet routen.
Du konfigurierst schlicht und einfach wie dog oben schon erwähnt hat eine Inbound Regel mit der du alle RFC_1918_IP_Netze (Private IPs) ganz simpel blockst !!!
In Cisco Access Listen Nomenklatur gesprochen sähe eine ACL für alle privaten IPs dann so aus:
access-list 110 deny ip any 10.0.0.0 0.255.255.255
access-list 110 deny ip any 172.16.0.0 0.15.255.255
access-list 110 deny ip any 192.168.0.0 0.0.255.255

Analog übernimmst du das für deine FW am eingehenden Ethernet Interface und schon hat diese Ruhe vor diesen IP Netzen !!
Noch besser wäre es diese Liste am zentralen Router am Interface wo deine FW hängt zu implementieren, dann kommen diese Pakete gar nicht erst an der FW an face-wink
Einfacher gehts ja nun wirklich nicht...!
gi-networx
gi-networx 13.02.2010 um 15:24:49 Uhr
Goto Top
Hi,

ja, das hört sich natürlich auch logisch an. Das Traffic in private Netze gar nicht erst an der FW ankommt, war ja vor vornherein meine Idee. Allerdings habe ich noch eine Frage zu

access-list 110 deny ip any 10.0.0.0 0.255.255.255

Ich kenne mich mit Cisco ACLs jetzt nicht so gut aus, aber müsste es nicht

access-list 110 deny ip any 10.0.0.0 255.0.0.0 oder 10.0.0.0/8 heißen?

Schreibt man die Maske in Ciscos ACLs andersherum?
gi-networx
gi-networx 13.02.2010 um 15:28:20 Uhr
Goto Top
Ah okay, ich habe das ganze jetzt gerade nochmal auf http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_not ... nachgelesen. Alles klar...
datasearch
datasearch 13.02.2010 um 20:58:55 Uhr
Goto Top
Eine ACL ist hier aber überflüssig. Die privaten Adressen routet man am Gateway gegen Null. Wenn du dann Routen für die existierenden Netze entweder über ein Routingprotokoll oder statisch dem Router bekannt machst, funktioniert alles. Eine ACL ist hier nur unnötiger Konfigurationsaufwand und kostet unnütz CPU.

Routing-Konfiguration (IP-Adressen erfunden):
Linux-Router, interne IP des Transportnetzes: 10.0.10.1
Cisco-L3 Switch, IP im Transportnetz: 10.0.10.2


 
ip route add blackhole 10.0.0.0/8
ip route add blackhole 172.6.0.0/12
ip route add blackhole 192.168.0.0/16
ip route add 10.0.0.0/16 via 10.0.10.2

Der Switch hat 10 weitere Subnetze lokal connected. Um Pakete an nicht vorhandene IP-Netze aus dem Netz 10.0.0.0/16 nicht wieder zurück an den Router zu schicken, und damit eine Loop (Ping-Pong Problem) zu bauen, werden am Router ebenfalls die Blackhole-Netze bekanntgegeben.

Ein weiteres Segment aus dem Bereich 10.0.100.0/22 beifindet sich hinter dem L3 Switch. Erreichbar über einen weiteren Router 10.0.50.2 vom L3 Interface 10.0.50.1.

ip route 10.0.0.0 255.0.0.0 null0
ip route 10.0.100.0 255.255.252.0 10.0.50.2
Auf diesem Router gibt es dann wieder die Blackhole-Routen um noch nicht vorhandene Netze ebenfalls nach null zu routen. Hier darf es aber nur 10.0.100.0/22 sein, dass nach null0 geroutet wird, sonst wird kein Client über diesen Router das Internet-Gateway erreichen können. Interface null0 muss natürlich vorhanden sein face-wink

Mit dieser Methode brauchst du keine einzige ACL und kannst alles vn der Routing-Engine, die teilweise in Hardware realisiert ist, erledigen lassen. Access-lists gehen in den meisten fällen über die CPU.