Automatique, sécurisé, distribué, avec des connexions transitives (c'est-à-dire le transfert de messages lorsqu'il n'y a pas d'accès direct entre les abonnés), sans point de défaillance unique, homologue, testé dans le temps, faible consommation de ressources, réseau VPN à maillage complet avec la capacité de «perforer» NAT - est-ce possible?

Les bonnes réponses sont:

• oui, avec douleur si vous utilisez du tinc.
• oui, facile si vous utilisez tinc + tinc-boot

Lien de saut d'introduction

Description de la tinc

Malheureusement, quelques informations ont été publiées sur Tinc VPN sur Habré, mais quelques articles pertinents peuvent toujours être trouvés:

• Notre recette pour un serveur VPN à sécurité intégrée basé sur tinc, OpenVPN, Linux de Flant
• Liste des solutions VPN Full-Mesh du ValdikSS respecté

Des articles de langue anglaise peuvent être distingués:

• Comment installer Tinc et configurer un VPN de base sur Ubuntu 14.04 à partir de Digital Ocean
• Comment configurer tinc, un VPN Peer-to-Peer de Linode

La source d'origine est préférable de considérer la documentation originale de Tinc man

Ainsi (une réimpression gratuite sur le site officiel), Tinc VPN est un service (démon tincd ) qui assure le fonctionnement d'un réseau privé en tunnelant et en chiffrant le trafic entre les nœuds. Le code source est ouvert et disponible sous la licence GPL2. Comme la solution classique (OpenVPN), le réseau virtuel créé est disponible au niveau IP (OSI 3), ce qui signifie que, dans le cas général, il n'est pas nécessaire d'apporter des modifications aux applications.

Caractéristiques clés:

• cryptage, authentification et compression du trafic;
• solution entièrement maillée entièrement automatique, qui comprend l'établissement de connexions aux nœuds de réseau dans un mode tout avec tous ou, si cela n'est pas applicable, le transfert de messages entre des hôtes intermédiaires;
• punch NAT;
• la possibilité de connecter des réseaux isolés au niveau ethernet (commutateur virtuel);
• prise en charge de plusieurs systèmes d'exploitation: Linux, FreeBSD, OS X, Solaris, Windows, etc.

Il existe deux branches de développement tinc: 1.0.x (dans presque tous les référentiels) et 1.1 (bêta éternelle). L'article utilise la version 1.0.x partout.

Tinc 1.1x fournit plusieurs nouvelles fonctionnalités clés: une sécurité avant parfaite, une connectivité client simplifiée (remplaçant en fait tinc-boot ) et une conception généralement plus réfléchie.

Cependant, pour le moment, une version stable - 1.0.x est indiquée et mise en évidence sur le site officiel, donc lorsque vous utilisez tous les avantages de la branche 1.1, vous devez évaluer tous les avantages et les inconvénients de l'utilisation d'une version non finale.

De mon point de vue, l'une des possibilités les plus fortes est de transmettre des messages lorsque la connexion directe n'est pas possible. Dans le même temps, les tables de routage sont construites automatiquement. Même les nœuds sans adresse publique peuvent faire passer le trafic par eux-mêmes.

Considérons la situation avec trois serveurs (Chine, Russie, Singapour) et trois clients (Russie, Chine et Philippines):

• les serveurs ont une adresse publique, les clients derrière NAT;
• ILV lors de la prochaine interdiction des procurations probables Le Télégramme a bloqué tous les hébergeurs à l'exception de la Chine "amie";
• la frontière du réseau de la Chine <-> RF est instable et peut tomber (en raison de l'ILV et / ou de la censure chinoise);
• les connexions à Singapour sont conditionnellement stables (expérience personnelle);
• Manille (Philippines) n'est une menace pour personne et est donc autorisée pour tout le monde (en raison de la distance de tout le monde et de tout).

Par exemple, l'échange de trafic entre Shanghai et Moscou, considérons les scénarios de Tinc (environ):

1. Situation d'origine: Moscou <-> russie-srv <-> chine-srv <-> Shanghai
2. ILV a fermé la connexion avec la Chine: Moscou <-> russia-srv <-> Manille <-> Singapour <-> Shanghai
3. (après 2) en cas de panne du serveur à Singapour, le trafic est transféré vers le serveur en Chine et vice versa.

Dans la mesure du possible, Tinc tente d'établir une connexion directe entre les deux nœuds derrière NAT par poinçonnage.

Une brève introduction à la configuration tinc

Tinc se positionne comme un service facile à configurer. Cependant, quelque chose s'est mal passé - pour créer un nouveau nœud, il est minimalement nécessaire:

• Décrivez la configuration de l'hôte (type, nom) ( tinc.conf );
• Décrire le fichier de configuration (sous-réseaux desservis, adresses publiques) ( hosts/ );
• créer une clé;
• créer un script spécifiant l'adresse du nœud et les paramètres associés ( tinc-up );
• il est conseillé de créer un script qui efface les paramètres créés après l'arrêt ( tinc-down ).

De plus, lors de la connexion à un réseau existant, vous devez obtenir les clés d'hôte existantes et fournir les vôtres.

C'est-à-dire: pour le deuxième nœud

Pour le troisième

Lorsque vous utilisez la synchronisation bidirectionnelle (par exemple, à l' unison ), le nombre d'opérations supplémentaires augmente à N éléments, où N est le nombre de nœuds publics.

Nous devons rendre hommage aux développeurs de Tinc - pour l'inclusion dans le réseau, il suffit d'échanger des clés
avec un seul des nœuds (bootnode). Après avoir démarré le service et se connecter au participant, tinc obtiendra la topologie
réseau et pourra travailler avec tous les abonnés.

Cependant , si l'hôte de démarrage est devenu indisponible et que tinc a redémarré, il n'y a aucun moyen
se connectera au réseau virtuel.

De plus, les énormes possibilités du tinc, ainsi que la documentation académique de celui-ci (bien décrit, mais peu d'exemples), fournissent un vaste champ d'erreurs.

Raisons de créer tinc-boot

Si nous généralisons les problèmes décrits ci-dessus et les formulons en tâches, nous obtenons:

1. la capacité de créer un nouveau site avec un effort minimal est nécessaire;
   
   • potentiellement, il faut permettre de donner au spécialiste moyen (enikey) une petite ligne pour créer un nouveau nœud et se connecter au réseau;
2. il est nécessaire de fournir une distribution automatique des clés entre tous les nœuds actifs;
3. il est nécessaire de prévoir une procédure simplifiée d'échange de clés entre le bootnod et le nouveau client.

bootnode - un nœud avec une adresse publique (voir ci-dessus);

En raison des exigences de la revendication 2, on peut faire valoir qu'après l'échange de clés entre le nœud de démarrage et le nouveau nœud, et après
en connectant le nœud au réseau, la distribution de la nouvelle clé se fera automatiquement.

Ce sont ces tâches que tinc-boot effectue.

tinc-boot est une application open source autonome, en dehors de tinc , qui fournit:

• création simple d'un nouveau nœud;
• connexion automatique à un réseau existant;
• définir la majorité des paramètres par défaut;
• distribution clé aux nœuds de miel.

L'architecture

Le fichier exécutable tinc-boot compose de quatre composants: un serveur bootnode, un serveur de gestion de distribution de clés et des commandes de gestion RPC pour celui-ci, ainsi qu'un module de génération de nœuds.

Module de génération de nœuds

Le module de génération de nœuds ( tinc-boot gen ) crée tous les fichiers nécessaires au bon fonctionnement de tinc.

Simplifié, son algorithme peut être décrit comme suit:

1. Définissez le nom d'hôte, le réseau, les paramètres IP, le port, le masque de sous-réseau, etc.
2. Normalisez-les (tinc a une limite sur certaines valeurs) et créez celles qui manquent
3. Vérifier les paramètres
4. Si nécessaire, installez tinc-boot sur le système (désactivable)
5. Créer des subnet-down tinc-up , tinc-down , subnet-up , subnet-down
6. Créer un tinc.conf configuration tinc.conf
7. Créer un hosts/
8. Effectuer la génération de clés
9. Effectuer un échange de clés avec bootnode
   
   1. Chiffrez et signez votre propre fichier hôte avec une clé publique, un vecteur d'initialisation aléatoire (nom) et un nom d'hôte à l'aide de xchacha20poly1305, où la clé de chiffrement est le résultat de la fonction sha256 du jeton
   2. Envoyer des données via le protocole HTTP à bootnode
   3. Déchiffrez la réponse reçue et l'en X-Node tête X-Node contenant le nom du nœud de démarrage en utilisant le nom d'origine et le même algorithme
   4. En cas de succès, enregistrez la clé reçue dans les hosts/ et ajoutez une entrée ConnectTo au fichier de configuration (c'est-à-dire une recommandation où se connecter)
   5. Sinon, utilisez l'adresse suivante dans la liste du nœud de démarrage et répétez à partir de l'étape 2
10. Afficher des recommandations sur le démarrage d'un service

La conversion via SHA-256 est utilisée uniquement pour normaliser la clé à 32 octets

Pour le tout premier nœud (c'est-à-dire lorsqu'il n'y a rien à spécifier comme adresse de démarrage), l'étape 9 est ignorée. Drapeau - --standalone .

Exemple 1 - création du premier site public

L'adresse publique est 1.2.3.4

sudo tinc-boot gen --standalone -a 1.2.3.4

• l'indicateur -a vous permet de spécifier des adresses accessibles au public

Exemple 1 - Ajout d'un nœud non public au réseau

Le nœud de démarrage sera tiré de l'exemple ci-dessus. L'hôte doit avoir un noeud de démarrage tinc-boot en cours d'exécution (décrit plus loin).

sudo tinc-boot gen --token "MY TOKEN" http://1.2.3.4:8655

• l'indicateur --token définit le jeton d'autorisation

Module d'amorçage

Le tinc-boot bootnode déclenche un serveur HTTP avec une API pour l'échange de clés primaires avec de nouveaux clients.

Par défaut, le port 8655 .

Simplifié, l'algorithme peut être décrit comme suit:

1. Accepter une demande d'un client
2. Déchiffrez et vérifiez la demande à l'aide de xchacha20poly1305, à l'aide du vecteur d'initialisation transmis lors de la demande, et où la clé de chiffrement est le résultat de la fonction sha256 du jeton
3. Vérifier le nom
4. Enregistrez le fichier s'il n'y a pas encore de fichier du même nom
5. Chiffrez et signez votre propre fichier hôte et votre nom en utilisant l'algorithme décrit ci-dessus
6. Retour à l'article 1

Ensemble, le processus d'échange de clé primaire est le suivant:

Exemple 1 - démarrage du nœud de téléchargement

On suppose que l'initialisation initiale du nœud a été effectuée ( tinc-boot gen )

tinc-boot bootnode --token "MY TOKEN"

• l'indicateur --token définit le jeton d'autorisation. Il devrait en être de même pour les clients se connectant à l'hôte.

Exemple 2 - démarrage du nœud de téléchargement en tant que service

tinc-boot bootnode --service --token "MY TOKEN"

• l'indicateur --service de créer un service systemd (par défaut, pour cet exemple tinc-boot-dnet.service )
• l'indicateur --token définit le jeton d'autorisation. Il devrait en être de même pour les clients se connectant à l'hôte.

Module de distribution de clés

Le module de distribution de clés ( tinc-boot monitor ) lève un serveur HTTP avec une API pour échanger des clés avec d'autres nœuds à l'intérieur du VPN . Il est fixé à l'adresse émise par le réseau (le port par défaut est 1655 , il n'y aura pas de conflits avec plusieurs réseaux, car chaque réseau a / doit avoir sa propre adresse).

Le module démarre et fonctionne de manière entièrement automatique: vous n'avez pas besoin de travailler avec lui en mode manuel.

Ce module démarre automatiquement lorsque le réseau est tinc-up (dans le script tinc-up ) et s'arrête automatiquement lorsqu'il s'arrête (dans le script tinc-down ).

Prise en charge des opérations:

• GET / - donnez votre fichier de noeud
• POST /rpc/watch?node=<>&subnet=<> - récupérez un fichier à partir d'un autre nœud, en supposant qu'un service similaire est en cours d'exécution dessus. Par défaut, les tentatives sont expirées à 10 secondes, toutes les 30 secondes jusqu'à la réussite ou l'annulation.
• POST /rpc/forget?node=<> - laissez les tentatives (le cas échéant) de récupérer le fichier à partir d'un autre nœud
• POST /rpc/kill - met fin au service

De plus, chaque minute (par défaut) et lorsqu'un nouveau fichier de configuration est reçu, l'indexation des nœuds enregistrés est effectuée pour les nouveaux nœuds publics. Lorsque des nœuds avec l'indicateur d' Address sont détectés, une entrée est ajoutée au fichier de configuration tinc.conf pour recommander la connexion lors du redémarrage.

Module de distribution de clés (gestion)

Les commandes pour demander ( tinc-boot watch ) et annuler la demande ( tinc-boot forget ) du fichier de configuration à partir d'autres nœuds sont exécutées automatiquement lorsqu'un nouveau nœud est détecté (script de subnet-up ) et arrêté (script de subnet-down ), respectivement.

Lors de l'arrêt du service, le script tinc-down est tinc-down dans lequel la commande tinc-boot kill arrête le module de distribution de clés.

Au lieu du total

Cet utilitaire a été créé sous l'influence de la dissonance cognitive entre le génie des développeurs Tinc et la complexité croissante de la mise en place de nouveaux nœuds.

Les principales idées du processus de développement étaient les suivantes:

• si quelque chose peut être automatisé, il doit être automatisé;
• les valeurs par défaut devraient couvrir au moins 80% de l'utilisation (principe de Pareto);
• toute valeur peut être redéfinie en utilisant à la fois des indicateurs et des variables d'environnement;
• l'utilité devrait aider, et non pas provoquer le désir d'appeler toute la punition du ciel sur le créateur;
• l'utilisation d'un jeton d'autorisation pour l'initialisation initiale est un risque évident, cependant, dans la mesure du possible, il a été minimisé en raison de la cryptographie et de l'authentification totales (même le nom de nœud dans l'en-tête de réponse ne peut pas être remplacé).

Un peu de chronologie:

• La première fois que j'ai utilisé du tinc il y a plus de 4 ans. A étudié une quantité importante de matériel. Mettre en place un réseau idéal (à mon avis)
• Après six mois, le tinc a été remplacé par le zérotier, comme un outil plus pratique / flexible
• Il y a 2 ans, j'ai fait un playbook ansible pour déployer tinc
• Un mois plus tard, mon script est tombé en panne sur le déploiement incrémentiel (c'est-à-dire lorsqu'il est impossible d'accéder à tous les nœuds du réseau, ce qui signifie distribuer des clés)
• Il y a deux semaines, j'ai écrit un script bash-script qui était le prototype de tinc-boot
• Il y a 3 jours après la deuxième itération, la première version (0.0.1 pour être exacte) de l'utilitaire est née
• Il y a 1 jour, j'ai réduit l'installation d'un nouveau nœud à une seule ligne: curl -L https://github.com/reddec/tinc-boot/releases/latest/download/tinc-boot_linux_amd64.tar.gz | sudo tar -xz -C /usr/local/bin/ tinc-boot curl -L https://github.com/reddec/tinc-boot/releases/latest/download/tinc-boot_linux_amd64.tar.gz | sudo tar -xz -C /usr/local/bin/ tinc-boot
• Bientôt, la possibilité d'une connexion encore plus simple au réseau sera ajoutée (sans sacrifier la sécurité)

Pendant le développement, j'ai activement testé sur de vrais serveurs et clients (l'image de la description de tinc ci-dessus est tirée de la vie réelle). Désormais, le système fonctionne parfaitement et tous les services VPN tiers sont désormais désactivés.

Le code d'application est écrit en GO et est ouvert sous la licence MPL 2.0. Une licence (traduction gratuite) permet une utilisation commerciale (si quelqu'un en a soudainement besoin) sans ouvrir le produit source. La seule exigence est que les modifications doivent être transférées au projet.

Les demandes de piscine sont les bienvenues.

Liens utiles

• Dépôt
• Documentation Tinc