5
Weigth-based routing?
Hallo,
Folgende Situation ist gegeben:
Ich habe ein funktionierendes Site-To-Site-VPN zwischen Firma (172.16.0.0/12) und AWS (10.1.0.0/16).
Nun müsste eine andere Firma ebenfalls ein Site-To-Site zum gleichen Netz in AWS aufbauen. Das Problem ist, dass deren internes Netz 172.18.0.0/16 hat, wie auch eines unserer Firma.
Traffic geht nur von den beiden Firmen in Richtung AWS, nicht von AWS in irgendein Firmennetz!
Und natürlich auch nicht von Fremdfirma zu Firma vice versa.
verm. Lösung 1:
Ich nehme an, dass man auf der Seite der anderen Firma das Gateway so konfigurieren kann, dass Traffic an das IPsec-Interface genattet wird, z.B. auf die 192.168.1.0/24. Auf AWS-Seite müsste das remote network für die VPN-Verbindung dann vermutlich auf 192.168.1.0/24 konfiguriert werden. Traffic muss nur von Fremdfirma nach AWS fliessen, andersrum ist nicht vorgesehen.
verm. Lösung 2:
Da die Fremdfirma nur ein paar Clients hat, die alle in das Netz 172.18.0.0/24 passen, wäre es doch bestimmt möglich, auf AWS-Seite mit einem Routing zu arbeiten, dass die Route 172.18.0.0/24->AWS-VPN-GW-FREMDFIRMA (2) höher gewichtet ist als die Route 172.16.0.0/12 -> AWS-VPN-GW-FIRMA (1).
Client A von Firma (172.18.60.1/16) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (1), da Route 172.16.0.0/12 aktiv.
Client AA von Fremdfirma (172.18.0.1/24) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (2), da Route 172.18.0.0/24 höher gewichtet.
Bei uns gibts keine Clients, die in der Range 172.18.0.1-254 liegen, daher sollte das keine Probleme geben.
Lösung zwei würde ich bevorzugen, wenn das machbar wäre, da dann auf das NAT in der Fremdfirma verzichtet werden könnte.
Kann man das so machen, insb. Lösung 2?
Vielen Dank schon mal!
EDIT: IP-Adressen nach RFC 1918 angepasst
Folgende Situation ist gegeben:
Ich habe ein funktionierendes Site-To-Site-VPN zwischen Firma (172.16.0.0/12) und AWS (10.1.0.0/16).
Nun müsste eine andere Firma ebenfalls ein Site-To-Site zum gleichen Netz in AWS aufbauen. Das Problem ist, dass deren internes Netz 172.18.0.0/16 hat, wie auch eines unserer Firma.
Traffic geht nur von den beiden Firmen in Richtung AWS, nicht von AWS in irgendein Firmennetz!
Und natürlich auch nicht von Fremdfirma zu Firma vice versa.
verm. Lösung 1:
Ich nehme an, dass man auf der Seite der anderen Firma das Gateway so konfigurieren kann, dass Traffic an das IPsec-Interface genattet wird, z.B. auf die 192.168.1.0/24. Auf AWS-Seite müsste das remote network für die VPN-Verbindung dann vermutlich auf 192.168.1.0/24 konfiguriert werden. Traffic muss nur von Fremdfirma nach AWS fliessen, andersrum ist nicht vorgesehen.
verm. Lösung 2:
Da die Fremdfirma nur ein paar Clients hat, die alle in das Netz 172.18.0.0/24 passen, wäre es doch bestimmt möglich, auf AWS-Seite mit einem Routing zu arbeiten, dass die Route 172.18.0.0/24->AWS-VPN-GW-FREMDFIRMA (2) höher gewichtet ist als die Route 172.16.0.0/12 -> AWS-VPN-GW-FIRMA (1).
Client A von Firma (172.18.60.1/16) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (1), da Route 172.16.0.0/12 aktiv.
Client AA von Fremdfirma (172.18.0.1/24) greift auf AWS-Datenbank zu (10.1.1.1) -> Rückroute über (2), da Route 172.18.0.0/24 höher gewichtet.
Bei uns gibts keine Clients, die in der Range 172.18.0.1-254 liegen, daher sollte das keine Probleme geben.
Lösung zwei würde ich bevorzugen, wenn das machbar wäre, da dann auf das NAT in der Fremdfirma verzichtet werden könnte.
Kann man das so machen, insb. Lösung 2?
Vielen Dank schon mal!
EDIT: IP-Adressen nach RFC 1918 angepasst
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: 62346840625
Url: https://administrator.de/contentid/62346840625
Printed on: June 18, 2024 at 12:06 o'clock
5 Comments
Latest comment
Hi
geht beides.
1) wäre 1to1NAT
2) ist einfaches Routing. Die "präziesere" Routinginfo gewinnt. Du routest 172.8.0.0/16 mit eurem Traffic auf euer gewünschtes Interface. Sofern 172.8.0.0/24 bei euch nicht verwendet wird kannst du das stinknormal mit der gleichen Prio/Distance einfach auf "deren" VPN-Interface routen. Das greift dann einfach deshalb weil es mit /24 die "genauere" Definition als das /16er Netz hat.
Alle anderen Netze in dem /16er gehen dennoch weiterhin auf euer Interface
geht beides.
1) wäre 1to1NAT
2) ist einfaches Routing. Die "präziesere" Routinginfo gewinnt. Du routest 172.8.0.0/16 mit eurem Traffic auf euer gewünschtes Interface. Sofern 172.8.0.0/24 bei euch nicht verwendet wird kannst du das stinknormal mit der gleichen Prio/Distance einfach auf "deren" VPN-Interface routen. Das greift dann einfach deshalb weil es mit /24 die "genauere" Definition als das /16er Netz hat.
Alle anderen Netze in dem /16er gehen dennoch weiterhin auf euer Interface
Danke für die schnelle Antwort. Das wollte ich hören!
Öffentliche IP Adressen die dir gar nicht gehören unrechtmäßig aktiv zu nutzen ist aber auch, gelinde gesagt, nicht die feine englische Art.
Wenn, dann solltest du immer die RFC Range 172.16.0.0/12 nutzen. Ansonsten wirst du immer und immer wieder Probleme mit der VPN Adressierung bekommen. Ggf. sogar rechtlich mit dem offiziellen Inhaber dieser Adressrange:
NetRange: 172.0.0.0 - 172.15.255.255
CIDR: 172.0.0.0/12
NetName: SIS-80-8-2012
NetType: Direct Allocation
OriginAS: AS7132
Organization: AT&T Corp. (AC-3280)
Spricht für mehr als schlampiges VPN IP Adressdesign im Vorfeld und hausgemachte Probleme.
Ob es dann zusätzlich auch noch besonders intelligent ist eine komplette /8er Range eines fremden IP Netzes in einem VPN zu routen obwohl es auch granularer ohne die /16er Range ginge, sei auch mal dahingestellt.
Das dann alles mit 1:1 NAT wieder hinfrickeln zu wollen spricht ebenfalls für sich...aber egal.
Sofern man die gruselige IP Adressieung mit unrechtmäßigen IP Adressen grundsätzlich mal außer Acht lässt.
Wenn, dann solltest du immer die RFC Range 172.16.0.0/12 nutzen. Ansonsten wirst du immer und immer wieder Probleme mit der VPN Adressierung bekommen. Ggf. sogar rechtlich mit dem offiziellen Inhaber dieser Adressrange:
NetRange: 172.0.0.0 - 172.15.255.255
CIDR: 172.0.0.0/12
NetName: SIS-80-8-2012
NetType: Direct Allocation
OriginAS: AS7132
Organization: AT&T Corp. (AC-3280)
Spricht für mehr als schlampiges VPN IP Adressdesign im Vorfeld und hausgemachte Probleme.
Ob es dann zusätzlich auch noch besonders intelligent ist eine komplette /8er Range eines fremden IP Netzes in einem VPN zu routen obwohl es auch granularer ohne die /16er Range ginge, sei auch mal dahingestellt.
Das dann alles mit 1:1 NAT wieder hinfrickeln zu wollen spricht ebenfalls für sich...aber egal.
Bei uns gibts keine Clients, die in der Range 172.8.0.1-254 liegen
Warum sparst du dann das 172.8.0.0 /24er Netz dann nicht ganz einfach aus in deiner eigenen VPN Peer Definition und weist es der anderen Firma zu? Problem gelöst und wäre ja noch einfacher.Sofern man die gruselige IP Adressieung mit unrechtmäßigen IP Adressen grundsätzlich mal außer Acht lässt.
Warum teilt ihr euch nicht 0.0.0.0/0?
Das würde alles viel einfacher machen.
Montag ist heute Freitag.
Das würde alles viel einfacher machen.
Montag ist heute Freitag.
2