Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Verständnissfrage mehrere Standorte

    Deutsch
    6
    23
    2.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      achim55
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • GruensFroeschliG
        GruensFroeschli
        last edited by

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

        We do what we must, because we can.

        Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

        1 Reply Last reply Reply Quote 0
        • JeGrJ
          JeGr LAYER 8 Moderator
          last edited by

          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

          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

          1 Reply Last reply Reply Quote 0
          • A
            achim55
            last edited by

            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ß

            1 Reply Last reply Reply Quote 0
            • O
              orcape
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • A
                achim55
                last edited by

                TOP  ;) ;) ;)

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

                Gruß

                1 Reply Last reply Reply Quote 0
                • JeGrJ
                  JeGr LAYER 8 Moderator
                  last edited by

                  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

                  Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                  If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                  1 Reply Last reply Reply Quote 0
                  • O
                    orcape
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator
                      last edited by

                      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

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      1 Reply Last reply Reply Quote 0
                      • S
                        shiversc
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • B
                          blex
                          last edited by

                          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

                          1 Reply Last reply Reply Quote 0
                          • A
                            achim55
                            last edited by

                            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ß

                            1 Reply Last reply Reply Quote 0
                            • O
                              orcape
                              last edited by

                              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

                              1 Reply Last reply Reply Quote 0
                              • A
                                achim55
                                last edited by

                                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ß

                                1 Reply Last reply Reply Quote 0
                                • O
                                  orcape
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    achim55
                                    last edited by

                                    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ß

                                    1 Reply Last reply Reply Quote 0
                                    • O
                                      orcape
                                      last edited by

                                      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
                                      1 Reply Last reply Reply Quote 0
                                      • A
                                        achim55
                                        last edited by

                                        supi, alles klar. ;)
                                        Besten Dank.

                                        1 Reply Last reply Reply Quote 0
                                        • First post
                                          Last post
                                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.