westberliner
Goto Top

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!

Content-Key: 327681

Url: https://administrator.de/contentid/327681

Printed on: April 19, 2024 at 18:04 o'clock

Member: brammer
brammer Jan 27, 2017 at 09:03:01 (UTC)
Goto Top
Hallo,

an beiden Standorten dieselben Netze zu nehmen für dazu das du NATten müsstest.
außerdem wüsstest du dann nie wo sich die IP jetzt gerade effektiv befindet...
Nimm für den 2. Standort 10.129.x.x dann fällt das NAT weg und due erkennst schon an der Adresse welcher Standort es ist

brammer
Member: aqui
aqui Jan 27, 2017 updated at 09:21:59 (UTC)
Goto Top
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.
Member: westberliner
westberliner Jan 31, 2017 at 20:27:01 (UTC)
Goto Top
Was mir gerade noch in den Sinn gekommen ist, mir aber praktische Erfahrung fehlt:

Brauche ich am Remotestandort evtl. doch einen DC mit DNS? Oder ist das bei der Anzahl User unkritisch, sodass diese dann sich die Infos übers VPN holen sollen?

Es wird vor Ort ebensowenig ein Fileserver wie auch Printserver stehen. Gerade beim letzteren bin ich am überlegen ob ich mir damit mein VPN nicht dicht mache und die Performance grottig wird...
Member: aqui
aqui Feb 01, 2017 at 09:14:54 (UTC)
Goto Top
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 face-sad
Wie soll man also eine hilfreiche und zielführende Antwort auf die Frage geben ohne Kristallkugel ?
Member: westberliner
westberliner Feb 01, 2017 at 09:27:12 (UTC)
Goto Top
Sorry das hier noch Infos fehlen.

Anbindung ist noch offen, ich plane mit min. 10MBit SDSL Company Connect - die Entscheidung liegt dabei bei der GF.
Druckvolumen liegt bei Schätzungsweise bis 500 Seiten pro Tag - evtl. noch mehr.
Member: westberliner
westberliner Feb 07, 2017 at 08:58:56 (UTC)
Goto Top
Ich habe gerade den Anruf von der Telekom bekommen - man könnte hier aufgrund der geringen Entfernung (ca 5-7km) auch mit Ethernet Connect arbeiten. Für mich hört sich das natürlich nach einer feinen Lösung an - da würde ich keine Firewall zusätzlich benötigen und wäre sozusagen in einem Netz.

Ist diese Lösung Erfahrungsgemäß vorzuziehen?
Member: brammer
brammer Feb 07, 2017 at 13:07:31 (UTC)
Goto Top
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
Member: aqui
aqui Feb 08, 2017 at 11:46:32 (UTC)
Goto Top
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.