Verständnissfrage mehrere Standorte

achim55

Hallo,
ich möchte demnächst 4 Standorte per OpenVPN miteinander verbinden und habe dazu eine Frage.
Der Hauptsandort bekommt den OpenVPN Server. A,B und C die OpenVPN Clients, die sich dann mit dem Hauptstandort verbinden.

Soweit alles klar. ;)

Nur möchte ich auch untereinander auf die lokalen Netzwerke zugreifen können.
Zb. von A nach B usw.

Muss ich da irgendwelche routings einrichten oder klappt das sowieso, da die alle über den selben OpenVPN Server laufen ?

Hauptstandort 10.1.1.1
Standort A 192.168.10.254
Standort B 192.168.11.254
Standort C 192.168.12.254

Gruß

orcape

Hi,
die Frage ist, ob Du das so trennen willst, das auch einmal ein einzelnes Abschalten einer Verbindung, möglich ist.
1. Wenn Du alles auf "eine Karte setzen willst", d.h., ein Server aus, sämtliche Verbindungen tot, reicht ein Multiclienttunnel.
Beispiel: Server 10.8.8.1
Client 10.8.8.6
Client 10.8.8.8 etc.
Wenn nicht, baue für jeden Nebenstandort eine extra Instanz.
Hauptstandort 3 Server
Bsp: Server1 10.8.8.1
Server2 10.8.5.1
Server3 10.8.3.1
Die Clients in den Standorten dann jeweils die 10.8.x.2.
Dann brauchst Du nur noch unter "advanced" in der Server.conf, die entsprechenden Routing-Einträge zu definieren und kannst die Tunnel untereinander verbinden.
Gleichzeitig kann auch einmal ein Tunnel ausfallen oder gewartet werden, ohne die anderen Standorte zu beeinflussen.
Gruss orcape

achim55

Hi Orcape,
das macht Sinn mit den mehreren Instanzen.

Wo finde ich den unter Advanced die Server.conf ::)

Gruß

orcape

Wo finde ich den unter Advanced die Server.conf

"VPN - OpenVPN -Server - Advanced Configuration - Custom options"
Hier musst Du mit "route" und "push route" auf die jeweils anderen Tunnelnetze verweisen.
In Verbindung mit Einträgen unter "Client Specific Overrides" und den darin enthaltenen "Client-Settings", verweist das "iroute" auf das remote LAN.
Auf diese Weise sind alle Netze (unterschiedliche IP-Bereiche) per Tun-Device gekoppelt.
Dann brauchst Du nur noch an der Firewall entsprechend frei zu geben und der Zugriff klappt so, wie Du es gerne hättest.

shiversc

Soll es also ein vermaschtes oder vollvermaschtes Netzwerk werden? Für mich zum Verständnis!

Außerdem würde ich empfehlen die Standorte, wenn noch möglich so zu Sitzen:
A= 192.168.0.0/x
B= 192.169.0.0/x
C= 192.170.0.0/x

Macht später das Leben, Routen und wachsen einfacher.

achim55

Hi zusammen,
danke für die Infos. Ein vermaschtes sollte vollkommenem ausreichen.

In einem Standort steht ein Konnektor ( telematikinfrastruktur )
In den anderen Standorten die Kartenterminals die sich per IP mit dem Konnektor verbinden.
Und in dem letzten Standort dann der Server.

Ich muss nur dafür sorge tragen das die Kartenterminals den Konnektor erreichen und die ThinClients den Server.

Sollte kein Problem geben. Ansonsten müsste jeder Standort ein Konnektor bekommen.

GruensFroeschli

@shiversc:

Soll es also ein vermaschtes oder vollvermaschtes Netzwerk werden? Für mich zum Verständnis!

Außerdem würde ich empfehlen die Standorte, wenn noch möglich so zu Sitzen:
A= 192.168.0.0/x
B= 192.169.0.0/x
C= 192.170.0.0/x

Macht später das Leben, Routen und wachsen einfacher.

Ausser 192.168/16 sind das öffentliche Adressen.

Nach rfc1918 steht:
192.168/16
172.16/12
10/8
zur Vefügung.
Persönlich würde ich die Standorte im 10er Bereich ansiedeln.
Die Transfernetze zwischen den Standorten im 172er Bereich.

JeGr

Genau was der Frosch sagt. Wehe es nutzt jemand sowas wie 192.169 oder sowas hier. Dem hau' ich auf die virtuellen Finger! :P :D

Informiert euch gründlich über eure Netze! Denn die anderen sind bspw. vergeben. Nichts peinlicher als "warum komme ich auf diesen Service nicht drauf?" - "ömm ja das Netz nutzen wir intern für VPN…" - hatten wir schon bei einem Kunden. Das war den Verantwortlichen dann plötzlich sehr peinlich und ein Renumbering der Netze kann später lästig werden.

Beim OpenVPN Setup und weil ich wieder was von Advanced Config und Pushes lese: Bitte erstmal genau überlegen, was wer wo wie nutzen können soll. Zeichnen hilft. Und vorher überlegen. Genügt ein Stern? Brauche ich ein Mesh? Muss A mit B reden oder redet zu 99% A mit Zentrale und B mit Zentrale und alle Schaltjahre mal miteinander?
Wenn man das vorher abklärt und nicht nur "ui wäre praktisch" gibts gleich viel mehr Klarheit :)

Die Konfiguration würde ich sowieso empfehlen NICHT als Multi-Client->Server zu machen. Also NICHT EIN Server an Z und 3 Clients A, B und C die sich am gleichen Server einbuchen, sondern DREI Site2Site Tunnel einrichten.

Warum?

Es SIND Site2Site Verbindungen, dafür wurde der Modus gebaut ;)
Will man später Dinge wie bspw. Routingprotokolle à la OSPF zur Vereinfachung oder dynamischem Routing einbringen, geht das NUR mit S2S Modus, NICHT mit ClientServer
Bei MultiClient to Server Modus kann der Server die Rückrouten nicht ohne weiteres lernen (daher der obige Punkt) und man muss diese per ClientOverride o.ä. mitbringen. Das ist umständlich und erhöht die Komplexität

Downsides? Naja bei >10 Außenstellen hätte man somit an der Zentrale >10 Tunnel. Und für jeden eine Instanz. Das ist viel, sieht ggf. unübersichtlich aus, ABER: Man kann somit jeden Tunnel einzeln handeln, konfigurieren, neustarten, kaputt machen ohne die anderen zu betreffen. Bei MultiClient->SingleServer ist eine Änderung am Server ausreichend und jeder Client darf sich neu verbinden. Nicht so toll, gerade wenn über die Tunnel Dinge wie Replikationen oder AD Logins etc. laufen.

Zudem: OpenVPN läuft super - aber im Userspace, nicht im Kernelspace wie IPSec. Zudem potentiell stark Core-bound (also single core lastig). Verteilt man die Tunnel auf mehrere Server läuft jede Instanz potentiell auf einem anderen Core (wie viele man eben hat) - sprich: der ganze Salat skaliert besser. Hat man einen Server mit 3+ (oder 10+) Server läuft da EIN OpenVPNd der die ganze Zeit auf 100% rödelt, weil ihm ein oder zwei Tunnel den Rest geben und die restlichen Tunnel gehen mit unter, obwohl die nix für können.

Daher mein Tipp an der Stelle: macht Sharedkey Site2Site Tunnel mit OpenVPN zwischen jedem Verbindungspaar, dass ihr braucht, also ZA, ZB, ZC und ggf. AB/AC/BC was eben als nötig identifiziert wird. Ansonsten könnt ihr natürlich auch Traffic von A an B via Z routen. Bei Sharedkey S2S Tunnel wird dann einfach bei den Clients (A/B/C) als Remote nicht nur das Netz von Z sondern auch die Netze von A/B/C angegeben (was gebraucht wird). Wenn man die LANs von A, B und C natürlich schon geschickt gewählt hat und die OVPN Transfernetze ebenfalls, dann kann man das natürlich ganz entspannt mit einer größeren Maske machen und hat alles im Sack :D

Bspw.:

Z: 172.21.0.0/24
A: 192.168.101.0/24
B: 192.168.102.0/24
C: 192.168.103.0/24
TA: 10.168.101.0/24
TB: 10.168.102.0/24
TC: 10.168.103.0/24

TA/B/C sind die Transfernetze für OpenVPN.

Hat man solch ein Netzdesign ist es extrem einfach: Zentrale bekommt bspw. beim Tunnel Z<->A als LAN sein 172er Netz und als Remote das 192.168.101.0/24. Die A-Seite bekommt bei dem Tunnel dann die 192.168.101.0/24 als LAN und als Remote "172.21.0.0/16, 192.168.0.0/16".
Nanu? Warum? Genau, wenn die Zentrale mal mehrere VLANs intern nutzen will oder splittet, dann kann sie einfach 172.21.1/10/20/100.0/24 nutzen und die Remotes werden trotzdem die Netze durchs VPN routen. Und da wir zusätzlich (mehrere Netze mit Komma getrennt bei Remote möglich) noch das 192.168.x.y/16 routen, geht auch alles was B oder C Traffic ist automatisch durchs VPN zur Zentrale. Bekommt man irgendwann D muss nichts geändert werden, durch sinvoll große Netzmasken geht das schon automatisch ebenfalls durch und biegt in der Zentrale dann in den Tunnel zu D ab.

Tadaa

Saubere Netze können so viel Spaß machen :D

achim55

wow ;D besten Dank für die Info.

Habe ich das so jetzt richtig versandt ?
Der Hauptstandort bekommt drei OpenVPN Server mit denen sich jeweils ein Client verbindet.
Es sind doch dann automatisch Site2Site Verbindungen, oder ? ::)

Hauptstandort 172.21.0.0/24
Standort A 192.168.101.0/24
Standort B 192.168.102.0/24
Standort C 192.168.103.0/24

Die Tunnel:
TA: 10.168.101.0/24
TB: 10.168.102.0/24
TC: 10.168.103.0/24

Vor Ort sollten die Verbindungen dann so aussehen:

Standort A muss auf Standort B und den Hauptstandort zugreifen können.
Standort C muss auf Standort B und den Hauptsandort zugreifen können.
Der Hauptstandort muss auf Standort B zugreifen können.

Gruß

orcape

Habe ich das so jetzt richtig versandt ?

Richtig verstanden…. ;D
Ich habe zum Bsp. alle LAN-Netze im Bereich 192.168.xxx.xxx/24, alle Tunnel im Bereich 10.xx.xx.xx/24 und Sondernetze DMZ etc. im privat möglichen 172.16.xx.xx Netz.
So bleibt das alles schön übersichtlich und ist in den Routing-Tabellen sofort auf den ersten Blick erkennbar, um welches Netz es geht.

Es sind doch dann automatisch Site2Site Verbindungen, oder ?

So Du den Server entsprechend eingerichtet hast, ja.

achim55

TOP ;) ;) ;)

1000 Dank noch einmal an alle!!! Klasse Hilfe und super Board :) :)

Gruß

JeGr

Es sind doch dann automatisch Site2Site Verbindungen, oder ?

So Du den Server entsprechend eingerichtet hast, ja.

Nein. Wichtig beim Einrichten ist:

"Peer to Peer (Shared Key)"

als Server zu nutzen. Dieser kann - durch Shared Key - sich eh nur mit einer Gegenstelle verbinden. Ja natürlich bleibt es eine Server-Client Beziehung, aber nur in diesem Setup sind es eindeutig zwei Peers die Informationen austauschen und nur in diesem Setup ist dann später bspw. OSPF oder anderes Routing möglich.

Grüße

orcape

So Du den Server entsprechend eingerichtet hast, ja.

Nein. Wichtig beim Einrichten ist:

Dann ist das wohl keine Frage der Servereinrichtung, ob man im "Server Mode"….
"Peer to Peer (Shared Key)"
oder...
"Remote Access"
...einrichtet ??
Im übrigen muss nicht zwingend "Pre Shared Key" verwendet werden um routen zu können.
Auch in der Variante SSL/TLS ist das unter "Peer-to-Peer" möglich. Nur ist SSL/TLS sicherer und dadurch aufwändiger zu realisieren, wie "Pre Shared Key".
Man lernt halt immer dazu. ;)
Gruss orcape

JeGr

Der Kommentar bezog sich eher auf

Es sind doch dann automatisch Site2Site Verbindungen, oder ?

Und das ist nicht so. Nur weil ein Server aufgesetzt wird, ist es noch kein Site2Site.

Im übrigen muss nicht zwingend "Pre Shared Key" verwendet werden um routen zu können.

Für erweiterte Routing-Geschichten - so Aussagen von pfSense Supportern - schon. Das wurde u.a. in einem Hangout und in einem Tech-Stream definitiv benannt. Ja ich habe mich auch gewundert, ob P2P+SSL/TLS nicht auch geht. Prinzipiell bleibt es aber damit auch für den Einsatzzweck einfacher einzurichten. "Sicherer" lasse ich mal dahingestellt, denn ob ich nun Zertifikate austausche oder einen entsprechend großen PSK der jeweils nur in 2 Geräte kommt… Nunja. Faktisch gibt es aber PDFs und Unterlagen, in denen konkret davor gewarnt wird, ein anderes Setting zu nutzen wenn später noch erweitertes Routing bspw. via RIP/OSPF/Mesh/whatever genutzt wird.

Grüße

shiversc

@GruensFroeschli:

Ausser 192.168/16 sind das öffentliche Adressen.

Nach rfc1918 steht:
192.168/16
172.16/12
10/8
zur Vefügung.
Persönlich würde ich die Standorte im 10er Bereich ansiedeln.
Die Transfernetze zwischen den Standorten im 172er Bereich.

Ja, war ein Beispiel. Ein blödes Beispiel.
Ich wollte eigentlich was anderes rüber bringen

Die ganzen /24 Netzwerke finde ich eher hinderlich. Wenn du später irgendwo noch ein Netz brauchst, ich finde ein Netz pro Standort sowieso etwas merkwürdig, dann macht man sich unnötig Arbeit.

Wenn ich an Standort A folgendes z. B. veranschlage:

10.0.0.0/16

Dann habe ich dort alle Netze von 10.0.0.0 bis 10.0.255.255.
Eine Route bzw die Default Route und ich bin im Geschäft.

Standort B:
10.1.0.0/16
Standort C:
10.2.0.0/16

usw… usw...

Am Standort muss ich dann natürlich nicht mit den ganzen Netzen Arbeiten, die Anzahl kann ich an der pfSense oder am folgenden Router begrenzen. Muss man jedoch nicht, weil es schadet nicht.

blex

Hi,

auch wenn ich jetzt vielleicht geschlachtet werde…

Darf ich fragen WIESO es ein OpenVPN sein muss. Was du hier bisher beschrieben hast ist doch ein klassisches Sites-2-Site VPN. Das kann man auch mit IPSec aufbauen.
Ich frage einfach mal ist OpenVPN hier eine zwingende Vorgabe oder kannst du auch IPSec nutzen. Falls ja solltest du dir das vielleicht mal überlegen, da hier die ganzen Transportnetze wegfallen.

Frei nach dem Motto "keep it simple".

Gruß blex

achim55

Hi , openvpn muss es nicht unbedingt sein. Ich dachte das es nur einfacher sei als IPSec.
Mir geht es hauptsächlich darum das ich die Standorte miteinander verbinde.

Ich habe auch noch eine Frage zu dem routing ( "VPN - OpenVPN -Server - Advanced Configuration - Custom options")

Muss ich bei allen 3 OpenVPN Servern das Routing eintragen, und welche IP, die vom Tunnel oder die IPv4 Remote network(s) ?

Z.b. so ! :

push route 192.168.101.0 255.255.255.0
push route 192.168.102.0 255.255.255.0
push route 192.168.103.0 255.255.255.0

Gruß

orcape

Hi,

Muss ich bei allen 3 OpenVPN Servern das Routing eintragen, und welche IP, die vom Tunnel oder die IPv4 Remote network(s) ?

Hier folgen die Einträge eines OpenVPN-Servers 10.10.8.1 (Instanz1)….

push "route 172.16.7.0 255.255.255.0";  (DMZ-Netz hinter dem Server/an pfSense)
push "route 10.15.8.0 255.255.255.0";  (OpenVPN-Netz, Remoter Client, von Netz 10.10.8.0/24 erreichbar)
route 10.15.8.0 255.255.255.0;      (OpenVPN-Netz, Remoter Client, von Netz 10.10.8.0/24 erreichbar)

Hier ein Bsp. einer Server-Einzel-Client (Instanz3)…..


push "route 172.16.7.0 255.255.255.0";   (DMZ-Netz hinter dem Server/an pfSense)
push "route 10.10.8.0 255.255.255.0";     (OpenVPN-Netz Instanz1)
push "route 192.168.55.0 255.255.255.0"; (LAN hinter Client Instanz1)
push "route 10.12.7.0 255.255.255.0";     (OpenVPN-Netz Instanz2)
push "route 192.168.18.0 255.255.255.0"; (LAN hinter Client Instanz2)
route 10.10.8.0 255.255.255.0; (Route zu Instanz1)
route 192.168.55.0 255.255.255.0; (Route zu LAN hinter Client1)
route 10.12.7.0 255.255.255.0; (Route zu Instanz2)
route 192.168.18.0 255.255.255.0; (Route zu LAN hinter Client2)

Zur kurzen Erklärung…
Instanz3, Laptop-OpenVPN-Client hat von Remote Zugriff auf pfSense (Hauptstandort/DSL-Anschluss) sowie einen Server hinter der pfSense in der DMZ und auf die OpenVPN Instanzen1 und 2 und deren remote Netze.
Von den remoten LAN-Netzen, ist ein Zugriff auf den Server am Hauptstandort im DMZ-Netz vorgesehen.
Gruss orcape

achim55

okay danke, ;)
und wie muss ich das Routing eintragen wenn ich die Variante mit openvpn nutze ?

Die Einträge sind doch wenn ich IPSec als VPN Servern nehme, oder?

Gruß

orcape

Die Einträge sind doch wenn ich IPSec als VPN Servern nehme, oder?

Ich nutze zur Zeit ausschliesslich OpenVPN und das sind die Einträge für den Server bzw. die Server.
Mit IPSec wird das "SO" nicht funktionieren.