OPENVPN und mehrere Standorte
-
supi, jetzt hat es geklappt :-)
Besten Dank für die Hilfestellung -
Weil bei solchen Multi-Point VPN Geschichten immer wieder die gleichen Fragen/Argumente für oder gegen eine bestimmte Variation des Aufsetzens mit OpenVPN kommt wie bspw. @Gladius
Ja, man kann das ganze natürlich mit einem einzelnen Server auf einem Port abdecken und muss dann nicht 3 VPN Server Instanzen (in diesem Fall in der Loc. RE) pflegen. Kann man. Und die pfSense Doku schreibt das auch konkret.
Aber: Die Doku schreibt auch ganz konkret wie es mit der Shared Key Methode läuft und dass diese eine andere Art und Alternative dazu ist. Die Vorteile überwiegen gerade in einem Datacenter Setup dabei für mich gerade deshalb weil:
- Nur mit Shared Key meines Wissens bislang FRR/Quagga möglich ist (OSPF und Co. für einfacheres Routing oder Failover)
- Mit 3 Server Instanzen Multicores (gerade in DC Umgebungen stehen da meistens nicht gerade Miniatur Router) sinnvoller genutzt werden können. Gerade bei 3 Site2Site Tunnel mit ordentlich Traffic ist dadurch bessere Nutzung der CPU möglich, ohne bei 3 ausgealsteten Verbindungen gleich einen einzelnen Kern zum Glühen zu bringen
- "Ausfall" eines Servers per se ist eher ungewöhnlich, was aber gar nicht so ungewöhnlich ist, sind Änderungen die an einer Verbindung vorgenommen werden müssen, die einen spezifischen Tunnel betreffen. Dann macht es absolut Sinn, dass ich nur diese Verbindung editieren muss und dann entsprechend nur dieses Ende neu starte während alle anderen Verbindungen sauber weiter laufen.
Dazu kommt dass bei einem Shared SSL/TLS Setup mit 3 "Clients" man gerade bei komplexen Routings durch die IRoutes (also client specific overrides und Co.) wieder so viel Zusatzkonfiguration hat, dass der Gewinn - nur einen Tunnel zu haben - fast schon wieder aufgeraucht wird. Gerade wenn man nicht nur Verbindungen des Typs Client(s) -> Server Netzwerk hat, sondern aus dem Server Standort auch auf die Clients muss, müssen Routen umständlich eingepflegt werden und man hat auch nicht die Möglichkeit, jede Verbindung einzeln (als Interface) mit Regeln zu bestücken.
Daher für mich (wie gesagt hauptsächlich bei Firmen- oder DC/RZ Verbindungen mit mehreren Tunneln) nach wie vor das sinnvollste Setup mit einzelnen Tunneln pro Site. Das sind aber natürlich nur meine Gründe und 2 Cent, da darf jeder seinen eigenen Euro reinwerfen und das anders machen
-
@jegr said in OPENVPN und mehrere Standorte:
Daher für mich (wie gesagt hauptsächlich bei Firmen- oder DC/RZ Verbindungen mit mehreren Tunneln) nach wie vor das sinnvollste Setup mit einzelnen Tunneln pro Site.
Danke für diese Hinweise. Da spricht ein Mann mit viel Erfahrung zum Einsatz von OpenVPN im Firmenumfeld.
Die genannten Vorteile mehrerer Tunnel-Instanzen hatte ich als privater Anwender nicht so im Blickfeld,
wobei ich die bessere Lastverteilung schon gesehen habe.LG
-
@gladius War auch gar nicht konkret als Kritik gedacht, sondern eher als Aufklärung, warum das heute durchaus noch die favorisierte Variante sein kann, wenn man mit größeren Strukturen murmeln "darf"
Ist auch nicht wirklich sooo schön, wenn man da bspw. für 20 Außenstellen 20 Tunnel aufbauen und konfigurieren muss, vor allem wenn die dann noch crossover verbunden sind. Aber gerade dadurch - und bei Tunnel Anzahlen von >4 - lohnt sich das oft schon alleine deshalb, um einen Multicore besser auszunutzen. Auch wenn man meistens nicht unbedingt die mega Bandbreiten schaufelt, addiert sich dann doch bei ~20 Links auf einem 4-Kerner die Last pro Kern (5 Tunnel pro Kern) durchaus zusammen. AES-GCM hilft da aber schonmal - wenn man beide Enden kontrolliert und aktuell hält. Inzwischen ist aber auch wieder IPSEC dank routbarem Interface eine veritable Alternative geworden (die wir aber noch testen müssen).