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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 444840
Url: https://administrator.de/contentid/444840
Ausgedruckt am: 25.11.2024 um 09:11 Uhr
11 Kommentare
Neuester Kommentar
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.
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
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.
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
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
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