11
Kundensupport via VPN - Wie löst Ihr das?
Hallo zusamen,
Wir betreuen derzeit die IT-Systeme zahlreiche Kunden mit 3 zuständigen IT'lern.
Bei fast alle Kunden gibt es VPN Zugänge, über die wir die Wartung des Netzwerks und der Server, aber auch sämtliche anderen administrativen Aufgaben durchführen.
Was uns nicht gefällt:
Auf unseren Arbeitsplätzen wird momentan jeweils immer eine neue VPN Verbindung eingerichtet, Zugänge & Co. in der Kundendokumentation nachgeschaut.
Dann läuft der eine Server per VMWare und mir fehlt der vSphere Client, der andere muss via Hyper-V Konsole gewartet werden. Der Dritte war vielleicht noch nie beim Kunden aufgeschaltet und hat an seinem Arbeitsplatz noch gar keine VPN Verbindung eingerichtet.
Wie löst Ihr dieses Szenario?
Welche Möglichkeiten gibt es, die Kunden-VPN's zentral einzurichten und die notwendigen Software Tools zentral zu installieren?
Im Endergebnis wollen wir zukünftig dass jeder IT'ler schnell & einfach die Systeme aller unserer Kunden administrieren kann, oder jeweils individuelle Konfigurationen auf seinem Rechner vornehmen oder anpassen zu müssen.
Vielleicht hat der ein oder andere von euch ja Erfahrungswerte oder stand schon mal vor der gleichen Frage?
Viele Grüße
Joshua
Wir betreuen derzeit die IT-Systeme zahlreiche Kunden mit 3 zuständigen IT'lern.
Bei fast alle Kunden gibt es VPN Zugänge, über die wir die Wartung des Netzwerks und der Server, aber auch sämtliche anderen administrativen Aufgaben durchführen.
Was uns nicht gefällt:
Auf unseren Arbeitsplätzen wird momentan jeweils immer eine neue VPN Verbindung eingerichtet, Zugänge & Co. in der Kundendokumentation nachgeschaut.
Dann läuft der eine Server per VMWare und mir fehlt der vSphere Client, der andere muss via Hyper-V Konsole gewartet werden. Der Dritte war vielleicht noch nie beim Kunden aufgeschaltet und hat an seinem Arbeitsplatz noch gar keine VPN Verbindung eingerichtet.
Wie löst Ihr dieses Szenario?
Welche Möglichkeiten gibt es, die Kunden-VPN's zentral einzurichten und die notwendigen Software Tools zentral zu installieren?
Im Endergebnis wollen wir zukünftig dass jeder IT'ler schnell & einfach die Systeme aller unserer Kunden administrieren kann, oder jeweils individuelle Konfigurationen auf seinem Rechner vornehmen oder anpassen zu müssen.
Vielleicht hat der ein oder andere von euch ja Erfahrungswerte oder stand schon mal vor der gleichen Frage?
Viele Grüße
Joshua
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 444840
Url: https://administrator.de/contentid/444840
Ausgedruckt am: 13.11.2024 um 00:11 Uhr
11 Kommentare
Neuester Kommentar
Moub,
Zentraler VPN-Arbeitsplatz, audf den man sich Remote aufschalten kann (RDP/VNC oder Netzwer-KVM-Modul).
lks
Zentraler VPN-Arbeitsplatz, audf den man sich Remote aufschalten kann (RDP/VNC oder Netzwer-KVM-Modul).
lks
1
Hi Iks, danke für deine Antwort 
Das war auch meine erste Idee - Also virtualisierte Win 10 Maschine oder ein Terminal Server.
Problem: Wir kämen nahezu nie mit einem VPN-Arbeitsplatz hin und müssten in der Lage sein, auch mehrere Kunden gleichzeitig zu betreuen. Grade mit Blick in die Zukunft müssten wir in irgend einer Form "skalierbar" bleiben, sofern wir weiter wachsen.
Das war auch meine erste Idee - Also virtualisierte Win 10 Maschine oder ein Terminal Server.
Problem: Wir kämen nahezu nie mit einem VPN-Arbeitsplatz hin und müssten in der Lage sein, auch mehrere Kunden gleichzeitig zu betreuen. Grade mit Blick in die Zukunft müssten wir in irgend einer Form "skalierbar" bleiben, sofern wir weiter wachsen.
Wir verfolgen da 2 Ansätze:
für die Wartung ein "Connection-Server" der sich im Netz des Kunden befindet und via LIC+ erreichbar ist. Details sind geheim. Soviel aber kann ich sagen: Zertifikate spielen ein Rolle. Von da weiter via RDP.
für Supportfälle beim User verwenden wir Netsupport. Für jedes Netz / jeden Kunden kann man da ein Gateway einrichten und je nachdem welches Gateway ausgewählt wurde kann man sich dann auf die entsprechende Maschine verbinden. Ist aber relativ teuer. Kommt auf das Anwendungsgebiet an.
Vorteil: Externe Server die am Ende die Verbindung herstellen, wie etwa bei TeamViewer, fallen weg.
Wenn sich im Netz des Kunden ein SCCM befindet für die Software-Verteilung, kann man sich auch von diesem aus zum Client des Users verbinden.
für die Wartung ein "Connection-Server" der sich im Netz des Kunden befindet und via LIC+ erreichbar ist. Details sind geheim. Soviel aber kann ich sagen: Zertifikate spielen ein Rolle. Von da weiter via RDP.
für Supportfälle beim User verwenden wir Netsupport. Für jedes Netz / jeden Kunden kann man da ein Gateway einrichten und je nachdem welches Gateway ausgewählt wurde kann man sich dann auf die entsprechende Maschine verbinden. Ist aber relativ teuer. Kommt auf das Anwendungsgebiet an.
Vorteil: Externe Server die am Ende die Verbindung herstellen, wie etwa bei TeamViewer, fallen weg.
Wenn sich im Netz des Kunden ein SCCM befindet für die Software-Verteilung, kann man sich auch von diesem aus zum Client des Users verbinden.
1
Hallo Joshua,
wieso richtet ihr die VPNs pro Arbeitsplatz ein und nehmt kein VPN-Gateway? Wir machen das mit einem VPN-Gateway und einer Linux-VM pro Kunde (KVM, sehr ressourcensparend) auf die man sich verbindet, um darüber dann ins Kunden-VPN zu kommen. Per SSH-X-Forwarding kann man sich dann von dort per RDP oder SSH oder über nen Socks-Proxy per SSH weiter verbinden. Sprich hier muss man nur den SSH-Port im VPN freigeben und alles andere bleibt völlig getrennt.
Für die Verwaltung der Infrastruktur ist alles bei den Kunden in einer Admin-VM, die entsprechende Management-Clients o.ä. bereithält. Damit das unabhängig von unseren CLients laufen kann. Bei neueren VSPhere gehts ja eh per Webinterface und nicht mehr per installiertem Client, da reicht dann auch der Socks-Proxy per SSH.
Grüße
bloody
wieso richtet ihr die VPNs pro Arbeitsplatz ein und nehmt kein VPN-Gateway? Wir machen das mit einem VPN-Gateway und einer Linux-VM pro Kunde (KVM, sehr ressourcensparend) auf die man sich verbindet, um darüber dann ins Kunden-VPN zu kommen. Per SSH-X-Forwarding kann man sich dann von dort per RDP oder SSH oder über nen Socks-Proxy per SSH weiter verbinden. Sprich hier muss man nur den SSH-Port im VPN freigeben und alles andere bleibt völlig getrennt.
Für die Verwaltung der Infrastruktur ist alles bei den Kunden in einer Admin-VM, die entsprechende Management-Clients o.ä. bereithält. Damit das unabhängig von unseren CLients laufen kann. Bei neueren VSPhere gehts ja eh per Webinterface und nicht mehr per installiertem Client, da reicht dann auch der Socks-Proxy per SSH.
Grüße
bloody
1
Servus,
unsere "alte" Lösung:
-S2S VPN
-Terminalserver für Techniker ohne Internet
-Kundennetze untereinander natürlich verbieten
-RDP TOOL deiner WAHL und nur RDP als Protokoll erlauben
Hat einige Jahre Prima funktioniert.
Grüße STIDK
unsere "alte" Lösung:
-S2S VPN
-Terminalserver für Techniker ohne Internet
-Kundennetze untereinander natürlich verbieten
-RDP TOOL deiner WAHL und nur RDP als Protokoll erlauben
Hat einige Jahre Prima funktioniert.
Grüße STIDK
1
Mehrere unserer "Zulieferer" haben es so realisiert, dass die bei sich eine virtuelle Umgebung haben, in der für jeden Kunden eine eigene Maschine mit dem entsprechenden VPN-Zugang läuft. Wenn jemand etwas bei einem Kunden ändern muss, verbindet er sich mit dem jeweiligen System, verbindet sich mit dem Kunden-VPN (also unserem) und führt seine Arbeiten durch.
Auf der Maschine befindet sich dann die Softwareausstattung, die für den jeweiligen Kunden benötigt wird.
Auf der Maschine befindet sich dann die Softwareausstattung, die für den jeweiligen Kunden benötigt wird.
1
Servus,
wenn Sicherheit eine Rolle spielt, würde ich nicht von einem PC aus auf X Kundennetze zugreifen wollen. Eine VM für jeden Kunden als VPN-Device ist da schon ne Nummer sicherer. Früher hatten wir einzelne PCs für jeden Kunden. Dann ist man an den Arbeitsplatz gegangen, von dem das Kundennetz erreichbar war.
War auch Vorgabe von einigen Kunden.
Grüße, Henere
wenn Sicherheit eine Rolle spielt, würde ich nicht von einem PC aus auf X Kundennetze zugreifen wollen. Eine VM für jeden Kunden als VPN-Device ist da schon ne Nummer sicherer. Früher hatten wir einzelne PCs für jeden Kunden. Dann ist man an den Arbeitsplatz gegangen, von dem das Kundennetz erreichbar war.
War auch Vorgabe von einigen Kunden.
Grüße, Henere
1
Moin,
Zum Thema:
Wir stellen unseren IT-Dienstleistern als Kunde die notwendige Infrastuktur bereit. Wir haben dazu eine weitere DMZ eingerichtet, in denen wir verschiedene RDS-Hosts (je nach Zweck und Sicherheitsvorgaben) bereitstellen. Denn auch hier liegt die Lizenzierung der notwendigen Produkte und CALs immer beim Kunden! Der Zugriff kann ausschließlich über HTML5 (kein RemoteApp oder Remotedeskclient) erfolgen. Zur Authentifizierung ist ein Client SSL-Zertifikat von unserer Zertifizierungsstelle notwendig so wie die dazugehörigen Credentils für die Anmeldung am RDS-Hosts.
Gruß,
Dani
Also virtualisierte Win 10 Maschine oder ein Terminal Server.
Bei Variante 1 (Win 10) aufpassen. Da kann die korrekte Lizenzierung ein teurer Spaß werden.Zum Thema:
Wir stellen unseren IT-Dienstleistern als Kunde die notwendige Infrastuktur bereit. Wir haben dazu eine weitere DMZ eingerichtet, in denen wir verschiedene RDS-Hosts (je nach Zweck und Sicherheitsvorgaben) bereitstellen. Denn auch hier liegt die Lizenzierung der notwendigen Produkte und CALs immer beim Kunden! Der Zugriff kann ausschließlich über HTML5 (kein RemoteApp oder Remotedeskclient) erfolgen. Zur Authentifizierung ist ein Client SSL-Zertifikat von unserer Zertifizierungsstelle notwendig so wie die dazugehörigen Credentils für die Anmeldung am RDS-Hosts.
Gruß,
Dani
1
Hallo zusammen,
vielen Dank für die zahlreichen Vorschläge
Unsere Kunden bewegen sich größtenteils im Bereich 3 - 50 Mitarbeiter.
Daher möchten wir von unseren kleinen Kunden natürlich im Regelfall nicht "erwarten" dass die uns die notwendige Infrastruktur zur Verfügung stellen. Teilweise sind dort nicht mal Hyper-V oder VMWare Hosts für einen virtuellen Arbeitsplatz vorhanden. Daher sollte die Lösung natürlich relativ einfach und ohne zusätzlich anzuschaffende Hardware umzusetzen sein.
Eine vollständige Site to Site Vernetzung mit freigegebenen RDP-Ports fällt für uns weg, da es schon bei den Adressbereichen der Kunden Überschneidungen gibt (historisch entstanden). Bei neuen Kunden versuchen wir zwar die Subnetze möglichst unterschiedlich zu gestalten, aber das lässt sich natürlich nicht überall einfach so anpassen.
Dani, was die virtuellen Win 10 Maschinen und deren Lizenzierung angeht hast du natürlich völlig recht. Sinnvoller wäre hier ein auf Hyper-V basierender Terminalserver. Damit könnten wir die Verbindungen entsprechend konfigurieren und uns je nach betreffendem Kunden per RDP anmelden.
Den Vorschlag von bloodstix über ein VPN Gateway zu arbeiten fand ich auch ganz interessant:
Wir arbeiten beispielsweise mit MikroTik Routern - Hier wäre es durchaus vorstellbar in einer virtuellen Instanz die VPN Verbindungen einzurichten. Per Mangle-Regeln könnten wir dann bestimmen, über welche VPN Verbindung unserere Clients / Arbeitsplätze das jeweilige Subnetz des Kunden erreichen können. Mit entsprechenden Firewallregeln wäre das bestimmt umsetzbar.
Ich werde über den Feiertag morgen mal verschiedene Möglichkeiten testen und mal mit den Kollegen sprechen, was die bevorzugen würden.
Viele Grüße
Joshua
vielen Dank für die zahlreichen Vorschläge
Unsere Kunden bewegen sich größtenteils im Bereich 3 - 50 Mitarbeiter.
Daher möchten wir von unseren kleinen Kunden natürlich im Regelfall nicht "erwarten" dass die uns die notwendige Infrastruktur zur Verfügung stellen. Teilweise sind dort nicht mal Hyper-V oder VMWare Hosts für einen virtuellen Arbeitsplatz vorhanden. Daher sollte die Lösung natürlich relativ einfach und ohne zusätzlich anzuschaffende Hardware umzusetzen sein.
Eine vollständige Site to Site Vernetzung mit freigegebenen RDP-Ports fällt für uns weg, da es schon bei den Adressbereichen der Kunden Überschneidungen gibt (historisch entstanden). Bei neuen Kunden versuchen wir zwar die Subnetze möglichst unterschiedlich zu gestalten, aber das lässt sich natürlich nicht überall einfach so anpassen.
Dani, was die virtuellen Win 10 Maschinen und deren Lizenzierung angeht hast du natürlich völlig recht. Sinnvoller wäre hier ein auf Hyper-V basierender Terminalserver. Damit könnten wir die Verbindungen entsprechend konfigurieren und uns je nach betreffendem Kunden per RDP anmelden.
Den Vorschlag von bloodstix über ein VPN Gateway zu arbeiten fand ich auch ganz interessant:
Wir arbeiten beispielsweise mit MikroTik Routern - Hier wäre es durchaus vorstellbar in einer virtuellen Instanz die VPN Verbindungen einzurichten. Per Mangle-Regeln könnten wir dann bestimmen, über welche VPN Verbindung unserere Clients / Arbeitsplätze das jeweilige Subnetz des Kunden erreichen können. Mit entsprechenden Firewallregeln wäre das bestimmt umsetzbar.
Ich werde über den Feiertag morgen mal verschiedene Möglichkeiten testen und mal mit den Kollegen sprechen, was die bevorzugen würden.
Viele Grüße
Joshua
Moin,
Bestes Spiel von heute Nachmittag. Es ist war nicht klar, wie der Ablauf bis dato war, aber da sind permanente Site-to-Site Tunnel fast eine Einladung.
Gruß,
Dani
Eine vollständige Site to Site Vernetzung mit freigegebenen RDP-Ports fällt für uns weg, da es schon bei den Adressbereichen der Kunden Überschneidungen gibt (historisch entstanden). Bei neuen Kunden versuchen wir zwar die Subnetze möglichst unterschiedlich zu gestalten, aber das lässt sich natürlich nicht überall einfach so anpassen.
Das lässt sich meistens nicht vermeiden - daher greift man öfters auf 1:1 NAT zurück. Unabhängig davon würde ich dem Dienstleister die Ohren langziehen, wenn er alle Kunden (sternförmig) per S2S an sein Firmen/Supportnetz anbinden würde. Ein simpler Konfigurationsfehler auf der Firewall kann dazu führen, dass unbefugte Zugriff auf Systeme erhalten.Bestes Spiel von heute Nachmittag. Es ist war nicht klar, wie der Ablauf bis dato war, aber da sind permanente Site-to-Site Tunnel fast eine Einladung.
Gruß,
Dani
Hallo zusammen,
ich bin mittlerweile einen Schritt weiter und relativ zufrieden mit der gefundenen Lösung:
mRemoteNG ist ein ziemlich cooles (wie ich finde) Open Source Tool zur Verwaltung von RDP und bspw. SSH Verbindungen.
Zusätzlich lassen sich auch externe Anwendungen einbinden (TeamViewer oder AnyDesk funktionieren).
Hiermit können wir nun zunächst mal alle RDP, SSH oder AnyDesk Verbindungen in einer AES Verschlüsselten Datei pro Kunde hinterlegen.
Mit einem PowerShell Script können wir via "Add-VPNConnection" und einem anschließenden rasdial.exe VPN Verbindungen auf einem Client anlegen und uns auch automatisch damit verbinden. Dieses PowerShell Script kann via Argumenten auch wieder aus mRemoteNG gestartet werden.
Im Endergebnis haben wir nun also eine Datei pro Kunde. Diese öffnen und entschlüsseln wir mit dem jeweiligen Masterpasswort. Darin enthalten ist ein Eintrag der via einfachem Doppelklick eine VPN verbindung zum Kunden einrichtet. Sämtliche weiteren Verbindungen lassen sich dann ebenfalls aus diesem Programm heraus initiieren.
Noch eine Anmerkung zum Thema Sicherheit: Ein Client sollte definitiv nie mit mehreren Kunden-Netzen gleichzeitig verbunden sein. Das abwechselnde Verbinden zu jeweils einem Kunden von unseren Arbeitsplätzen ist aber aus meiner Sicht vertretbar: Denn diese Clients nutzen wir auch für alle sonstigen Arbeiten. Wir greifen damit schließlich auch auf kundenspezifische KeePass Dateien zu oder Loggen uns bei empfindlichen Onlinediensten ein. Damit müssen wir unseren Clients letztendlich sowieso vertrauen und für den Schutz der Daten sorgen - Mit der Fernwartung verhält es sich da letztendlich ja nicht anders.
Vielleicht ist dieser Ansatz ja auch etwas für den ein oder anderen?
Vielleicht habt ihr aber auch noch Anmerkungen oder Ideen zu meiner Vorgehensweise?
Viele Grüße
Joshua
ich bin mittlerweile einen Schritt weiter und relativ zufrieden mit der gefundenen Lösung:
mRemoteNG ist ein ziemlich cooles (wie ich finde) Open Source Tool zur Verwaltung von RDP und bspw. SSH Verbindungen.
Zusätzlich lassen sich auch externe Anwendungen einbinden (TeamViewer oder AnyDesk funktionieren).
Hiermit können wir nun zunächst mal alle RDP, SSH oder AnyDesk Verbindungen in einer AES Verschlüsselten Datei pro Kunde hinterlegen.
Mit einem PowerShell Script können wir via "Add-VPNConnection" und einem anschließenden rasdial.exe VPN Verbindungen auf einem Client anlegen und uns auch automatisch damit verbinden. Dieses PowerShell Script kann via Argumenten auch wieder aus mRemoteNG gestartet werden.
Im Endergebnis haben wir nun also eine Datei pro Kunde. Diese öffnen und entschlüsseln wir mit dem jeweiligen Masterpasswort. Darin enthalten ist ein Eintrag der via einfachem Doppelklick eine VPN verbindung zum Kunden einrichtet. Sämtliche weiteren Verbindungen lassen sich dann ebenfalls aus diesem Programm heraus initiieren.
Noch eine Anmerkung zum Thema Sicherheit: Ein Client sollte definitiv nie mit mehreren Kunden-Netzen gleichzeitig verbunden sein. Das abwechselnde Verbinden zu jeweils einem Kunden von unseren Arbeitsplätzen ist aber aus meiner Sicht vertretbar: Denn diese Clients nutzen wir auch für alle sonstigen Arbeiten. Wir greifen damit schließlich auch auf kundenspezifische KeePass Dateien zu oder Loggen uns bei empfindlichen Onlinediensten ein. Damit müssen wir unseren Clients letztendlich sowieso vertrauen und für den Schutz der Daten sorgen - Mit der Fernwartung verhält es sich da letztendlich ja nicht anders.
Vielleicht ist dieser Ansatz ja auch etwas für den ein oder anderen?
Vielleicht habt ihr aber auch noch Anmerkungen oder Ideen zu meiner Vorgehensweise?
Viele Grüße
Joshua
