3
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!
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: 150302
Url: https://administrator.de/contentid/150302
Ausgedruckt am: 22.11.2024 um 15:11 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
Servus,
...und danke fürs schnelle Feedback.
Das es aufwendig ist stimme ich zu - aber diese "gekapselte" Lösung hat eben auch viele Vorteile. Bei einem Terminalserver hätte ich das Problem mit den (leider vielen) unterschiedlichen VPN-Clients die sich ins Gehege kommen. Aber das mit der Synchronisation der VPN spezifischen Daten ist generell ein interessanter Ansatz.
@brammer:
Wie sieht dann euere Infrastruktur aus bzw. pro Kunde eine VM? Welches Betriebssystem läuft unter der virtuellen Haube. Bei uns momentan noch ein "schmalles" XP - da ich für eines unserer Produkte (industrieller Hutschienen-PC) sowieso demnächst ein "Windows Embedded Standard 7" Image bzw. Betriebssytem schnitzen muss, bin ich mir am überlegen ob ich eben nicht auch für die Remote-Lösung ein solches Image generieren soll. Durch den modularen Aufbau könnte man relativ viel Ballast weglassen und die Gesamtgröße der VM reduzieren. Falls es nämlich keine andere Lösung gibt, bleibt mir nur die Variante mit der Migration zwischen den Standorten. Und dann "zählt" jedes MB welches von Netz A inds Netz B migriert/verschoben wird.
Ich hab mir über die Tage noch einmal ein paar Gedanken gemacht bzw. komme ich auf verschiedene "Ansätze":
generell gilt:
Die Konstellation jeder Kunde = eigene VM möchte ich (wenn es eine Lösung geben sollte) auf jeden Fall auflösen bzw. in Zukunft anderst handhaben!
Jeder Mitarbeiter der einen Kunden via Remote-Anbindung bedient, hat zukünftig seine eigene VM (in der DMZ) - die jeweilige Anbindung zum Kunden (VPN Konfig.) sollte sich dynamisch in die VM "laden" lassen
- "Snapshot-Library" genial wäre es wenn es eine zentrale Snapshot-Bibliothek gäbe...jede VPN-Anbindung zum Kunden "steckt" in jeweils einem Snapshot vorkonfiguriert. Möchte unser Mitarbeiter eine Verbindung herstellen, lädt er sich eben den zentral abgelegten Snapshot in seine Remote-VM. Damit hätte er den bereits installierten und konfigurierten VPN Client zur Verfügung, Kundeninfos & Verknüpfungen auf dem Desktop usw. Das Ganze würde sich auch über die Standorte hinweg realisieren lassen.
Realisierbar? Müsste ich prüfen bzw. meines Erachtens ist eine Snapshot an eine VM gebunden bzw. kann nicht wahllos übergeben werden. Ein Austauschformat welches eben einen Snapshot repräsentiert wäre die Waffe der Wahl.
Weitere Ansätze über ein zentrales Gateway pro Standort habe ich wiederum begraben, da so etwas meines Erachtens kaum oder gar nicht realisierbar ist - gerade bei der Artenvielfalt an VPN Lösungen. Was ich bereits im oberen Thread geschrieben habe, war die Sache mit der Anwendungsvirtualisierung bzw. den entsprechenden VPN-Klienten zu kapseln (quasi portabel zu machen). Diesen wiederum zentral im Netz ablegen und jedem Mitarbeiter verfügbar zu machen. Denke auch nicht realisierbar, da sich nicht jede Software portabel machen lässt, Lösungen wie VMWare ThinApp extzrem teuer sind und und und.
Grüße Koll.
...und danke fürs schnelle Feedback.
Das es aufwendig ist stimme ich zu - aber diese "gekapselte" Lösung hat eben auch viele Vorteile. Bei einem Terminalserver hätte ich das Problem mit den (leider vielen) unterschiedlichen VPN-Clients die sich ins Gehege kommen. Aber das mit der Synchronisation der VPN spezifischen Daten ist generell ein interessanter Ansatz.
@brammer:
Wie sieht dann euere Infrastruktur aus bzw. pro Kunde eine VM? Welches Betriebssystem läuft unter der virtuellen Haube. Bei uns momentan noch ein "schmalles" XP - da ich für eines unserer Produkte (industrieller Hutschienen-PC) sowieso demnächst ein "Windows Embedded Standard 7" Image bzw. Betriebssytem schnitzen muss, bin ich mir am überlegen ob ich eben nicht auch für die Remote-Lösung ein solches Image generieren soll. Durch den modularen Aufbau könnte man relativ viel Ballast weglassen und die Gesamtgröße der VM reduzieren. Falls es nämlich keine andere Lösung gibt, bleibt mir nur die Variante mit der Migration zwischen den Standorten. Und dann "zählt" jedes MB welches von Netz A inds Netz B migriert/verschoben wird.
Ich hab mir über die Tage noch einmal ein paar Gedanken gemacht bzw. komme ich auf verschiedene "Ansätze":
generell gilt:
Die Konstellation jeder Kunde = eigene VM möchte ich (wenn es eine Lösung geben sollte) auf jeden Fall auflösen bzw. in Zukunft anderst handhaben!
Jeder Mitarbeiter der einen Kunden via Remote-Anbindung bedient, hat zukünftig seine eigene VM (in der DMZ) - die jeweilige Anbindung zum Kunden (VPN Konfig.) sollte sich dynamisch in die VM "laden" lassen
- "Snapshot-Library" genial wäre es wenn es eine zentrale Snapshot-Bibliothek gäbe...jede VPN-Anbindung zum Kunden "steckt" in jeweils einem Snapshot vorkonfiguriert. Möchte unser Mitarbeiter eine Verbindung herstellen, lädt er sich eben den zentral abgelegten Snapshot in seine Remote-VM. Damit hätte er den bereits installierten und konfigurierten VPN Client zur Verfügung, Kundeninfos & Verknüpfungen auf dem Desktop usw. Das Ganze würde sich auch über die Standorte hinweg realisieren lassen.
Realisierbar? Müsste ich prüfen bzw. meines Erachtens ist eine Snapshot an eine VM gebunden bzw. kann nicht wahllos übergeben werden. Ein Austauschformat welches eben einen Snapshot repräsentiert wäre die Waffe der Wahl.
Weitere Ansätze über ein zentrales Gateway pro Standort habe ich wiederum begraben, da so etwas meines Erachtens kaum oder gar nicht realisierbar ist - gerade bei der Artenvielfalt an VPN Lösungen. Was ich bereits im oberen Thread geschrieben habe, war die Sache mit der Anwendungsvirtualisierung bzw. den entsprechenden VPN-Klienten zu kapseln (quasi portabel zu machen). Diesen wiederum zentral im Netz ablegen und jedem Mitarbeiter verfügbar zu machen. Denke auch nicht realisierbar, da sich nicht jede Software portabel machen lässt, Lösungen wie VMWare ThinApp extzrem teuer sind und und und.
Grüße Koll.
