Verständnissfrage mehrere Standorte



  • 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ß



  • 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



  • Hi Orcape,
    das macht Sinn mit den mehreren Instanzen.

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

    Gruß



  • 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.



  • 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.



  • 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.



  • @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.


  • Moderator

    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



  • 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ß



  • 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.



  • TOP  ;) ;) ;)

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

    Gruß


  • Moderator

    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



  • 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


  • Moderator

    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



  • @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.



  • 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



  • 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ß



  • 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



  • 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ß



  • 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.



  • Hi, ich habe es jetzt so verstanden das ich bei jedem Server die IP von den Standorten und Tunnel eintragen muss ::)

    Das push route ist dafür das das LAN von dem Standort erreichbar ist und das Route dann quasi für die Geräte die sich in dem LAN befinden?

    Z.b so:

    push "route 192.168.101.0 255.255.255.0"; (LAN Standort A)
    push "route 192.168.102.0 255.255.255.0"; (LAN Standort B)
    push "route 192.168.103.0 255.255.255.0"; (LAN Standort C)
    route 192.168.101.0 255.255.255.0; (Route zu LAN hinter Client1)
    route 192.168.102.0 255.255.255.0; (Route zu LAN hinter Client2)
    route 192.168.103.0 255.255.255.0; (Route zu LAN hinter Client3)
    push "route 10.168.101.0 255.255.255.0";    (OpenVPN-Netz Tunnel TA )
    push "route 10.168.102.0 255.255.255.0";    (OpenVPN-Netz Tunnel TB )
    push "route 10.168.103.0 255.255.255.0";    (OpenVPN-Netz Tunnel TC )
    push "route 192.168.18.0 255.255.255.0"; (LAN hinter Client Instanz2)


    Netzwerke vor Ort:
    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


    Gruß



  • Du musst in den Server-Instanzen sowohl die Routen zur jeweils anderen Server-Instanz definieren, sowie die Routen auf dessen Remotes-LAN. Außerdem die Route in der jeweiligen Instanz pushen, um auf Dein LAN am Hauptstandort, (LAN-pfSense) zu kommen.
    Also in der Instanz TA…TA: 10.168.101.0/24

    
    push "route 172.21.0.0 255.255.255.0";  (um von remote Dein Netz am Hautstandort zu erreichen)
    push "route 10.168.102.0 255.255.255.0"; (Tunnel2)
    push "route 192.168.102.0 255.255.255.0"; (Client-LAN2)
    push "route 10.168.103.0 255.255.255.0"; (Tunnel3)
    push "route 192.168.103.0 255.255.255.0"; (Client-LAN3)
    route 10.168.102.0 255.255.255.0; (Tunnel2)
    route 192.168.102.0 255.255.255.0; (LAN Standort2)
    route 10.168.103.0 255.255.255.0; (Tunnel3)
    route 192.168.103.0 255.255.255.0 (LAN Standort3)
    
    Das in den anderen Instanzen ebenfalls, natürlich mit entsprechend modifizierten IP-Bereichen.
    
    Dann unter "Client-Specific-Overrides eine CCD anlegen und unter "advanced" dem Client die Verweise auf das Client-LAN mit dem...
     [code]iroute 192.168.101.0 255.255.255.0; [/code] z.B.  für die erste Instanz mitgeben.
    Ohne diese CCD kann es Probleme beim Zugriff auf das remote LAN geben.
    
    Je nachdem, wohin Du die Verbindungen wünschst, lässt sich das natürlich auch problemlos modifizieren und nur einzelne Rechner freigeben ist auch kein Problem.
    Firewallregeln nicht vergessen, sowohl am WAN wie auch unter OpenVPN.
    Gruß orcape
    


  • supi, alles klar. ;)
    Besten Dank.