Remotestandort anbinden - wie am besten realisieren
Hallo,
ich muss hier zeitnah (am besten schon vorgestern) einen Remotestandort aufgrund von Auslagerung der Tätigkeiten zu einem Dienstleister remote anbinden.
Ich habe mich dazu entschlossen quasi einen Remote-Standort zu machen und die Mitarbeiter dort in unserem System arbeiten zu lassen.
Doch nun bin ich am Planen wie ich das am Besten umsetze. Ist für mich absolutes Neuland und ich möchte hier nichts falsch machen.
Am Remotestandort geplant:
4-6 Workstations
6-8 MDE-Geräte
6 Accesspoints
1 Switch, L3-Fähig
1 Watchguard Firewall
1 Internetanbindung mit statischer IP
Der Plan war die zwei Standorte mit einem VPN zwischen den zwei Firewalls und einem weiteren VPN zum Rechenzentrum für das ERP-System zu verbinden.
Ich verwende hier den Netzbereich 10.128.80.0/20 - wobei hier überall /24 Subnetze verwendet werden für die einzelnen Geräteklassen wie z.B. Office, Server, Maschinen etc.
Zwischendrin habe ich noch einzelne Subnetze frei.
Jetzt stellt sich die Frage: Welche Subnetze soll ich am Remotestandort verbinden? Zwecks Routing sollte ich wohl den verwenden Bereich 10.128.80/20 meiden und einen eigenen Bereich hierzu verwenden wie bsp. 10.128.112.0/20 und dort dann entsprechende Subnetze für die Geräteklassen einrichten? Oder kann ich meine Subnetze vor Ort auf den Remotestandort ausweiten?
Die Accesspoints werden z.B. über einen WLAN-Controller gesteuert. Würde gerne die vom Remotestandort auch bei mir gerne mit einbinden, ebenfalls das AD/DHCP/DNS/PrinterServices nutzen, sodass Remote kein Server notwendig sein sollte.
Ich hoffe ich finde hier Hilfe.
Vielen Dank!
ich muss hier zeitnah (am besten schon vorgestern) einen Remotestandort aufgrund von Auslagerung der Tätigkeiten zu einem Dienstleister remote anbinden.
Ich habe mich dazu entschlossen quasi einen Remote-Standort zu machen und die Mitarbeiter dort in unserem System arbeiten zu lassen.
Doch nun bin ich am Planen wie ich das am Besten umsetze. Ist für mich absolutes Neuland und ich möchte hier nichts falsch machen.
Am Remotestandort geplant:
4-6 Workstations
6-8 MDE-Geräte
6 Accesspoints
1 Switch, L3-Fähig
1 Watchguard Firewall
1 Internetanbindung mit statischer IP
Der Plan war die zwei Standorte mit einem VPN zwischen den zwei Firewalls und einem weiteren VPN zum Rechenzentrum für das ERP-System zu verbinden.
Ich verwende hier den Netzbereich 10.128.80.0/20 - wobei hier überall /24 Subnetze verwendet werden für die einzelnen Geräteklassen wie z.B. Office, Server, Maschinen etc.
Zwischendrin habe ich noch einzelne Subnetze frei.
Jetzt stellt sich die Frage: Welche Subnetze soll ich am Remotestandort verbinden? Zwecks Routing sollte ich wohl den verwenden Bereich 10.128.80/20 meiden und einen eigenen Bereich hierzu verwenden wie bsp. 10.128.112.0/20 und dort dann entsprechende Subnetze für die Geräteklassen einrichten? Oder kann ich meine Subnetze vor Ort auf den Remotestandort ausweiten?
Die Accesspoints werden z.B. über einen WLAN-Controller gesteuert. Würde gerne die vom Remotestandort auch bei mir gerne mit einbinden, ebenfalls das AD/DHCP/DNS/PrinterServices nutzen, sodass Remote kein Server notwendig sein sollte.
Ich hoffe ich finde hier Hilfe.
Vielen Dank!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 327681
Url: https://administrator.de/forum/remotestandort-anbinden-wie-am-besten-realisieren-327681.html
Ausgedruckt am: 07.04.2025 um 13:04 Uhr
8 Kommentare
Neuester Kommentar
IP Adressdesign bei VPNs guckst du hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Fazit: IP Netze bzw. Subnetze in einem großen Netz müssen immer einzigartig sein !!
Da dein remotes Netz sehr klein ist kannst du ja auch problemlos einen /25 oder /26 er Prefix verwenden. Es würde ja Sinn machen remote wenigstens das WLAN und das LAN allein schon aus Sicherheitsgründen zu trennen. Ggf. noch mit einem Gast WLAN falls erforderlich was dann 3 Subnetze wären.
Mit deinem L3 fähigen Switch und VLANs ist das ja dann ein Kinderspiel. Wenn du mit einem /24er Prefix arbeitest wäre das dann recht einfach, denn den kannst du so als Summary Route nehmen für den remoten Standort, trennst das netz dort aber dann in /25 oder /26er Segmente. Du hast ja nicht mehr als 30 Endgeräte dort.
Diese simple Binsenweisheit lernt man aber auch schon als IT Azubi im ersten Lehrjahr oder in der Schule in der Informatik AG.
In so fern ist doch deine IP Adressierung vollkommen klar, oder ?
Kollege brammer hat absolut Recht oben. IP Adressgleichheit wäre tödlich in so einem Design. Inbound und Outbound NAT machen zu müssen nur weil man ein falsche IP Adresskonzept hat wäre absolut der falsche Weg. Mach die Adressierung gleich richtig, dann ist das ein Kinderspiel im Klicki Bunti GUI der Firewall.
Dadurch das du dein remotes Netzwerk ja problemlso übers Routing erreichst kannst du ALLE Komponenten dort natürlich auch via Routing erreichen. Deine Accesspoints inklusive. Das ist ja genau der tieferes Sinn eines VPNs !
Stell dir den VPN Tunnel einfach wie eine virtuelle Standleitung in den remoten Standort vor ! Genau so funktioniert der.
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Fazit: IP Netze bzw. Subnetze in einem großen Netz müssen immer einzigartig sein !!
Da dein remotes Netz sehr klein ist kannst du ja auch problemlos einen /25 oder /26 er Prefix verwenden. Es würde ja Sinn machen remote wenigstens das WLAN und das LAN allein schon aus Sicherheitsgründen zu trennen. Ggf. noch mit einem Gast WLAN falls erforderlich was dann 3 Subnetze wären.
Mit deinem L3 fähigen Switch und VLANs ist das ja dann ein Kinderspiel. Wenn du mit einem /24er Prefix arbeitest wäre das dann recht einfach, denn den kannst du so als Summary Route nehmen für den remoten Standort, trennst das netz dort aber dann in /25 oder /26er Segmente. Du hast ja nicht mehr als 30 Endgeräte dort.
Diese simple Binsenweisheit lernt man aber auch schon als IT Azubi im ersten Lehrjahr oder in der Schule in der Informatik AG.
In so fern ist doch deine IP Adressierung vollkommen klar, oder ?
Kollege brammer hat absolut Recht oben. IP Adressgleichheit wäre tödlich in so einem Design. Inbound und Outbound NAT machen zu müssen nur weil man ein falsche IP Adresskonzept hat wäre absolut der falsche Weg. Mach die Adressierung gleich richtig, dann ist das ein Kinderspiel im Klicki Bunti GUI der Firewall.
Dadurch das du dein remotes Netzwerk ja problemlso übers Routing erreichst kannst du ALLE Komponenten dort natürlich auch via Routing erreichen. Deine Accesspoints inklusive. Das ist ja genau der tieferes Sinn eines VPNs !
Stell dir den VPN Tunnel einfach wie eine virtuelle Standleitung in den remoten Standort vor ! Genau so funktioniert der.
Das kann man ja durch Raten schlecht beantworten, denn du hast mit keinem Wort erwähnt ob dort z.B. 3mal in einer Stunde gedruckt wird oder 300mal.
Ferner erwähnst du mit keinem Wort deine Bandbreite der Anbindung
Wie soll man also eine hilfreiche und zielführende Antwort auf die Frage geben ohne Kristallkugel ?
Ferner erwähnst du mit keinem Wort deine Bandbreite der Anbindung
Wie soll man also eine hilfreiche und zielführende Antwort auf die Frage geben ohne Kristallkugel ?
Hallo,
kann man machen.... aber.....
Vertraust du der Telekom?
Alles was du später zusätzlich brauchst oder ändern willst kostet extra...
Wenn z.B. mit VoIP zwischen den Standorten arbeiten willst dann kommt ein QoS dazu und dann kommst du mit dem Standard Angebot für etherconnect schon nicht mehr hin.
Ich würde VPN bevorzugen.
brammer
kann man machen.... aber.....
Vertraust du der Telekom?
Alles was du später zusätzlich brauchst oder ändern willst kostet extra...
Wenn z.B. mit VoIP zwischen den Standorten arbeiten willst dann kommt ein QoS dazu und dann kommst du mit dem Standard Angebot für etherconnect schon nicht mehr hin.
Ich würde VPN bevorzugen.
brammer
st diese Lösung Erfahrungsgemäß vorzuziehen?
Kann man machen allerdings ist die Frage vom Kollegen brammer berechtigt, denn der transparente Link ist eine MPLS VLL oder VPLS. Du bist also nur virtuell allein denn auf dem Router sind noch zig andere Kunden. Klar und logisch, denn die TCom wird nicht dedizierte HW nur für dich hinstellen.Außerdem solltes du niemals bridgen auch wenn du ein transparentes Ethernet bekommst. IMMER routen darüber !
Insofern brauchst du schon eine FW minimal aber ein L3 Device wie einen Switch.
Bridging ist immer kontraproduktiv also gleich vergessen am besten.
Ansonsten ist das technisch aber schon nicht falsch und kann man gut machen wenn man die o.a. Grundlagen beherzigt.
Wenn du unternehmenskritische Daten überträgst solltest du immer encrypten über den Link.
Wenn deine Switches Macsec supporten damit oder einfach mit IPsec dann.