IT über mehrere Standorte verbinden

Mehrere Standorte verbindet man entweder über ein Site-to-Site-VPN, das die vorhandene Internetanbindung jedes Standorts nutzt, oder über eine Standleitung mit zugesicherter Bandbreite. Für die meisten kleinen und mittleren Betriebe reicht ein sauber aufgesetztes VPN über stabile Business-Anschlüsse und ist günstiger. Eine Standleitung lohnt sich, wenn dauerhaft große Datenmengen fließen oder ein Verbindungsausfall wirtschaftlich nicht tragbar ist. Entscheidend ist, was zwischen den Standorten tatsächlich läuft, nicht ihre Anzahl.

VPN oder Standleitung: welche Anbindung passt zum Betrieb?

Ein Site-to-Site-VPN verschlüsselt die Verbindung zwischen zwei Standorten über das normale Internet – jeder Standort braucht dafür nur eine stabile Internetleitung und eine Firewall, die VPN-Tunnel verlässlich aufbaut. Die Bandbreite ist so gut wie die zugrunde liegende Internetanbindung, und bei einem Ausfall des Internetanbieters an einem Standort steht auch der Tunnel. Eine Standleitung dagegen ist eine dedizierte Verbindung, deren Bandbreite garantiert ist, unabhängig davon, was andere Kunden desselben Anbieters gerade tun. Sie kostet mehr, liefert dafür aber planbare Latenz – wichtig für Anwendungen, die auf kurze Antwortzeiten angewiesen sind, etwa Terminalsitzungen auf einem zentralen ERP-Server oder Telefonie über mehrere Standorte hinweg. Für den reinen Datenaustausch, E-Mail und Zugriff auf zentrale Dateiablagen reicht in aller Regel das VPN.

• Site-to-Site-VPN für die meisten Fälle: günstig, schnell eingerichtet, ausreichend für E-Mail, Dateizugriff und Standard-Anwendungen
• Standleitung, wenn durchgehend hohe und garantierte Bandbreite gebraucht wird, etwa bei großen Datenmengen aus der Produktion
• Latenzkritische Anwendungen wie Telefonie oder Terminalsitzungen zuerst testen, bevor über die Anbindungsart entschieden wird
• Die Internetanbindung an jedem Standort ist die Grundlage des VPN – eine schwache Leitung an einem Standort bremst die ganze Verbindung

Zentrale oder lokale Dienste: wo sollten Server und Software laufen?

Die zweite Grundsatzentscheidung ist, wo die eigentlichen Dienste liegen. Zentral heißt: ein Server oder eine Cloud-Instanz an einem Standort oder bei einem Hoster, auf die alle anderen Standorte über die Verbindung zugreifen. Lokal heißt: jeder Standort hat eigene Systeme, die auch ohne Verbindung zu den anderen Standorten weiterlaufen. Beides hat seinen Platz, und in der Praxis ist es meist eine Mischung. Systeme, die für den laufenden Betrieb an einem Standort unverzichtbar sind – etwa eine Produktionssteuerung, eine Kassenlösung im Handel oder ein Zeiterfassungsterminal – sollten so ausgelegt sein, dass sie einen kurzen Ausfall der Standortverbindung überstehen, notfalls mit lokaler Zwischenspeicherung, die später synchronisiert wird. Systeme, bei denen ein kurzer Ausfall verkraftbar ist – zentrales ERP, E-Mail, Dateiablage – können ohne Risiko zentral liegen.

• Betriebskritische, lokale Prozesse (Produktion, Kasse, Zutrittskontrolle) sollten einen kurzen WAN-Ausfall am jeweiligen Standort überstehen
• Zentrale Systeme wie ERP, E-Mail oder Dateiserver dürfen von der Standortverbindung abhängen, wenn ein kurzer Ausfall tolerierbar ist
• Backups nie ausschließlich am selben Standort wie die Daten selbst vorhalten – ein zweiter Standort oder ein externer Speicherort ist Pflicht
• Bei der Auswahl neuer Software vorab klären, ob sie einen dauerhaften Zentralzugriff voraussetzt oder Offline-Betrieb pro Standort erlaubt

Was passiert an einem Standort, wenn die Verbindung zu den anderen ausfällt?

Diese Frage sollte für jeden Standort einzeln beantwortet sein, bevor sie in der Praxis gestellt wird. Ein Standort ohne Verbindung zur Zentrale braucht lokal funktionierendes Internet, eine eigene lokale DNS-Auflösung und – je nach Betrieb – lokal zwischengespeicherte Daten für die wichtigsten Prozesse. Wo ein Ausfall besonders schmerzhaft wäre, lohnt sich eine redundante Anbindung: eine zweite Internetleitung über einen anderen Anbieter oder eine Mobilfunk-Backup-Verbindung, die automatisch übernimmt, wenn die Hauptleitung ausfällt. Wichtiger als die Technik ist dabei die Übung: Ein Failover, der nie getestet wurde, funktioniert im Ernstfall erfahrungsgemäß seltener als erwartet.

Ein neuer Standort kommt dazu: was bei einem Zukauf technisch ansteht

Bei einer Übernahme oder einem Zukauf trifft die eigene, gewachsene Infrastruktur auf eine fremde – mit eigenem Adressraum, eigenen Geräten und oft eigener IT-Historie. Der größte Fehler ist, den neuen Standort einfach per VPN an das bestehende Netz zu hängen, ohne vorher zu prüfen, was dort tatsächlich läuft. IP-Adressbereiche können sich überschneiden, was zu Konflikten führt, sobald beide Netze verbunden werden. Geräte und Software am neuen Standort können ältere, unsichere Konfigurationen mitbringen, die man sich nicht ungeprüft ins eigene Netz holen möchte. Deshalb steht am Anfang immer eine Bestandsaufnahme, danach eine saubere Netztrennung mit klar definierten, kontrollierten Übergängen – und erst wenn diese Übergänge stehen, eine schrittweise Integration statt eines einmaligen großen Zusammenschlusses.

• Vor der Anbindung: IP-Adressbereiche beider Netze auf Überschneidungen prüfen
• Geräte und Systeme am neuen Standort inventarisieren, bevor sie mit dem bestehenden Netz verbunden werden
• Erste Anbindung über eine kontrollierte, eingeschränkte Verbindung statt eines offenen Vollzugriffs
• Integration schrittweise planen: zuerst E-Mail und zentrale Systeme, kritische oder unklare Altsysteme zuletzt

Wie sollte die Adressierung über mehrere Standorte hinweg aufgebaut sein?

Ein Punkt, der bei der ersten Standortverbindung häufig zu kurz kommt, ist ein einheitliches Adressierungsschema. Wächst ein Unternehmen organisch, bekommt jeder Standort irgendwann sein eigenes Netz, oft nach dem Schema, das gerade zur Hand war – mit der Folge, dass sich Adressbereiche überschneiden, sobald die Standorte verbunden werden sollen, oder dass niemand mehr auf Anhieb sagt, welcher Adressbereich zu welchem Standort und welcher Funktion gehört. Ein klar strukturiertes Schema, bei dem sich Standort und Funktion aus der Adresse ablesen lassen, macht spätere Fehlersuche, Firewall-Regeln und die Anbindung weiterer Standorte spürbar einfacher. Wer diesen Schritt bei zwei Standorten überspringt, zahlt beim dritten oder vierten Standort dafür in Form von Nacharbeit, die sich mit etwas Vorplanung leicht vermeiden lässt.

Wie arbeiten mehrere Standorte mit denselben Daten statt mit eigenen Listen?

Ist die Netzwerkverbindung stabil, bleibt oft ein anderes Problem: Jeder Standort arbeitet mit eigenen Listen. Interne Bestellungen zwischen Filialen laufen per E-Mail, Lagerbestände sind nur vor Ort sichtbar, und für den Monatsbericht sammelt jemand Zahlen aus mehreren Tabellen zusammen. Die Geschäftsführung sieht dann nicht den aktuellen Stand, sondern den Stand der letzten Zusammenfassung.

• Standortübergreifende Abläufe wie interne Bestellungen oder Umlagerungen in einem gemeinsamen System abbilden
• Programme der einzelnen Standorte über Schnittstellen verbinden, statt Daten per E-Mail weiterzuleiten
• Berichte aus der gemeinsamen Datenbasis erzeugen, statt Tabellen von Hand zusammenzuführen
• Eine KI-gestützte Suche über Dokumente und Daten aller Standorte erst aufsetzen, wenn diese Daten zentral und geordnet vorliegen

Bei mehreren Standorten stellt sich außerdem die Frage, wo eine IT-Investition zuerst etwas bringt. Ein Standort mit schwacher Leitung oder ohne getesteten Failover kommt meist vor neuer Software, weil jede spätere Verbesserung auf dieser Verbindung aufbaut.

Wie NDVDL die Vernetzung mehrerer Standorte übernimmt

NDVDL sieht sich jeden Standort einzeln an, bevor eine Verbindung geplant wird: Leitung, Firewall, lokale Systeme, Adressbereiche und die Abläufe, die vom Netz abhängen.

1. 01Bestandsaufnahme an jedem Standort, inklusive Adressbereiche, Leitungen, lokaler Systeme und Dokumentationsstand
2. 02Schriftlicher Vorschlag zu Anbindungsart, Adressschema, Ausfallsicherung und Reihenfolge der Umsetzung
3. 03Umsetzung Standort für Standort, mit getestetem Failover, bevor der nächste Standort angebunden wird
4. 04Laufender Betrieb und Wartung von Firewalls, VPN-Tunneln und Netzwerk an allen Standorten, mit einem festen Ansprechpartner und einer gemeinsamen Dokumentation

So bleibt das Netz auch beim dritten oder vierten Standort nachvollziehbar, und ein Zukauf beginnt mit einem geprüften Plan statt mit einem offenen Tunnel ins eigene Netz.