VPN Clients bzw. Konfigurationen virtualisieren und gekapselt an zentraler Stelle ablegen - welche Möglichkeiten gibt es?
Hallo,
zugegeben, der Titel klingt etwas exotisch. Allerdings sieht auch genauso meine Anforderung aus. Wir sind ein kleines Software-Unternehmen im Bereich Energiemanagement.
Musste man "früher" noch für jede Inbetriebahme (unseres teils doch komplexen Systems) zum Kunden fahren, wird mittlerweile das meiste via Remote-Anbindung erledigt. In der Regel stellt der Kunde eine Anbindung zur Verfügung - der Kunde gibt logischerweisse aber auch an wie man eben ins kundeneigene Netzwerk kommt bzw. wie die Verbindung auf unserer Seite eingerichtet werden muss.
Kunde A realisiert das ganze über Cisco bzw. bekommen wir dann den Cisco Client samt Policy, Kunde B nutzt irgendeine Citrix-Lösung, Kunde C über webex oder Bomgar und so weiter.......
Diese "Brücke" zum Kunden wird von unterschiedlichen Stellen aus verbunden bzw. muss zuerst der Inbetriebnahmer eine Verbindung aufbauen um die Software zu installieren, danach der technische Zeichner...später der Support oder bei Fehlern auch mal die Entwicklung. Und die Projekte werden parallel bearbeitet.
IST-Stand:
Wir haben VMWare VSphere 4 im Einsatz - für jeden Kunden wurde bisher eine eigene VM (WinXP aus einem Template) geklont. In dieser VM wurde die Remote-Anbindung konfiguriert und bei Bedarf eben gestartet.
Das hat viele Vorteile:
- schnelle Bereitstellung
- eine zentrale Konfiguration für jeden
- die jeweiligen Mitarbeiter können parallel arbeiten - quasi jeder Kunde = eine eigene Sitzung
- der Entwickler "schaut" mal eben kurz auf die Konsole des jeweiligen Mitarbeiters, welcher gerade ein Projekt bearbeitet (auch standortübergreifend)
- VPN Client "beissen" sich nicht gegenseitig bzw. hätten wir alles auf einem System installiert, gäbe es bez. Kompatibilität Probleme...hatten wir früher alles
Problem:
Ab einem gewissen Zeitpunkt ist das Ganze nicht mehr handlebar bzw. nimmt es überhand. Mit Kanonen auf Spatzen bzw. für eine triviale Verbindung nach draussen "läuft" ein komplettes Betriebssystem welches Speicherplatz und Ressourcen frisst und auch gewartet werden muss (Updates etc.).
Das zweite Problem:
Wir haben Mitarbeiter an einem ca. 400km entfernten Standort - diese benötigen ebenfalls den Zugang zum Kunden. Unsere Standorte sind miteinander via VPN verbunden. Standort B musste also ersteinmal durch den VPN-Tunnel in unser Netzwerk (auf die VMWare Konsole), um sich dann von dort aus ins entfernte Kunden-Netzwerk zu bohren. [Standort B] ->[www/VPN] -> [Standort A] -> [www/VPN] -> [Kunde]
Resultat: extrem lahmende und zähe Verbindung über mehrere "Ecken"
Um der sowieso etwas zähen Konsole auszuweichen gäbe es ja die Möglichkeit eine direkte Sitzung via (schnellerem) RDP in die VM aufzubauen. Die meisten VPN-Clients unterbinden dieses aber bzw. "kappen" diese das eigene Netzwerk vor der virtuellen Maschine. Aus [eigenes LAN] -> [VM-Konsole] -> [Remote LAN] wird dann eben nur noch: [VM-Konsole] -> [Remote LAN]
Auch ein VMWare Server am zweiten Host bringt nicht die Lösung, da die "Kunden"-VM von einem Standort zum anderen migriert werden muss - dauert Stunden!
Lösung?
Bildlich stelle ich mir folgendes vor: die virtuelle Maschine ist der Berg und die darin konfigurierte VPN-Anbindung ist der Kiesel. Bisher ging ich immer davon aus den kompletten Berg je nach Situation bzw. Standort des Zugriffs verschieben zu müssen. Warum aber nicht den Kiesel (also die VPN-Anbindung) verschieben bzw. diesen "gekapselt" an zentraler Stelle ablegen.
Für jeden Remote-Mitarbeiter würde ich eine eigene VM für die Remote-Anbindungen erzeugen (jeder Standort hat einen eigenen Server bzw. läuft die Remote-VM jeweils immer im lokalen Netz). Je nach Bedarf startet der Mitarbeiter in seiner VM z.Bsp. die vorkonfigurierte VPN Anbindung zum Kunden XY. Diese Anbindung - z.Bsp über den Cisco Client (IPSec) liegt an zentraler Stelle als virtualisierte Anwendung. Via Doppelklick wird die Verbindung quasi am jeweiligen Standort aufgebaut.
Somit habe ich eine zentrale Konfiguration welche sich einfach pflegen lässt - ansonsten müsste ich das gleiche mehrere Male konfigurieren und warten etc.
Oder gibt es etwas wie ein lokales "Remote"-Gateway?
Ist so etwas realisierbar?
Die Konstellation ist etwas komplex bzw. verzahnen sich die Zugänge in fremde Netze immer mehr. Eventuell gibt es noch einen ganz anderen Lösungsansatz?
Über jedes Feedback dankbar....Grüße!
zugegeben, der Titel klingt etwas exotisch. Allerdings sieht auch genauso meine Anforderung aus. Wir sind ein kleines Software-Unternehmen im Bereich Energiemanagement.
Musste man "früher" noch für jede Inbetriebahme (unseres teils doch komplexen Systems) zum Kunden fahren, wird mittlerweile das meiste via Remote-Anbindung erledigt. In der Regel stellt der Kunde eine Anbindung zur Verfügung - der Kunde gibt logischerweisse aber auch an wie man eben ins kundeneigene Netzwerk kommt bzw. wie die Verbindung auf unserer Seite eingerichtet werden muss.
Kunde A realisiert das ganze über Cisco bzw. bekommen wir dann den Cisco Client samt Policy, Kunde B nutzt irgendeine Citrix-Lösung, Kunde C über webex oder Bomgar und so weiter.......
Diese "Brücke" zum Kunden wird von unterschiedlichen Stellen aus verbunden bzw. muss zuerst der Inbetriebnahmer eine Verbindung aufbauen um die Software zu installieren, danach der technische Zeichner...später der Support oder bei Fehlern auch mal die Entwicklung. Und die Projekte werden parallel bearbeitet.
IST-Stand:
Wir haben VMWare VSphere 4 im Einsatz - für jeden Kunden wurde bisher eine eigene VM (WinXP aus einem Template) geklont. In dieser VM wurde die Remote-Anbindung konfiguriert und bei Bedarf eben gestartet.
Das hat viele Vorteile:
- schnelle Bereitstellung
- eine zentrale Konfiguration für jeden
- die jeweiligen Mitarbeiter können parallel arbeiten - quasi jeder Kunde = eine eigene Sitzung
- der Entwickler "schaut" mal eben kurz auf die Konsole des jeweiligen Mitarbeiters, welcher gerade ein Projekt bearbeitet (auch standortübergreifend)
- VPN Client "beissen" sich nicht gegenseitig bzw. hätten wir alles auf einem System installiert, gäbe es bez. Kompatibilität Probleme...hatten wir früher alles
Problem:
Ab einem gewissen Zeitpunkt ist das Ganze nicht mehr handlebar bzw. nimmt es überhand. Mit Kanonen auf Spatzen bzw. für eine triviale Verbindung nach draussen "läuft" ein komplettes Betriebssystem welches Speicherplatz und Ressourcen frisst und auch gewartet werden muss (Updates etc.).
Das zweite Problem:
Wir haben Mitarbeiter an einem ca. 400km entfernten Standort - diese benötigen ebenfalls den Zugang zum Kunden. Unsere Standorte sind miteinander via VPN verbunden. Standort B musste also ersteinmal durch den VPN-Tunnel in unser Netzwerk (auf die VMWare Konsole), um sich dann von dort aus ins entfernte Kunden-Netzwerk zu bohren. [Standort B] ->[www/VPN] -> [Standort A] -> [www/VPN] -> [Kunde]
Resultat: extrem lahmende und zähe Verbindung über mehrere "Ecken"
Um der sowieso etwas zähen Konsole auszuweichen gäbe es ja die Möglichkeit eine direkte Sitzung via (schnellerem) RDP in die VM aufzubauen. Die meisten VPN-Clients unterbinden dieses aber bzw. "kappen" diese das eigene Netzwerk vor der virtuellen Maschine. Aus [eigenes LAN] -> [VM-Konsole] -> [Remote LAN] wird dann eben nur noch: [VM-Konsole] -> [Remote LAN]
Auch ein VMWare Server am zweiten Host bringt nicht die Lösung, da die "Kunden"-VM von einem Standort zum anderen migriert werden muss - dauert Stunden!
Lösung?
Bildlich stelle ich mir folgendes vor: die virtuelle Maschine ist der Berg und die darin konfigurierte VPN-Anbindung ist der Kiesel. Bisher ging ich immer davon aus den kompletten Berg je nach Situation bzw. Standort des Zugriffs verschieben zu müssen. Warum aber nicht den Kiesel (also die VPN-Anbindung) verschieben bzw. diesen "gekapselt" an zentraler Stelle ablegen.
Für jeden Remote-Mitarbeiter würde ich eine eigene VM für die Remote-Anbindungen erzeugen (jeder Standort hat einen eigenen Server bzw. läuft die Remote-VM jeweils immer im lokalen Netz). Je nach Bedarf startet der Mitarbeiter in seiner VM z.Bsp. die vorkonfigurierte VPN Anbindung zum Kunden XY. Diese Anbindung - z.Bsp über den Cisco Client (IPSec) liegt an zentraler Stelle als virtualisierte Anwendung. Via Doppelklick wird die Verbindung quasi am jeweiligen Standort aufgebaut.
Somit habe ich eine zentrale Konfiguration welche sich einfach pflegen lässt - ansonsten müsste ich das gleiche mehrere Male konfigurieren und warten etc.
Oder gibt es etwas wie ein lokales "Remote"-Gateway?
Ist so etwas realisierbar?
Die Konstellation ist etwas komplex bzw. verzahnen sich die Zugänge in fremde Netze immer mehr. Eventuell gibt es noch einen ganz anderen Lösungsansatz?
Über jedes Feedback dankbar....Grüße!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150302
Url: https://administrator.de/forum/vpn-clients-bzw-konfigurationen-virtualisieren-und-gekapselt-an-zentraler-stelle-ablegen-welche-150302.html
Ausgedruckt am: 23.12.2024 um 15:12 Uhr
3 Kommentare
Neuester Kommentar
Hi!
Terminalserver habt Ihr nicht im Einsatz ? Ich verstehe nicht so ganz, warum Ihr für jede Remoteanbindung eine eigene virtuelle Maschine aufsetzt (finde ich recht aufwendig). Wäre da ein Terminalserver, auf dem die Verbindungen vorkonfiguriert sind (und auf den sich die Anwender per rdp einloggen) nicht sinnvoller ? Die VPN-Betreffenden FDaten (Schlüssen, Zertifikate etc.) kann man zwischen zwei Terminalservern replizieren (z.B. cwrsync) um auch am zweiten Standort Zugriff auf die Kundeninstallationen zu haben.
Oder habe ich etwas falsch verstanden ?
CU,
Kai.
Terminalserver habt Ihr nicht im Einsatz ? Ich verstehe nicht so ganz, warum Ihr für jede Remoteanbindung eine eigene virtuelle Maschine aufsetzt (finde ich recht aufwendig). Wäre da ein Terminalserver, auf dem die Verbindungen vorkonfiguriert sind (und auf den sich die Anwender per rdp einloggen) nicht sinnvoller ? Die VPN-Betreffenden FDaten (Schlüssen, Zertifikate etc.) kann man zwischen zwei Terminalservern replizieren (z.B. cwrsync) um auch am zweiten Standort Zugriff auf die Kundeninstallationen zu haben.
Oder habe ich etwas falsch verstanden ?
CU,
Kai.
Hallo,
wir haben eine ähnliche Struktur wie Kollisionskurs und in dem Zusammenhang schlechte Erfahrungen imn Zusammenspiel von mehreren VPN Clients auf einem Rechner gehabt, daher haben wir genauso umgestellt auf VM, respektive sind zum Teil noch im Aufbau dieser Struktur.
Gute Erfahrungen haben wir aber mit Cisco EZVPN gemacht.
Damit benötigen wir beim Kunden nur noch eine IP Adressen aus dessen lokalen Netz. zur zusätzlichen Sicherheit authentifiziert sich der Cisco Router gegen einen Radius Server hier bei uns im Haus.
VPN Clients oder Logins über Webaccess nutzen wir nach Möglichkeit garnicht, oder nur dort wo derKunde partout nicht anders will.
Unsere Servicetechniker können nicht von außen in das Netz eines Kunden sondern nur (!) durch unser Hausnetz.
Also Token gesicherte Einwahl in unser Hausnetz, durch den Tunnel zum Kunden!
Performance mässig haben wir nur da Probleme wo es sich bei der Anbindung noch um Analoge Wählverbindungen handelt .
Tunnel Richtung Südamerika laufen mit einem lokalen Breitbandinternet Anschluss teilweise gut bis sehr gut!
brammer
wir haben eine ähnliche Struktur wie Kollisionskurs und in dem Zusammenhang schlechte Erfahrungen imn Zusammenspiel von mehreren VPN Clients auf einem Rechner gehabt, daher haben wir genauso umgestellt auf VM, respektive sind zum Teil noch im Aufbau dieser Struktur.
Gute Erfahrungen haben wir aber mit Cisco EZVPN gemacht.
Damit benötigen wir beim Kunden nur noch eine IP Adressen aus dessen lokalen Netz. zur zusätzlichen Sicherheit authentifiziert sich der Cisco Router gegen einen Radius Server hier bei uns im Haus.
VPN Clients oder Logins über Webaccess nutzen wir nach Möglichkeit garnicht, oder nur dort wo derKunde partout nicht anders will.
Unsere Servicetechniker können nicht von außen in das Netz eines Kunden sondern nur (!) durch unser Hausnetz.
Also Token gesicherte Einwahl in unser Hausnetz, durch den Tunnel zum Kunden!
Performance mässig haben wir nur da Probleme wo es sich bei der Anbindung noch um Analoge Wählverbindungen handelt .
Tunnel Richtung Südamerika laufen mit einem lokalen Breitbandinternet Anschluss teilweise gut bis sehr gut!
brammer