Kleines Firmennetzwerk mit VPN - was wird benötigt?

zap1337

Enthusiast
Thread Starter
Mitglied seit
29.08.2007
Beiträge
8.923
Ort
Stuttgart
Hallo ihr Lieben,

ich habe eine Frage, vielleicht könnt ihr mir helfen.

Für ein Miniunternehmen soll ein neues Firmennetzwerk eingerichtet werden.

Das sind die Hard-Facts:

- 4 Standorte.
- Hauptstandort hat eine fest IP.
- Jeder Standort hat nur einen Rechner.
- Auf jeden Rechner läuft das Warenwirtschaftsprogramm (nein kein SAP, irgendwas kleines unbekanntes).
- Das Warenwirtschaftsprogramm ist Server-Client basierend.

Ziel:

Die Warenwirtschaftssysteme sollen an allen Standorten synchronisiert werden.

Mein Plan:

Server am Hauptstandort mit der Server-Version v. Warenwirtschaftssystem + VPN Server.

An den anderen Standorten:

Clients mit VPN-Verbindung zum Hauptstandort.


Ist die Denkweise richtig?

Was wird HW + SW benötigt?

1. VPN Router mit VPN passthrough (IPSec/​PPTP/​L2TP/​SSL)?
2. Server mit Windows Server 20XX? (Was hier am besten benutzen?) Welche VPN Software?

Was ist eine kostengünstige Lösung? Worauf muss ich achten?

LG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
VPN terminiert man auf einem dediziertem VPN Gateway!
An allen Standorten jeweils einen NETGEAR ProSafe™ Gigabit 8 Port VPN Firewall FVS318N

Für alle Standorte jeweils ein Site2Site VPN zum Hauptstandort einrichten.
Das geht auch hinter einem eventuell vorhandenem Provider Router (T-Com. Vodafone, Fritzbox etc.) sofern mindestens eine Seite eine DMZ bzw. das VPN_Gateway am Router als exposed Host definiert werden kann. (Mit Port und Protokollforwarding geht es prinzipiell auch, mir ist aber bislang kein Providerrouter untergekommen, bei dem ich sowas einrichten konnte - es fehlt meistens die Protokollweiterleitung.) Nur dann kann das VPN-Gateway als "Responder" agieren - also eingehende VPN Verbindungen annehmen.
Noch einfacher wird's, wenn die Providergeräte als Modem fungieren (können).

Wichtig: Alle lokalen Netze müssen sich unterscheiden (Netzadresse/Netzmaske), da eine "nested Konfiguration" nicht erlaubt ist.
Die Standorte könnnen sich untereinander nicht sehen. (Man kann natürlich das ganze auch vermaschen, in dem jeder Standord zu jedem Standort ein VPN Aufbaut, falls das notwendig werden sollte.)

Frage: ist die WaWi wirklich eine "echte" Client/Server Anwendung?
D.H. Es wird tatsächlich eine Clientanwendung lokal auf dem Rechner installiert?
Es gibt nämlich auch "Pseudo" Client-Server-Anwendungen, bei denen die komplette Anwendung über's Netzwerk gestartet wird (meist von einem gemappten Netzwerklaufwerk) - also nicht nur der reine Datenbankverkehr über's Netz muss.
Das solltest du auf jeden Fall klären, weil daß könnte ja nach Verbindungsgeschwindigkeit an den Standorten schon der Todesstoß für ein deratiges Vorhaben sein.
Als nächstes wäre zu klären, was da für ein Backend dahinter hängt.
z.B. Access, Sybase ADS (Advantage-Database-Server) sind nicht gerade performante Backends - soll heissen, man muß das Testen, ob die Performance überhaupt ausreicht.
MySQL, MSSQL, MariaDB sind auf jeden Fall deutlich performanter.
 
Zuletzt bearbeitet:
Finde ich mit Kanonen auf Spatzen geschossen... Für die paar Rechner würde ich zentral ein VPN-Gateway aufstellen (und sei es OpenVPN) und auf den Clients an den Sites dann einfach die Verbindung zur Mainsite aufnehmen. Da brauchts dann auch keine spezielle Hardware, dürfte für den Use-Case aber vollkommen ausreichen.

Ich mein klar kann man alles mit Hardware und Geld erschlagen - für die genannte Anzahl an Systemen ist das aber einfach nicht nötig, außer ihr habt vor da in Zukunft noch mehr Rechner an den jeweiligen Sites in Betrieb zu nehmen.
 
Zuletzt bearbeitet:
Finde ich mit Kanonen auf Spatzen geschossen... Für die paar Rechner würde ich zentral ein VPN-Gateway aufstellen (und sei es OpenVPN) und auf den Clients an den Sites dann einfach die Verbindung zur Mainsite aufnehmen. Da brauchts dann auch keine spezielle Hardware, dürfte für den Use-Case aber vollkommen ausreichen.

Ich mein klar kann man alles mit Hardware und Geld erschlagen - für die genannte Anzahl an Systemen ist das aber einfach nicht nötig, außer ihr habt vor da in Zukunft noch mehr Rechner an den jeweiligen Sites in Betrieb zu nehmen.
Für Privat gebe ich dir unumwunden recht!

Es geht hier aber um ein Unternehmen, da sollte man sowas schon auf vernünftige Beine stellen!
Vorteil meiner Lösung: es ist vollkommen Transparent an den Standorten und es könne jederzeit weiter PC dazukommen, ohne daß VPN-technisch was geändert werden muß.

Um deine Lösung aufzugreifen:
Nur 1 Gateway am Hauptstandort hinstellen und an den Aussenstellen die VPN Verbindung per VPN-Clientsoftware herstellen (Client2Site VPN). Wobei die Clientsoftware (Netgear oder TheGreenBow) auch was kostet (die Kostenlosen Clients habe ich alle getestet, es funktioniert nicht stabil genug.)

Ein FVS318N kostet ca. 180 € und wäre nur einzurichten.

Alternative Selbstbau:
Ein Dell T20 kostet mit Cashback ca. 140 €, 'ne 2. Netzwerkkarte (Firewall) kommt dazu und man müsste den selber installieren (Debian, Open VPN, Firewall z.B. sophos etc.).
Der RasPi dürfte Leistungstechnisch hierfür natürlich auch ausreichen, müsste aber um eine 2. Netzwerkarte erweitert werden.
Eine Firewall mit nur einer Netzwerkkarte ist in meinen Augen witzlos.
 
Zuletzt bearbeitet:
Das mit dem Kanonen und den Spatzen ist immer relativ.

Ich würde auch ein Multi-Side-to-Side VPN aufbauen.

So hat man eine unabhängige Lösung, muss nichts ändern, wenn ein neuer PC kommt. (alter raus, neuer rein oder komplett neu)
Und man kann sämliche anderen Geräte im Netzwerk erreichen. z.B. auch eine VoIP-TK-Anlage, wo offside nur noch das Telefon steht.
Weiterhin kann man mit Intel AMT-Geräten auch einen direkten Support über das VPN abfahren. Bis runter auf Neuinstallation des OS. (am besten mit einer Backup-HDD, wegen 10GB Image Restore)
Somit kann ein Offside Support auch support geben ohne vorbeizufahren.

Und es gibt auch noch andere Vorteile.

VPN-Software Client hat nur den Preisvorteil, der sich schnell relativiert.

1x DrayTek Vigor 2925 Preisvergleich @mainoffice
3x DrayTek Vigor2120 Preisvergleich @offside

Letzterer kann sogar noch einen 2. Tunnel aufbauen zu einem 2. Standort oder einem Server in einem Rechenzentrum, falls das mal interessant werden sollte.
Ansonsten kommt man mit 3 einzelnen "Leitungen" locker hin.
So kommt man auf 500EUR für die Router. Hinzu kommen noch Modems (wenn kein Modem vorhanden ist) und die Einrichtung.
Ansonsten kann man auch z.B. Fritzbox IPSEC nach Draytek IPSEC machen. Spart kosten, hat man dann aber ne FB für Geschäftsanwendungen. (nicht so mein Fall)

Ich würde zusehen, die VPN-Gateway auch direkt zu betreiben. Sprich kein Router davor. Falls das nicht geht, eine Lösung finden. Mindestens aber den Main direkt ans Inet hängen.
Etwaige Fritzboxen für den Telefonanschluss man man auch hinter dem Router betreiben.

Auf dem Server halt die Software die drauf soll. Kein VPN-Server, das machen die Gateway. Macht den Server schlank und koppelt das VPN auch vor etwaigen Servercrashes ab. (wenn z.B. noch VoIP laufen soll)

@digi
Die Standorte könnnen sich untereinander nicht sehen. (Man kann natürlich das ganze auch vermaschen, in dem jeder Standord zu jedem Standort ein VPN Aufbaut, falls das notwendig werden sollte.)
Warum sollten die sich nicht sehen können? Dazu braucht man keinen Maschen bilden. Einfach auf dem Mainrouter entsprechende Routen einrichten.
Mit RIP (default @Draytek) geht das sogar outof the box. Also InterVPN-Routing kein Problem.
(muss man wissen, ob man das will)


EDIT:
Ich habe selber ein VPN-Dreieck (jeder hat also 2 VPNs) als side-to-side mit den Draytek 2925n. Bin wunschlos glücklich. Einrichtung in 5mins erledigt.
(Wer mehr will, muss auch mehr einstellen)
Das VPN ist stabil und baut sich auch immer wieder auf, wenn was war. Firmwareupdates kommen nach. (muss jeder wissen, wann/ob er updatet)
Habe mir erst gestern einen 4. als Ersatz beschafft.

Das geht natürlich auch mit anderen SoHo-Geräten. Aber auf SoHo und diese Art der Verbindung würde ich nicht verzichten. Wenn die Leute 2h nicht arbeiten können, hat man die 100EUR für ein VPN-Gateway drin. Kann man ja mal rechnen.

PS: Den Fehlerfall nicht vergessen. (Ersatzgerät, Notfallstrategie etc)
 
Zuletzt bearbeitet:
Warum sollten die sich nicht sehen können? Dazu braucht man keinen Maschen bilden. Einfach auf dem Mainrouter entsprechende Routen einrichten.
Mit RIP (default @Draytek) geht das sogar outof the box. Also InterVPN-Routing kein Problem.
(muss man wissen, ob man das will)
Hmmm, ich habe auf meinem Gateway RIP ausgeschaltet, weil ich die "Spinne im Netz" bin - habe 4 VPNs zu unterschiedlichen Kunden, die sollen sich natürlich nicht sehen.
Ich will das jetzt auch nichtmal testweise einschalten :-)

Das geht natürlich auch mit anderen SoHo-Geräten. Aber auf SoHo und diese Art der Verbindung würde ich nicht verzichten. Wenn die Leute 2h nicht arbeiten können, hat man die 100EUR für ein VPN-Gateway drin. Kann man ja mal rechnen.

PS: Den Fehlerfall nicht vergessen. (Ersatzgerät, Notfallstrategie etc)
Mein Reden!
Die Geräte von Draytek kenne ich (noch) nicht.
Bei den Netgears funktioniert es halt auch über doppeltes NAT via "Provider-Router"! (mehrfach im Einsatz)
 
Hallo,

vielen Dank für die ausführliche Antworten.

Soweit ich das rauslesen kann, ist die 'professionellere Lösung' über VPN Gateways zu gehen. Diese müsste man nur einmalig kaufen und einrichten und benötigt dann keine Soft-VPN oder VPN-Provider mehr. Vorteil ist auch die Sicherheit und dass die Uptime des VPN-Netzwerkes unabhängig vom Server sind. Auf dem Server würden dann nur noch die WiWa-Software und andere Server Software installiert, falls vorhanden und benötigt.

Den Router des Internetproviders am jeweiligen Standort hängt man einfach nur dran, ist das korrekt?

Habe ich das richtig verstanden?

Edit: Könnte man noch ein NAS mit Raid für Backups ans VPN Gateway hängen? Oder würdet ihr das auf dem Server lösen?
 
Zuletzt bearbeitet:
Grob ja.

Der Mainstandort muss über eine öffentliche v4 IP verfügen.
Router hinten dran geht dann, wenn es kein Kabelmodemrouter ist. An den kann/muss man das offsideVPN auch hintendran hängen.

Bei DSL würde ich ein separates DSL-Modem vor das VPN-Gateway bauen. (selbiges auch bei Kabel, sofern das möglich ist, 1.8. Routerzwangsende)
Du kannst alles mögliche in dein Netz hängen.
Das VPN-Gateway stellt ja auch nur ein internes Netz bereit, das du so groß aufbauen kannst, wie du magst.

Generell würde ich den Server als Server nutzen (sprich also auch die Daten von offside da speichern), also auch für Daten allgemein.
Ein NAS ist nur bedingt als Backup geeignet. Du solltest dir eine geeignete Backupstrategie überlegen. Dafür gibt es geeignete Mittel.

Einfaches Beispiel. Wenn da der Blitz reinwandert, kannst du den Server und das NAS in die Tonne treten. Wo war nochmal das Backup?
 
Zuletzt bearbeitet:
Backup:
Je nach Datenvolumen kann man auch das NAS auch an einem Anderen Standort unterbringen - und schon wäre das Argument Bltzschlag ausgehebelt...

Wichtig ist hier erstmal ein Backupkonzept/eine Backupstartegie zu haben.
Was muß wie oft gesichert werden, ist Versionierung notwendig, Wieviele Backupgenerationen will man haben etc. pp.
 
Ein ständig im Zugriff befindliches NAS ist alles, aber kein Backup und schon gar kein Konzept.
 
Ein ständig im Zugriff befindliches NAS ist alles, aber kein Backup und schon gar kein Konzept.
Ein Backup ist erstmal eine Sicherheitskopie von Daten, nicht mehr und auch nicht weniger!
Und im Zugriff ist das ggf. auch nur für den Benutzer "Backup", für den keine interaktive Anmeldung gestattet ist.
Anwender XYZ hat auf dem NAS gar keinen Zugriff, kann also auch nichts verschlüsseln!

Das Backup von der vorherigen Nacht , welches Mittags vom Chef im Banktresor deponiert worden ist, ist wunderbar und erfüllt sicherlich alle deine Ansprüche an ein Backup!
Dieses hilft aber am Freitagnachmittag um 16:15 gar nichts, wenn der Server abgeraucht ist und ein Restore erforderlich ist. Die Mitarbeiter wollen am Samstag Morgen wieder arbeiten (oder auch am Montag Morgen).

Deswegen:
Wichtig ist hier erstmal ein Backupkonzept/eine Backupstartegie zu haben.
Was muß wie oft gesichert werden, ist Versionierung notwendig, Wieviele Backupgenerationen will man haben etc. pp.
Wenn man von einer Datenbank Stündlich 'nen Snapshot sichert, macht man das mit Sicherheit nicht als Offline Backup!
 
Zuletzt bearbeitet:
Wenn man von einer Datenbank Stündlich 'nen Snapshot sichert, macht man das mit Sicherheit nicht als Offline Backup!

Vollkommen korrekt, da ein Snapshot nichts direkt mit Backups zu tun hat.
Ein Snapshot ist eine Versionierung eines Standes X eines Objektes und nichts weiter.
Das gilt für Datenbanken, für Files, für VMs usw.

Ein Snapshot ist die Grundlage eines Backups, aber stellt selber keins dar.

EDIT:
Backup:
Je nach Datenvolumen kann man auch das NAS auch an einem Anderen Standort unterbringen - und schon wäre das Argument Bltzschlag ausgehebelt...

Das ist nur dann ausgehebelt, wenn der Ort blitzschlagsfrei wäre. Das gilt eigentlich nur in Bunkeranlagen mit eigener Stromgenerierung. Ansonsten ist nur der gleichzeitige Blitzeinschlag ausgehebelt, wenn die Standorte entsprechend weit auseinander liegen.
Blitzschlag ist nur ein kleiner Teil der Sachen die ein NAS gegenüber eines Offline Backups als Nachteil hat.

Ein NAS ist nur unter ganz bestimmten (wenigen) Szenarien ein geeignetes Backup. Regelmäßig allenfalls für extrem große Datenmengen oder sehr kurze Zyklen. (wobei selbst bei letzterem ein längerfristiges Backup angefertigt werden sollte)
 
Zuletzt bearbeitet:
Und im Zugriff ist das ggf. auch nur für den Benutzer "Backup", für den keine interaktive Anmeldung gestattet ist.
Anwender XYZ hat auf dem NAS gar keinen Zugriff, kann also auch nichts verschlüsseln!
Wieso bringst Du jetzt Verschlüsselung ins Spiel? Alle meine Daten - auch die Backups - sind verschlüsselt. Ist das jetzt schlimm?

und erfüllt sicherlich alle deine Ansprüche an ein Backup!
Verstehe ich nicht - seit wann geht es um mich bzw. meine Ansprüche? Habe ich da was verpasst?

Ich habe lediglich darauf hingewiesen, das ein NAS kein Backup-Konzept ist oder gar eines ersetzt. Erkläre uns doch bitte deine verwirrte Reaktion auf diese IMHO korrekte Feststellung!
 
Ein (oder eher mehrere) NAS(oder seine ausgewachsenen Brüder und Schwestern) können ein Backup darstellen. Es gibt Szenarien, wo es einfach nicht geht sowas zeitgerecht auf DVD oder Band zu kopieren.
Ein "Cloud"-Backup ist ja auch nichts anderes.

Allerdings denke ich, dass wir in dem Fall mit den "klassischen" Methoden auskommen sollten.
 
Wieso bringst Du jetzt Verschlüsselung ins Spiel?
beantworte ich mal mit deinem Argument
Ein ständig im Zugriff befindliches NAS ist alles, aber kein Backup und schon gar kein Konzept.
Und da Verschlüsselungstrojaner ein durchaus vorkommendes Problem darstellt, habe ich dieses in weiser Vorraussicht mit in Spiel gebracht.

Alle meine Daten - auch die Backups - sind verschlüsselt. Ist das jetzt schlimm?
Das ist auf der eine Seite löblich, auf der anderen Seite eine vermeidbare Fehlerquelle!
Wenn auch nur ein kleiner Teil des Bandes/ ein Sektor einer Platte nicht gelesen werden kann, ist das ganze Backup zerstört, bei nichtverschlüsselung ist nur eine Datei betroffen dessen Verlust möglicherweise verschmerzbar ist oder aus einem älteren Backup wiederhergestellt werden.

Verstehe ich nicht - seit wann geht es um mich bzw. meine Ansprüche? Habe ich da was verpasst?
Du bist derjenige, der Schwarz/Weiß gemalt hat.

Ich habe lediglich darauf hingewiesen, das ein NAS kein Backup-Konzept ist oder gar eines ersetzt. Erkläre uns doch bitte deine verwirrte Reaktion auf diese IMHO korrekte Feststellung!

Wo steht in dieser Aussage etwas von einem NAS?
Wichtig ist hier erstmal ein Backupkonzept/eine Backupstrategie zu haben.
Was muß wie oft gesichert werden, ist Versionierung notwendig, Wieviele Backupgenerationen will man haben etc. pp.
Ein oder mehrer NASen kann/können durchaus essentieller Bestandteil eines Backupkonzeptes / einer Backupstrategie sein!

Solltest du jetzt immer noch verwirrt sein, kann dir wohl keiner weiterhelfen.
Im Zweifel hat jeder seine Meinung!
Wer damit erfolgreicher ist, kann hier sowieso nicht festgestellt werden!
Das Beste Backup ist nämlich das Backup, welches nie benötigt wird.
Um Das zu erreichen gibt es 'ne ganze Menge was man tun kann.

Kleine Nachtrag:
Mein NAS für die Datensicherung wird automatisch hochgefahren, um die Datensicherung vom HauptNAS zu ziehen und wird danach automatisch wieder runtergefahren.
Der Kritikpunkt ist, daß das Teil physiikalisch am Netzwerk und am Stromnetz angeschlossen ist und somit im Falle eines direkten Blitzschlages gegrillt werden kann.
 
Zuletzt bearbeitet:
@ All für die Tips und die rege Diskussion :) Über Backup-Lösungen mache ich mir mal Gedanken und komme dann auf euch zu.

Mittlerweile ging es hier etwas weiter:

Erledigt:

- Öffentliche IP4-Anschluss
- Brigde Modus für alle KabelBW-Router hier freigeschalten

Dabei ist eine Frage aufgekommen für das VPN Netzwerk:

Kann man auch, wenn man z.B. im Urlaub ist, ohne Gateway HW auf das VPN Netzwerk zugreifen?

LG
 
Moin,

Du fragst "kann man", meinst du damit mehrere berechtigte oder Du für Wartungszwecke?;)

Ich habe privat soetwas ähnliches mit pfSense aufgezogen: Zwei Clientnetze verbinden sich vollkommen transparant von ihrer pfSense zu meiner pfSense, dann verbindet sich noch ein remote Server via OpenVPN mit meiner pfSense. Zu meiner pfSense und einer entfernten pfSense kann ich auch von unterwegs jederzeit einen Tunnel vom Handy oder Notebook aufbauen, hat mir schon viel Fahrerei erspart :banana:

-teddy
 
... man kann ...
nennt sich dann Client2Site-VPN

Auf dem VPN Gateway muss eine entsprechende "Client2Site-konfiguration" angelegt sein, auf dem Client Rechner benötigt man dann noch einen VPN Client wie z.B. "Shrew VPN Client" oder "TheGreenBow" - oder auch OpenVPN, je nach dem welche der Lösungen zumEinsatz kommt.

Bis vor einigen Jahren gab es noch SSL-VPN, aber das ist seit Windows7-64Bit Geschichte (unter W7-32Bit SP1 auch nur noch mit viel Mühe zum Laufen zu bekommen) - Der Schwarze Peter liegt offenbar bei MS.
 
Hallo ihr Lieben,

hier geht es endlich weiter :) (wurde wegen der Software ein paar mal umentschieden usw., aber was ran muss, muss doch ran.)

Gekauft wurde:
DrayTek Vigor2925

und mehrere
Draytek Vigor2120

In der Hauptfiliale, wo auch der Server steht ist folgender Anschluss vorhanden:

Unitymedia, 50Mbit, Business-Anschluss, statische IP.
Folgende Hardware:
Fritbox 6360
Dort wurde der Bridgemodus freigeschalten und ich habe den Port 3 als Brigdeport freigegeben.
Der wurde mit den Vigor2925 WAN Port 1 verbunden und dort habe ich folgendes eingestellt:

Statische IP,
Ip Adresse: XX.XXX.XX.16 (wurde vom Unitymedia so vergeben)
Subnetmask: 255.255.255.0
Gateway: XX.XXX.XX.1 (steht so in der Fritzbox unter Internetverbindung, ist das korrekt?)

Dann ein Notebook direkt per Kabel in den LAN-Port 1 des Vigors.

Ich bekomme hier aber keine Internetverbindung. Die Lämpchen leuchten, eine physikalische Verbindung besteht also. Was könnte der Fehler sein? Scheint so als würde der Vigor keine IP bekommen, bzw der Brigdemodus funktioniert nicht.

Zu VPN bin ich noch nicht gekommen, denke der erste Schritt ist es, den Gateway zu integrieren :)

LG
 
Ja genau, den Port habe ich bereits aktiviert und den Vigor dort angeschlossen. Allerdings wird keine Internetverbindung hergestellt. Oder meinst du, dass ich im Vigor, gar nichts einstellen muss? Also alles leerlasse?
 
Der Vigor braucht die Einwahldaten (PPOE), damit er über die Fritzbox - die am Bridgeport wie ein DSL-Modem angesprochen wird - die Internetverbindung aufbaut
Lies doch einfach die Anleitung
evtl mußt du noch die automatische Einwahl auf der FB deaktivieren, andernfalls muß Providerseitig eine Mehrfacheinwahl für deinen Anschluss freigeschaltet sein, da du dann 2 Public IPs hast (Fritzbox und Vigor).
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh