Admin. sys. Nos oignons (version publique) > Services > Tor

Relai

Nos oignons fait actuellement tourner plusieurs relais.

Pour surveiller l'état d'un des relais, on peut utiliser la commande arm. Pour les nœuds de marcuse et marylou, il faut utiliser soit arm -s /run/tor-instances/1/control ou arm -s /run/tor-instances/2/control.

Informations de contact

La configuration de Tor permet de spécifier des informations de contact via la directive ContactInfo. Pour nos relais, il faut mettre :

ContactInfo 0x9F29C15D42A8B6F3 Nos oignons <adminsys@nos-oignons.net> - 17WLwtW63FrHeMAEVkALnwhfmizBxGXDW1

On y trouve : l'adresse des adminsys, le long keyid pour la clé GnuPG correspondante, ainsi qu'une adresse pour recevoir des bitcoins (via OnionTip.com par exemple).

IPv6

Pour que nos relais soient accessibles en IPv6, il faut spécifier IPv6Exit 1 (depuis la version 0.2.9.10, ce qui remplace la configuration qui consistait à lister manuellement les adresses IPv4 et IPv6 à utiliser avec de multiples lignes ORPort).

Plusieurs daemons tor

Tor ne parallélise pas encore très bien ses calculs. Il est donc parfois nécessaire de faire fonctionner plusieurs daemons tor plutôt qu'un seul pour tirer le maximum d'un système multi-cœur ou multi-CPU.

Afin de faire tourner deux daemons tor, on a utilisé la méthode suivante sur marcuse et marylou :

  • Deux utilisateurs dédiés _tor-1 et _tor-2 et leurs groupes respectifs ont été créés pour agir en lieu et place de debian-tor, mais on peut aussi utiliser debian-tor tout simplement.
  • Le service est lancé par systemd, à qui on confie la multi-instantiation au moyen de deux Unit files dans /etc/systemd/system/multi-user.target.wants : tor@1.service et tor@2.service.
  • Le fichier de configuration /etc/tor/torrc a été remplacé par deux fichiers /etc/tor/instances/1/torrc et /etc/tor/instances/2/torrc. À noter que plusieurs paramètres qui pourraient être définis dans ces torrc (DataDirectory, PidFile ou ControlSocket) le sont dans les fichiers /run/tor-instances/1.defaults et 2.defaults, crées par systemd à partir d'un template, et utilisés en lieu et place de /usr/share/tor/tor-service-defaults-torrc comme argument de l'option --defaults-torrc.
  • Les données se trouvent dans /var/lib/tor-instances/1 et /var/lib/tor-instances/2.
  • Les données volatiles se trouvent dans /run/tor-instances/1 et /run/tor-instances/2. Ces répertoires sont créés au démérrage de chaque instance grâce à un paramètre ExecStartPre dans les Unit files.

Dans la pratique, on peut suivre la procédure utilisée pour marylou

Il est important de forcer l'adresse IP dans les options ORPort, DirPort, Address et OutboundBindAddress.

AppArmor

Vu que la multi-instantiation de tor par systemd utilise des chemins (pour PidFile, ControlSocket, etc) non prévus par le profil AppArmor fourni, il est nécessaire d'ajuster ce profil.

Ça se fait en créant un fichier /etc/apparmor.d/local/system_tor :

owner /var/lib/tor-instances/{1,2}/** rwk,
owner /var/lib/tor-instances/{1,2}/ r,
/var/lib/tor-instances/{1,2}/** r,
/etc/tor/instances/{1,2}/* r,
/{,var/}run/tor-instances/{1,2}/ r,
/{,var/}run/tor-instances/{1,2}.defaults rw,
/{,var/}run/tor-instances/{1,2}/control{,.authcookie} w,
/{,var/}run/tor-instances/{1,2}/control.authcookie.tmp rw,
/{,var/}run/tor-instances/{1,2}/socks w,
/{,var/}run/tor-instances/{1,2}/tor.pid w,

Et aussi un fichier /etc/systemd/system/tor@.service.d/override.conf :

[service]
AppArmorProfile=system_tor
ReadWriteDirectories=-/proc

C'est en place sur marcuse et marylou.

ekumen et AlGrothendieck n'hébergeant qu'une seule instance de Tor, la configuration par défaut a été conservée.

Autres