Udalenka. une autre histoire de déploiement VPN d'auto-isolation

Une autre histoire sur la façon dont il était nécessaire de déployer rapidement l'accès à distance pour une petite entreprise qui s'est auto-isolée, mais ne pouvait pas se permettre de ne pas continuer à travailler.

Comme beaucoup d'autres, l'entreprise qui m'a demandé d'aider à organiser l'accès à distance a réalisé qu'elle devrait partir pour s'isoler quelques jours seulement avant que le président n'annonce ces mesures. Il fallait agir vite.

J'ai de l'expérience en transférant soudainement des employés pour travailler à distance sur des serveurs RDP. C'est un choc, tous les processus habituels tombent en panne, l'efficacité de l'interaction des employés diminue pendant un certain temps et certains processus s'arrêtent complètement. Il faut du temps pour que tous les processus fonctionnent à nouveau. En général, l'option de transférer tout le monde vers un serveur RDP en peu de temps, étant donné que l'environnement de travail familier des employés est en train de changer, ne convient pas. Par conséquent, il a été décidé de fournir un accès direct aux ordinateurs des employés. Dans ce cas, l'environnement de travail habituel reste avec le salarié; pratiquement rien ne change ni ne se casse en lui.

Dans l'entreprise, en plus des profils d'utilisateurs traditionnels, tels que les hommes d'affaires, les vendeurs, la comptabilité, etc., il y a des designers. Il était nécessaire de s'assurer que les concepteurs pouvaient utiliser RDP dans les applications graphiques. Vous devez également vous rappeler d'autoriser l'accès à distance des employés sur tous les PC et de mettre en place un programme d'économie d'énergie afin que les ordinateurs ne s'endorment pas la nuit.

Pour vérifier que les concepteurs peuvent travailler confortablement à distance, un test OpenVPN a été déployé, puis plusieurs concepteurs se sont connectés à leurs PC et ont vérifié le fonctionnement de leurs applications. L'accès à distance et un schéma d'économie d'énergie sont autorisés via les stratégies de groupe.

Afin de ne pas courir dans les performances du serveur VPN, pour pouvoir étendre les capacités d'accès et effectuer la maintenance du serveur sans arrêter cet accès, il a été décidé de déployer un cluster de plusieurs nœuds OpenVPN, accès auquel HaProxy va distribuer.

Schème:

Nous autoriserons les utilisateurs du domaine Active Directory. Pour ce faire, créez un groupe dans le domaine, par commodité, je l'ai appelé COVID-19. Dans ce groupe, vous devez ajouter des utilisateurs qui bénéficieront d'un accès à distance.

Pour une autorisation via AD dans OpenVPN, vous devez connecter le module conçu à cet effet.
Je ne travaillais pas avec openvpn-auth-ldap, je n'avais pas le temps de le comprendre, j'ai donc utilisé le script de ce référentiel . Il se connecte facilement, il suffit de le placer dans le répertoire openvpn, d'ajouter une ligne à openvpn.conf et de spécifier les paramètres de recherche pour l'utilisateur AD.

Il reste à écrire une instruction minimale pour l'auto-installation du client OpenVPN et du profil de connexion et à les envoyer aux utilisateurs.

En conséquence, en quelques jours, les employés de l'entreprise ont pu passer rapidement en mode d'auto-isolation et continuer à travailler.

Je ne donnerai pas une analyse détaillée des paramètres du serveur. Qui veut voir et même déployer un cluster, j'ai posté sur GitHub un playbook pour ansible, qui déploie HaProxy et OpenVPN sur trois serveurs. Attention! J'ai utilisé FreeBSD, les playbooks sont écrits pour ce système d'exploitation.

Pour que les administrateurs puissent voir qui est actuellement connecté et à quel serveur, ils ont écrit un script qui interroge le serveur par couronne et génère une simple page html. Les informations sur les employés sont extraites du wiki des ressources internes, vous pouvez supprimer ce bloc du script, en ne laissant que les comptes AD ou le remplacer par des informations sur les employés d'AD, si de telles informations y sont disponibles. Le script se trouve dans le dossier misc, dans le référentiel le lien auquel j'ai donné ci-dessus.

Pendant le fonctionnement, un bug désagréable a été détecté dans Windows 10 1903. Lors du travail à distance via RDP, 10 déconnectés, après quoi il était impossible de s'y connecter. Le bug sera corrigé par le patch KV4522355

C'est toute l'histoire. Son objectif, peut-être tardif, est de fournir un exemple de la façon dont vous pouvez rapidement déployer l'accès à distance à un coût minimal. La mise en œuvre convient aux petites et moyennes entreprises, avec la possibilité d'augmenter le nombre de connexions à distance.

Merci pour l'attention.