4 203
modifications
« Clustering proxmox avec tinc » : différence entre les versions
Aller à la navigation
Aller à la recherche
→node 2
(→node 2) |
|||
| (14 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 20 : | Ligne 20 : | ||
Name = node1 | Name = node1 | ||
AddressFamily = ipv4 | AddressFamily = ipv4 | ||
#BindToAddress = x.x.x.x | |||
Device = /dev/net/tun | Device = /dev/net/tun | ||
Mode = switch | Mode = switch | ||
ConnectTo = node2 | ConnectTo = node2 | ||
TcpOnly=no | |||
IndirectData=no | |||
</pre> | </pre> | ||
| Ligne 72 : | Ligne 75 : | ||
Name = node2 | Name = node2 | ||
AddressFamily = ipv4 | AddressFamily = ipv4 | ||
#BindToAddress = x.x.x.x | |||
Device = /dev/net/tun | Device = /dev/net/tun | ||
Mode = switch | Mode = switch | ||
ConnectTo = node1 | ConnectTo = node1 | ||
TcpOnly=no | |||
IndirectData=no | |||
</pre> | </pre> | ||
| Ligne 116 : | Ligne 122 : | ||
Copiez le fichier <code>/etc/tinc/vpn/hosts/node2</code> de <code>node2</code> vers <code>/etc/tinc/vpn/hosts/</code> sur <code>node1</code> | Copiez le fichier <code>/etc/tinc/vpn/hosts/node2</code> de <code>node2</code> vers <code>/etc/tinc/vpn/hosts/</code> sur <code>node1</code> | ||
= | =Test de la configuration= | ||
Ajoutez ceci dans <code>/etc/hosts</code> sur les deux nodes : | Ajoutez ceci dans <code>/etc/hosts</code> sur les deux nodes : | ||
| Ligne 133 : | Ligne 139 : | ||
<pre>omping node1 node2</pre> | <pre>omping node1 node2</pre> | ||
Si tout fonctionne, activez le lancement automatique de tinc : | =Lancement automatique= | ||
Si tout fonctionne, nous allons configurer tinc pour se lancer automatiquement au démarrage, et ce avant corosync. | |||
<pre>systemctl edit --full tinc@vpn.service</pre> | |||
et ajoutez la ligne suivante dans la section <code>[Unit]</code> : | |||
<pre>Before=corosync.service</pre> | |||
Puis activez le lancement automatique de notre lien tinc "vpn" : | |||
<pre>systemctl enable tinc@vpn</pre> | <pre>systemctl enable tinc@vpn</pre> | ||
Puis recharger la configuration de systemd : | |||
<pre>systemctl daemon-reload</pre> | |||
=Création du cluster= | =Création du cluster= | ||
| Ligne 174 : | Ligne 191 : | ||
<pre>rm -rf /etc/pve/nodes/node5</pre> | <pre>rm -rf /etc/pve/nodes/node5</pre> | ||
=Afficher les informations | =Afficher les informations du lien tinc= | ||
Le démon tinc permet egalement d'obtenir des informations plus détaillées sur le statut du lien : | |||
<pre>tincd -n <nom> -kUSR2</pre> | <pre>tincd -n <nom> -kUSR2</pre> | ||
Les informations seront dans le syslog | Les informations seront dans le syslog | ||
=Note sur la gestion du démon tinc par systemd sous debian= | |||
Sous debian avec systemd, une unit par défaut est créée (<code>tinc.service</code>) mais ne reflete pas réellement le statut de votre démon tinc. Elle est utilisée pour propager les commandes stop, restart et reload à tous les démons tinc que vous pourriez lancer. | |||
Si vous créez deux VPN différents dans <code>/etc/tinc/vpnA/</code> et <code>/etc/tinc/vpnB/</code>, il vous faudra les activer avec : | |||
<pre> | |||
systemctl enable tinc@vpnA.service | |||
systemctl enable tinc@vpnB.service | |||
</pre> | |||
Puis vous pourrez gérer indépendamment vpnA ou vpnB en utilisant les noms complets, par exemple : | |||
<pre> | |||
systemctl status tinc@vpnA.service | |||
systemctl status tinc@vpnB.service | |||
</pre> | |||
L'unit <code>tinc.service</code> permet de propager les commandes stop, restart et reload à l'ensemble des démons tinc. Ainsi, <code>systemctl stop tinc.service</code> provoquera l'arrêt de <code>tinc@vpnA.service</code> et <code>tinc@vpnB.service</code> | |||
=Documentations tinc= | =Documentations tinc= | ||