From b92109ea5be87526a536bb55fe810aca361f59e3 Mon Sep 17 00:00:00 2001 From: jvoisin Date: Mon, 6 Jul 2020 11:58:42 +0200 Subject: [PATCH 1/1] Ajout de la new sur elenagb et ipv6 --- .../20200706_ipv6_elenagb.mdwn" | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 "Actualit\303\251s/20200706_ipv6_elenagb.mdwn" diff --git "a/Actualit\303\251s/20200706_ipv6_elenagb.mdwn" "b/Actualit\303\251s/20200706_ipv6_elenagb.mdwn" new file mode 100644 index 0000000..647f90b --- /dev/null +++ "b/Actualit\303\251s/20200706_ipv6_elenagb.mdwn" @@ -0,0 +1,61 @@ +[[!meta title="Tor, IPv6 et prises de tête"]] +[[!meta date="2020-07-06 12:00:00"]] + + +Chez nos-oignons, nous faisons tourner [plusieurs relais de sortie tor à haute +capacité](https://nos-oignons.net/Services/index.fr.html), et comme nous sommes en 2020, la plupart ont de l'IPv6. Tout allait +bien, jusqu'à ce qu'on se penche sur le cas +d'[elenagb](https://metrics.torproject.org/rs.html#details/F47B13BFCE4EF48CDEF6C4D7C7A99208EBB972B5), +notre nœud hébergé chez [Aquilenet](https://www.aquilenet.fr/), et nommé +d'après la professeure et écrivaine italienne [Elena Gianini Belotti]( +https://fr.wikipedia.org/wiki/Elena_Gianini_Belotti ). En effet, le consensus +pensait que son *exit policy* était `reject *:*`, alors que nous voulions qu'il +soit un relai de sortie. La seule différence avec nos autre relais était que +comme notre hébergeur ne nous attribuait pas l'IPv4, nous nous étions mis +d'accord pour n'avoir que du trafic sortant du réseau tor en IPv6. Il y avait +donc, quelque part, sûrement, un soucis de configuration. Le `torrc` +ressemblait à ça. En partant du principe que tout le reste soit correctement +configuré (`ORPort`, `address`, …), arrivez-vous à débusquer l'erreur? + +``` +# No exit in ipv4 +ExitPolicy reject *:* + +# Reduced exit policy in IPv6 +ExitPolicy accept6 *:20-23 # FTP, SSH, telnet +… +ExitPolicy accept6 *:64738 # Mumble +ExitPolicy reject6 *:* +``` + +L'astuce comme souligné dans le [ticket 16069](https://trac.torproject.org/projects/tor/ticket/16069) est que la configuration `reject +*:*` rejette l'IPv4 **ainsi** que l'IPv6 pour des raisons historiques. À ce +sujet, la [documentation](https://torproject.org/docs/tor-manual.html.en) indique : + +> Les entrées `accept6` et `reject6` affectent seulement les politiques de +sortie Ipv6. Utiliser des IPv4 avec `accept6` et `reject6` sera ignoré et +générera une alerte. Les entrées `accept`/`reject` permettent de prendre en +compte l'IPv4 ainsi que l'IPv6. Utiliser `*4` comme adresse IPv4 générique, et `*6` +comme IPv6 générique. `accept`/`reject *` sont utilisés comme générique +concernant IPv4 et IPv6. + +La bonne configuration ressemblerait donc plutôt à ceci: + +``` +# No exit in ipv4 +ExitPolicy reject *4:* + +# Reduced exit policy in IPv6 +ExitPolicy accept6 *:20-23 # FTP, SSH, telnet +ExitPolicy accept6 *:43 # WHOIS +… +ExitPolicy accept6 *:64738 # Mumble +ExitPolicy accept6 *:64738 # Mumble +ExitPolicy reject6 *:* + +``` + +Une bonne partie de la soirée fût passée à s'user les yeux sur le problème, et +évidement, aussitôt le mystère résolu, notre hébergeur nous a informé que +l'IPv4 nous était maintenant correctement attribuée, et qu'elenagb pouvait donc +avoir du trafic sortant de tor à la fois en IPv4 et en IPv6. -- 2.39.5