Advies nodig : meerdere VPN clients verbinden klanten

[speedme]

Hallo,

Ik werk voor een bedrijf met ongeveer 150 klanten.
Wij leveren support op een ERP pakket bij deze klanten, maar het is nu een drama om remote verbinding te maken naar de servers van deze klanten om support te kunnen verlenen.
Er zijn een hoop verschillende VPN clients waar onze klanten gebruik van maken.

Nu zijn er verschillende virtuele machines ingericht, op elke virtuele machine 1 of een aantal VPN clients geinstalleerd. De VM's zijn gebaseerd op Windows 7.

Bij een support call, logt onze support medewerker in op 1 van de VM's, start daar zijn VPN sessie om vervolgens een RDP sessie naar de klant te maken.
Op zich werkbaar, maar zeer frustrerend en tijdrovend. Daarbij kunnen maar 2 mensen tegelijkertijd via RDP naar 1 VM.

Ik ben het pakket Remote Desktop Manager (van Devolutions) aan het testen om in ieder geval centraal de "inbelverbindingen" aan te maken en het remote verbinden zoveel mogelijk te automatiseren, wat best goed werkt. Echter lopen wij tegen de limitaties aan van de virtuele machines.

Is er een betere manier om meerdere VPN clients centraal te kunnen gebruiken door meerdere medewerkers ?
(bijvoorbeeld verbinden naar een Terminal server, daar VPN sessie starten en vervolgens RDP sessie naar klant ?)

Onze support medewerkers willen geen VPN clients op hun eigen systemen geinstalleerd hebben, want dan hebben ze misschien wel 10 verschillende clients nodig en sommige bijten elkaar.

[Outerspace]

Waarom draai je de boel niet om? Schaf een pakket aan a la teamviewer (betaald) en laat men via die Teamviewer Quicksupport connectie maken.

[ak0nnmgn]

Wij gebruiken ook Teamviewer, maar dan meer voor gebruikersondersteuning. Voor de serveromgevingen hebben wij Kaseya en binnenkort N-Central om RDP op te zetten, deze pakketten moeten wel aangeschaft worden en vervolgens ingericht worden met bijvoorbeeld een agent op de clientserver(s).

[speedme]

Laat ik het probleem anders omschrijven :

Wij hebben ruim 100 consultants in dienst en al deze consultants bedienen hun klanten.
Dat kan zijn voor support, maar ook voor migratie-trajecten of installaties van ons ERP systeem.
Daarvoor dienen zij remote toegang te kunnen krijgen tot de server van de klant.
Deze remote toegang wordt vaak gedirigeerd door de klant en hebben wij "maar te slikken".
Veranderen gaat dus (bijna) niet

Deze klanten, of de hosting providers van deze klanten, hanteren enorm vaak VPN clients om remote verbinding te kunnen maken. HIerdoor gebruiken wij iets van 15 verschillende soorten VPN clients (Cisco AnyConnect, Cisco VPN, SonicWall, Sophos, Citrix Netscaler, etc etc)

Het is een b**tch om al deze VPN clients lokaal op een eigen systeem te installeren en gebruiken, omdat deze VPN clients elkaar vaak bijten en crashen of simpelweg niet werken.
Daarom hebben wij dus VM's in het leven geroepen om op elke VPN 1 of een paar VPN clients te installeren en dan via deze VM's de VPN verbinding met de klant te maken.

Dit is op zich een werkbare oplossing, maar omslachtig en zeer frustrerend omdat deze VM's maar 2 concurrent RDP sessies toe laten.

Ik zoek dus een mogelijkheid om meerdere VPN clients te kunnen gebruiken door meerdere consultants tegelijkertijd.

Zou het mogelijk zijn door een Terminal Server op het netwerk te installeren, op deze TS een aantal VPN clients installeren die binnen een TS sessie gebruikt kunnen worden door de consultants ?

[Hero of Time]

Dat zou ik niet doen. Veel VPN connecties passen de default gateway aan en als je al met 2 mensen tegelijk naar 2 verschillende klanten een verbinding opzet, gaat het helemaal mis met de gateways of kan de tweede niet eens connecten totdat de eerste zijn client verbinding verbreekt.

Afhankelijk van hoeveel klanten je hebt en de IP reeksen die ze gebruiken zou je nog kunnen vragen voor site-to-site connecties van jouw kantoor naar die van hun. Dan kunnen de consultants er standaard bij. Je zit dan alleen wel met een permanente verbinding met de klant en dat kan ook weer gevolgen hebben (denk aan en virus uitbraak bij een klant die jullie infecteert en zo naar een andere klant gaat).

Wat je nu hebt lijkt voor nu nog het beste.

[Brahiewahiewa]

Ik denk dat de keuze voor gehoste vm's niet zo'n praktische is.
Waarom draai je die dingen niet locaal, op de pc/laptop van de medewerker in kwestie?
Je biedt de virtual disks read-only aan op het netwerk, per vpn-smaak geordend of misschien wel per klant voorgeconfigureerd. 't Enige wat de medewerker dan nog nodig heeft is 1 à 2 Gieg vrije ram

[speedme]

Brahiewahiewa schreef op vrijdag 26 januari 2018 @ 02:48:
Ik denk dat de keuze voor gehoste vm's niet zo'n praktische is.
Waarom draai je die dingen niet locaal, op de pc/laptop van de medewerker in kwestie?
Je biedt de virtual disks read-only aan op het netwerk, per vpn-smaak geordend of misschien wel per klant voorgeconfigureerd. 't Enige wat de medewerker dan nog nodig heeft is 1 à 2 Gieg vrije ram

Het installeren van verschillende VPN clients lokaal op de systemen van de consultants is niet wenselijk, omdat deze elkaar bijten. Ze conflicteren met elkaar.
We hebben het dan over ongeveer 15 verschillende VPN clients.

[Kaalus]

speedme schreef op vrijdag 26 januari 2018 @ 08:45:
[...]


Het installeren van verschillende VPN clients lokaal op de systemen van de consultants is niet wenselijk, omdat deze elkaar bijten. Ze conflicteren met elkaar.
We hebben het dan over ongeveer 15 verschillende VPN clients.

@Brahiewahiewa bedoeld de VM's lokaal draaien. Je bied dan als het ware een soort thin client VM aan welke je medewerkers uitvoeren, hun werk bij de klant mee doen en weer dichtzetten. Als je per VM maar een enkele VPN client installeert heb je geen problemen dat ze elkaar in de weg zitten, en door het read only houden van je disks kunnen je medewerkers de VM ook niet om zeep helpen.

[speedme]

Kaalus schreef op vrijdag 26 januari 2018 @ 08:53:
[...]

@Brahiewahiewa bedoeld de VM's lokaal draaien. Je bied dan als het ware een soort thin client VM aan welke je medewerkers uitvoeren, hun werk bij de klant mee doen en weer dichtzetten. Als je per VM maar een enkele VPN client installeert heb je geen problemen dat ze elkaar in de weg zitten, en door het read only houden van je disks kunnen je medewerkers de VM ook niet om zeep helpen.

Uiteraard zal dit gaan werken, maar om 15 vm's (per VPN client 1 VM) lokaal neer te zetten is toch een aanslag op het lokale systeem.

Nu staan de Hyper-V VM's op het netwerk en loggen wij daar remote op in via RDP.
We doen ons werk en loggen vervolgens weer netjes uit.
De VM's zijn gebaseerd op Windows 7 (vanwege de oudere VPN clients die niet op Win10 werken).

[Kaalus]

speedme schreef op vrijdag 26 januari 2018 @ 09:01:
[...]


Uiteraard zal dit gaan werken, maar om 15 vm's (per VPN client 1 VM) lokaal neer te zetten is toch een aanslag op het lokale systeem.

Nu staan de Hyper-V VM's op het netwerk en loggen wij daar remote op in via RDP.
We doen ons werk en loggen vervolgens weer netjes uit.
De VM's zijn gebaseerd op Windows 7 (vanwege de oudere VPN clients die niet op Win10 werken).

Ook dat staat in de post van @Brahiewahiewa, je kunt de disks files gewoon aanbieden via het netwerk. Ook kun je differencing disks maken waardoor je het OS eenmaal opslaat en de rest toevoegt d.m.v. een differencing disk.
Zoals ook al eerder genoemd in andere reacties gaan die gedeelde VM's op een gegeven moment fout zodra een VPN client de gateway aan gaat zitten passen. En voor zover ik weet mag je Windows 7 niet gedeeld via RDP aanbieden volgens de licentie voorwaarden. Je zou dan dus alsnog per user een VM aan moeten bieden, kun je dat net zo goed lokaal doen

[Dennism]

speedme schreef op vrijdag 26 januari 2018 @ 09:01:
[...]


Uiteraard zal dit gaan werken, maar om 15 vm's (per VPN client 1 VM) lokaal neer te zetten is toch een aanslag op het lokale systeem.

Nu staan de Hyper-V VM's op het netwerk en loggen wij daar remote op in via RDP.
We doen ons werk en loggen vervolgens weer netjes uit.
De VM's zijn gebaseerd op Windows 7 (vanwege de oudere VPN clients die niet op Win10 werken).

Heb je wel je licensing voor elkaar, Windows 7 VM's mag je niet zomaar draaien op een gedeelde infrastructuur wanneer je geen Windows Enterprise licenties hebt met SA of VDA licenties, iets dat vaak over het hoofd gezien wordt, een behoorlijke kosten post kan zijn en je bij een audit behoorlijk kan bijten als je het niet voor elkaar hebt. Ook met meerdere users op 1 Windows 7 VM is volgens mij licentie technisch nog wel tricky.

Waar je ook naar zou kunnen kijken is een systeem als Kaseya, daarmee kan je ook server remote beheren en overnemen. Zit je alleen wel met het feit dat de klant moet toestaan om een agent te installeren op de betreffende servers. Maar je zit dan niet meer vast aan een sliert VPN clients, wat uit ervaring gesproken inderdaad zeer irritant kan zijn, een andere optie is zoals al genoemd mogelijk site-to-site verbindingen met strenge firewalling. Als dit soort zaken vanuit de klant echter geen optie is, en er vastgehouden moet worden aan alle VPN clients dan is denk ik de oplossing van Brahiewiewah nog een redelijk elegante.

[ Voor 4% gewijzigd door Dennism op 26-01-2018 10:29 ]

[Gijs007]

Als je het toch centraal wil regelen dan is het waarschijnlijk makkelijker en goedkoper om de huidige implementatie schaalbaar te maken.
Door bijvoorbeeld een krachtigere server te nemen en de VM's te klonen. Dan kunnen de consultants verbinding maken met de VM die zij nodig hebben.