Ce plugin utilise l’API ProxyTracer pour détecter et bloquer le trafic VPN, Tor et proxy dans Discourse.
Fonctionnalités
Il vous offre un contrôle précis sur le blocage des utilisateurs VPN, Tor et Proxy lors des nouvelles inscriptions, de l’authentification des utilisateurs existants, ou globalement pour tous les visiteurs du site. Si vous acceptez que les utilisateurs VPN, Tor et Proxy aient un accès en lecture à votre forum, vous pouvez économiser des requêtes API en n’activant la fonctionnalité que pour l’inscription et l’authentification.
Il utilise la mise en cache pour stocker les évaluations récentes des adresses IP, réduisant ainsi le nombre de requêtes vers l’API et la latence. Vous pouvez contrôler la durée de conservation d’une évaluation d’adresse IP dans les paramètres.
En cas de délai d’attente de l’API ou d’échec réseau, le plugin priorise l’accès des utilisateurs pour éviter des blocages généralisés. Ce comportement peut être modifié via les options.
Prise en charge intégrée de la liste blanche pour les adresses IP exactes et les sous-réseaux CIDR.
Accédez au panneau d’administration de votre Discourse : Admin → Plugins → ProxyTracer pour trouver les paramètres de ProxyTracer.
Saisissez votre clé API dans le champ Clé API ProxyTracer.
Activez les paramètres de protection en basculant Activé lors de l'inscription, Activé lors de la connexion et/ou Activé pour tous les visiteurs.
Ajoutez les adresses IP ou plages CIDR de confiance à la liste Adresses IP autorisées.
(Optionnel) Ajustez le délai d’attente de l’API et la durée de cache Redis selon les besoins spécifiques du trafic de votre serveur.
(Optionnel) Personnalisez le message de blocage affiché aux utilisateurs bloqués. Par exemple, vous pouvez ajouter des instructions pour contacter l’administration du site s’ils estiment que le blocage est injustifié et qu’ils n’accèdent pas au site via un proxy, Tor ou VPN.
Voici un tableau des paramètres et de leurs descriptions :
Nom
Description
Délai d’attente API (ms)
Durée d’attente avant que l’API ne soit considérée comme ayant expiré.
Durée du cache (heures)
Durée de conservation d’une adresse IP avant de vérifier à nouveau l’API.
Ouvrir en cas d’erreur
Si l’API plante ou expire, autoriser l’utilisateur à s’inscrire/se connecter pour éviter de bloquer tout le monde.
Activé lors de l’inscription
Bloquer les proxies et VPN lorsqu’un nouvel utilisateur tente de s’inscrire.
Activé lors de la connexion
Bloquer les proxies et VPN lorsqu’un utilisateur existant tente de se connecter.
Activé pour tous les visiteurs
Bloquer les proxies et VPN d’accéder ou de consulter toute page du forum. (Attention : cela vérifie chaque visiteur et utilise intensivement votre quota API).
Message de blocage
Le message d’erreur exact affiché à l’utilisateur lorsqu’il est bloqué.
Adresses IP autorisées
Adresses IP ou plages CIDR (par exemple, 192.168.1.0/24) strictement autorisées à contourner le blocage.
Configuration réseau : Cloudflare et Proxies inverses
Pour que ProxyTracer fonctionne efficacement, l’application Discourse doit recevoir la véritable adresse IP du client.
Pour assurer une transmission correcte des adresses IP, vous pouvez suivre ces instructions détaillées.
Accès d’urgence
Si vous vous êtes exclu, vous pouvez retrouver l’accès en suivant ces étapes simples.
Si vous souhaitez tester le plugin, vous pouvez vous inscrire à ProxyTracer et obtenir des crédits API gratuits pour les tests.
Cela dépend. Il existe un paramètre de site qui vous permet de désactiver le mode sans échec, ce qui est utile pour le composant de sujet restreint et d’autres composants/plugins que les utilisateurs ne devraient pas pouvoir désactiver aussi facilement (publicité, porte d’entrée pour les invités, …). Mais lorsque vous n’êtes pas connecté, cela rendrait également l’utilisation du mode sans échec plus difficile pour les administrateurs. Je pense qu’ils peuvent toujours l’activer en utilisant admin-login.
Pour ce plugin, je doute que le mode sans échec soit utile. Le mode sans échec désactive uniquement la partie front-end des plugins, et ce plugin est écrit à 100 % en Ruby. Je ne pense donc pas que la désactivation des personnalisations JavaScript soit d’une grande aide. Ce fait me rend un peu sceptique quant au plugin, tout comme le fait qu’il inclue un fichier about.json comme s’il s’agissait d’un composant de thème. Mais en fin de compte, chacun est responsable du code qu’il installe sur son forum.
Vous avez tout à fait raison sur ce point. Je peux le confirmer grâce à mes propres tests effectués sur une instance Discourse fraîchement déployée. J’ai donc mis à jour la documentation avec des instructions qui fonctionnent réellement : se connecter au serveur et désactiver manuellement l’extension :
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
Je confirme que le mode sans échec est inaccessible lorsque le paramètre « Activé pour tous les visiteurs » est activé et qu’un utilisateur tente d’y accéder en se connectant via un VPN ou un proxy.
En effet, un fichier about.json est redondant pour les plugins standards. Je l’ai donc supprimé du dépôt.
Merci pour tous vos retours @Moin. Si vous avez d’autres remarques ou suggestions, n’hésitez pas à les laisser ici. Le code est entièrement open source et toute contribution est la bienvenue : GitHub - ProxyTracer/discourse-proxytracer.
Je suis en train de tester votre service et je souhaiterais savoir s’il y a un conflit avec le fichier « templates/cloudflare.template.yml » et si le plugin prendra en charge les éventuelles mises à jour du noyau de Discourse.
Je me demande ce que pourrait être le juste milieu pour ne pas perdre des utilisateurs comme moi, au sein d’une communauté respectueuse de la vie privée.
Merci pour les tests ! La documentation dans le README.md concernant l’intégration Cloudflare recommande clairement d’inclure "templates/cloudflare.template.yml", car c’est nécessaire pour s’assurer que Discourse extrait l’IP réelle de l’utilisateur lorsque le forum est derrière Cloudflare. Il n’y a donc aucun conflit avec ce modèle ; au contraire, son inclusion est indispensable.
Et oui, nous nous engageons à suivre les mises à jour du cœur de Discourse afin de garantir une compatibilité complète avec les versions plus récentes.
Je me demandais si l’ajout d’une option qui, au lieu de bloquer les utilisateurs, exigerait simplement de passer un hCaptcha, et de rendre cette option par défaut, constituerait un bon compromis. Cela ajouterait juste assez de friction pour rendre la tâche plus difficile aux spameurs et à ceux qui tentent d’échapper aux bannissements, tout en permettant aux utilisateurs légitimes qui souhaitent protéger leur vie privée en ligne via des VPN, Tor et similaires de continuer à accéder au service. Bien sûr, les administrateurs qui préféreraient toujours appliquer des bannissements complets sur ces réseaux conserveraient cette option. Qu’en pensez-vous ?
Merci beaucoup ! Je viens de faire un essai dans un environnement de test et ça fonctionne parfaitement.
Envisagez-vous d’ajouter une fonctionnalité liée aux IP/ASN des réseaux mobiles ? Sur mon forum, il est fréquent qu’un utilisateur quitte son réseau à large bande pour passer sur un réseau 4G/5G de son opérateur afin d’obtenir une adresse IP différente et ainsi contourner les restrictions d’inscription ou de connexion sur Discourse.
Il serait intéressant de pouvoir identifier lorsqu’une IP appartient à un ASN d’un opérateur mobile et, éventuellement, de permettre à ces adresses IP d’être traitées différemment lors de l’inscription ou de la connexion.
Cela sort peut-être un peu du cadre de ProxyTracer, car ce n’est pas nécessairement lié aux VPN ou aux proxys, mais cela serait utile pour un problème spécifique lié à la façon dont Discourse gère les limites de comptes par adresse IP.
Dans le cas de hCaptcha, je l’utilise déjà dans mon installation et ça fonctionne très bien ! Peut-être une fusion du plugin qui semble déjà intégré au cœur de Discourse avec votre plugin, une fonctionnalité supplémentaire qui sait ?
J’aime l’idée de maintenir un blocage total, car c’est finalement l’objectif, mais en ce qui concerne les adresses IPv4 et IPv6 des réseaux fixes et mobiles, il semble très utile de rendre cet accès plus difficile au moyen de défis, étant donné que l’IA adore créer des comptes sur les forums.
Bonjour, merci d’avoir pris ma réponse en considération. C’est vraiment un sujet qui m’intéresse, et je le trouve particulièrement sensible pour tout le monde, que ce soit en tant qu’utilisateurs ou administrateurs.
Franchement, je me sens comme un robot qui résout des CAPTCHA pour prouver qu’il est humain, en agissant délibérément comme un bot. J’ai mentionné dans des sujets connexes que l’implémentation d’Anubis (POW) me semble beaucoup plus agréable et fonctionnelle.
Je comprends que cela dépasse le cadre de ce projet, mais d’après ce que je peux analyser depuis ma position, l’utilisation du CAPTCHA que vous avez mentionné serait envisageable et pourrait littéralement ne pas bloquer les utilisateurs qui valorisent leur vie privée et souhaitent contribuer sans être tenus à l’écart.
Merci d’avoir effectué le test, c’est vraiment apprécié !
C’est un cas d’utilisation intéressant et je vois la valeur de donner aux utilisateurs un contrôle plus granulaire de ce type. Cela nécessiterait un nouveau point d’accès API, car le point d’accès v1 est assez limité en portée et ne fournit qu’une valeur booléenne indiquant si une adresse IP donnée est un proxy/VPN ou non.
J’ai quelques préoccupations concernant la précision des données lors de l’implémentation d’une telle fonctionnalité, car la précision de la détermination d’une adresse IP utilisée pour un réseau 4G/5G est loin d’être idéale, et il existe des applications où certains utilisateurs innocents pourraient être injustement pénalisés, comme ceux utilisant la large bande sans fil domestique 4G/5G.
Cela étant dit, pour le moment, l’objectif est d’améliorer le point d’accès v1 de l’API pour étendre la couverture.
Nous travaillons sur une nouvelle version de test de l’extension avec l’option captcha et nous envisageons également cette fonctionnalité. Est-ce qu’un onglet de ce type vous suffirait, ou pensez-vous que nous devrions y ajouter d’autres colonnes ?
@ProxyTracer J’ai une question concernant l’utilisation des requêtes. J’ai remarqué qu’une requête est décomptée à chaque nouveau connexion, même si le réseau n’est pas une VPN ou un proxy. Est-ce le comportement attendu ?
Je sais qu’il faut vérifier le registre de toute façon et que cela consomme probablement une requête du panneau de contrôle. C’est bien ça ? Car si je configure le blocage de tous les sites de ces accès, cela va consommer une quantité beaucoup plus importante de mon forfait, n’est-ce pas ?
J’ai envisagé d’augmenter la « durée du cache » à environ 30 jours, mais cela ne semble pas être l’idéal. Me trompé-je ?
Oui, pour déterminer si une adresse IP entrante appartient à un VPN/proxy ou non, le plugin doit interroger l’API ProxyTracer.
Cependant, le résultat (qu’il s’agisse d’une IP propre ou d’un VPN/proxy) est immédiatement mis en cache dans la base de données Redis de votre forum. Si cette même adresse IP se connecte à nouveau dans la fenêtre de durée de cache configurée (en heures), Discourse fournit la réponse directement depuis Redis. Ainsi, aucune requête API n’est déduite. La même chose s’applique si vous activez l’option de bloquer les VPN/proxies sur toutes les pages du site.
Le blocage au niveau des visiteurs consomme plus de requêtes que la protection limitée à la connexion en raison du trafic anonyme, mais la mise en cache Redis garantit que les vues de pages répétées par des visiteurs récurrents ne génèrent jamais de déductions API inutiles.
Les IP dynamiques résidentielles ou mobiles tournent occasionnellement, et de nouveaux nœuds de sortie VPN apparaissent au fil du temps. Ainsi, avec un cache de 30 jours, il est possible qu’une IP dynamique auparavant propre, qui serait réaffectée à un fournisseur de VPN, ne soit pas réexaminée avant l’expiration du cache. C’est pourquoi une durée d’environ 4 jours serait beaucoup plus appropriée que 30 jours.
Pour que ProxyTracer fonctionne efficacement, l’application Discourse doit recevoir la véritable adresse IP du client.
