A la découverte de Twingate

Il y a quelques mois, j’ai vu plusieurs vidéos YouTube sur un outil qui a captivé mon attention : Twingate. J’me suis tout de suite dit “Waaaaah, c’est le feu 🔥🔥” et je vais vous expliquer pourquoi ! 😏

En tant que vrai ptit geek, je mène régulièrement des expérimentations sur mon propre serveur Proxmox pour créer des environnements de tests et des labs. J’avais déjà eu l’idée de mettre en place un VPN pour y accéder depuis l’extérieur. Mais clairement, troooop la flemme de configurer et de maintenir un OpenVPN. Et puis c’était hors de question d’ouvrir et forward des ports sur ma box, d’un point de vue secu’ ça me dérange un peu… 😅

Un “beau” jour de décembre, après que deux neurones se soient touchées 🧠, j’ai eu une idée : “Ehhhhhh, mais est-ce que je testerai pas Twingate ?”

Il était temps d’avoir une alternative simple pour sécuriser mes connexions à distance, sans les tracas associés aux VPN. 🤔

Dans cet article, on va partir à la découverte de Twingate. Mais avant de tester tout ça, laissez-moi-vous le présenter plus en détail !

Les présentations

Twingate fonctionne avec une architecture qui s’éloigne des modèles de VPN conventionnels. Plutôt que de centraliser tout le trafic à travers un réseau privé virtuel, il utilise un modèle dit “Zero Trust”. Cela signifie que l’accès à une ressource n’est pas automatiquement accordé même si un utilisateur est connecté au réseau interne. (Et ça c’est cooooool 😎)

Et en clair, comment ça fonctionne ?

Lorsqu’un utilisateur tente d’accéder à une ressource distante, Twingate établit une connexion sécurisée “point to point” et uniquement pour la durée de la session en cours. Vous commencez à comprendre la diff’ avec les VPN ? Non? 

En gros, les vieux VPN (à la papa 🫢) impliquent souvent le routage de l’ensemble du trafic par un tunnel sécurisé. Perso, je trouve pas ça fou d’avoir accès à toutes les ressources d’un réseau interne. Je vous laisse imaginer l’impact en cas de compromission de vos accès VPN… Avec Twingate, on bénéficie d’une granularité des accès, réduisant les risques potentiels liés à une exposition excessive. 

Cet outil nous offre une plateforme centralisée où l’on peut définir et gérer des politiques d’accès en fonction des rôles, des utilisateurs et des ressources 🤩. J’adore cette approche qui permet une personnalisation uuuuultra fine des autorisations, garantissant que chaque utilisateur ne peut accéder uniquement aux ressources dont il a besoin. Si je simplifie en quelques mots, on définit qui a accès à quoi. Alors qu’avec un VPN, bien souvent c’est juste “on donne les accès” et amuses-toi, 

Il paraît qu’une image vaut 1000 mots, alors je vous ai fait un petit schéma :

Et cerise sur le gâteau Twingate, s’intègre à merveille dans les architectures cloud ☁️. Cela facilite et participe grandement à la sécurité des environnements hébergés sur des plateformes telles que AWS, Azure, ou GCP. 

Selon moi, cette intégration est cruciale dans un paysage technologique où les entreprises adoptent de plus en plus des solutions cloud sans pour autant prendre conscience des aspects sécurité et la gestion des accès que cela engendre. 

Avec Twingate, par exemple, on n’a plus besoin d’exposer ses clusters EKS au monde entier. Ils ont un blog post sur le sujet si ça vous intéresse. 😉

Mais plus globalement, on peut gérer l’accès à nos serveurs, nos clusters Kube’, applications, RDP, SSH…

Comment ça fonctionnement ? 🤔

Petit point sur ce que l’on va mettre en place et son fonctionnement :

Twingate s’appuie sur quatre composants 

• le contrôleur
• les clients
• les connecteurs
• les relais

Ensemble, ils garantissent que seuls les utilisateurs authentifiés peuvent accéder aux ressources auxquelles ils ont été autorisés à accéder.

Le contrôleur est le composant central de l’outil. C’est lui qui conserve les configurations faites via la console d’administration. Grâce à lui on va pouvoir enregistrer nos connecteurs et définir nos autorisations.

Le client, une fois installé sur notre poste de travail, va nous permettre de faire proxy pour les requêtes entre nous et nos ressources privées. C’est aussi grâce à lui que nous allons nous authentifier et avoir (ou non) nos autorisations pour router le réseau en conséquence.

Le connecteur, à sensiblement le même role que le client mais avec moins de responsabilité. En gros il va falloir l’installer sur nos ressources privées afin de maintenir la connexion active avec le relais Twingate.

Le relais, son rôle est très simple, servir de point de connexion pour les clients cherchant à établir une communication avec les connecteurs.

Si jaaaaaaamais ce n’est pas très clair, voici la documentation officielle expliquant plus en détail le fonctionnement de l’outil.

Allez, on remonte nos manches et au travail ! 🛠️

La mise en place

La première chose à faire : Se créer un compte. 

Dans mon cas, je vais faire simple et me connecter à avec le SSO Google. Je réponds à 2-3 questions, et voilàààà. On est connecté à la console Twingate !  

Maintenant, créons un nouveau remote network dans lequel on va définir notre serveur HomeLab afin d’y avoir accès. Pour ça on se rend dans la partie “remote network”. Dans mon cas, je sélectionne, “On Premise” et je rentre un nom. Après réflexion, j’aurai dû le nommer HomeLab et non Proxmox 😅

Vous êtes toujours là ? Super, on continue, ajoutons une ressource ! 

Je renseigne le réseau précédemment créé (Proxmox dans mon cas), puis l’IP interne de mon serveur Proxmox. Je laisse tout le reste avec les paramètres par défaut… Et nooooon, it’s a prank! Justement l’avantage de Twingate c’est d’être ultra-précis sur les accès. Donc, on va en profiter pour uniquement ouvrir l’accès à l’interface web Proxmox. Ouvrons le port 8006 et bloquons tout le reste. 

Last step, le connecteur. Pour être honnête, j’ai un peu galéré à trouver où l’on configure les connecteurs !

En gros, ça se passe dans le Remote network Proxmox que l’on a créé. Ils sont gentils, on en a déjà 3 de créés mais non configurés. Prenez-en un au hasard, ça n’a pas d’importance. J’ai décidé d’aller au plus simple, et de choisir l’installation via docker. Je génère mes tokens et je me retrouve avec la commande docker à copier/coller. Il ne me reste plus qu’à entrer cette commande sur mon serveur Proxmox :

docker run -d --sysctl net.ipv4.ping_group_range="0 2147483647" --env TWINGATE_NETWORK="antoinemayer" --env TWINGATE_ACCESS_TOKEN="xxxxxxxxxxxx" --env TWINGATE_REFRESH_TOKEN="xxxxxxxxxx"  --env TWINGATE_LABEL_HOSTNAME="`hostname`" --name "twingate-agate-xxx" --restart=unless-stopped --pull=always twingate/connector:1

Une fois le conteneur “up and running” depuis la console Twingate, je vois bel et bien que la communication est active : 

J’ai connu plus dur, je dois l’avouer ! 
Aller, dernière étape, installer le client sur notre poste de travail. Je ne vais pas m’étendre sur le sujet, la procédure va dépendre de votre OS. Je vous laisse avec la documentation officielle.

Le moment de vérité (spoiler : ça ne s’est pas passé comme prévu…)

Il est temps de tester ! 😍

Première chose à faire, changer de co’, je passe en 4G. Deuxièmement, on lance le client Twingate sur notre poste et on se connecte.

Cool, maintenant je n’ai plus à me rendre sur l’adresse de mon Proxmox comme si j’étais à la maison. Mais…. Ça ne fonctionne pas… 😭😭😭 après pas mal de tests je ne sais toujours pas pourquoi la connexion ne passe pas… Pourtant j’ai essayé d’ouvrir tous les ports mais ce n’était pas mieux… J’ai dû louper quelque chose. 

Dès que j’aurai trouvé la solution, je ferai une update, ne vous inquiétez pas, je ne vous laisserai pas tomber ! (d’ailleurs si vous savez d’où peut venir le problème, n’hésitez à me faire signe 😅)

En attendant, j’ai d’autres services qui tournent sur mon réseau local, comme UptimeKuma. Alors on essaye d’y accéder. 🙂

Je rajoute une ressource avec les infos adéquates pour accéder à ce service :

On teste ? On croise les doigts ? On invoque les dieux du cloud ?

Yeaaaaaah it woooorks ! Donc c’est bien la config pour Proxmox qui merde 🙁

Conclusion

En conclusion, j’ai vraiment kiffé Twingate. ça simplifie  de ouf l’accès aux services que j’héberge sur mon HomeLab. Quand je vois les limitations et les complexités des solutions VPN, je trouve que Twingate se démarque vraiment de par sa simplicité et son efficacité. 

En seulement 5 minutes, le déploiement de l’agent via un conteneur Docker a permis un accès à mon Proxmox (ça vaaaaaaa je rigole 🥲🥲). En tout cas, pour ce qui est des autres services de mon HomeLab, je peux y accéder depuis n’importe où, éliminant la nécessité de configurer des pare-feu ou de faire du port forwarding.

“It’s just works” résume parfaitement mon ressenti. A noter aussi que l’on a un plan gratuit, avec la possibilité d’inclure jusqu’à 5 utilisateurs sans frais supplémentaires. 

J’ai trouvé une solution rapide et adaptée à mes besoins en matière de sécurité pour accéder à mon HomeLab.

J’espère que l’article vous a plu, que je vous ai fait découvrir un outil, et donné envie de l’essayer ! 😁