This plugin uses the ProxyTracer API to detect and block VPN, Tor and proxy traffic in Discourse.
Features
It gives you fine control over blocking VPN, Tor and Proxy users during new user registrations, existing user authentication, or globally for all site visitors. If you’re fine with VPN, Tor and Proxy users having read access to your forum then you can save on API requests and only enable it for user registration and authentication.
It uses caching to store recent IP address evaluations thus saving requests to the API and lowering latency. You can control how long to remember an IP address evaluation in the settings.
In the event of an API timeout or network failure, the plugin prioritizes user access to prevent wide-scale lockouts. This behavior can be changed through the options.
Built-in support for exact IP and CIDR subnet whitelisting.
Navigate to your Discourse administration panel: Admin → Plugins → ProxyTracer to find ProxyTracer’s settings.
Input your API key into the ProxyTracer API Key field.
Enable the protection parameters by toggling Enabled during Signup, Enabled during Login and/or Enabled for All Visitors.
Add any trusted IPs or CIDR ranges to the Whitelisted IPs list.
(Optional) Adjust the API timeout and Redis cache duration limits to suit your server’s specific traffic requirements.
(Optional) Customize the Block Message that appears to blocked users. For instance, you can add instructions for contacting the administration of the site in case they believe that the block isn’t warranted and that they’re not accessing the site through a proxy, Tor or VPN.
It depends. There is a site setting that allows you to disable safe mode, which is helpful for the gated topic component and other components/plugins users shouldn’t easily disable like that (advertising, guest gate, …). But while you are logged out, that would also make using safe mode more difficult for admins. I think they can still enable it using admin-login.
For this plugin, I doubt safe mode helps. Safe mode disables only the front-end part of plugins, and this plugin in 100% Ruby. So I don’t think disabling JavaScript customizations is any help. This fact makes me a little skeptical about the plugin, as does the fact that it includes an about.json file as if it were a theme component. But in the end, everyone is responsible for the code they install on their forum.
You are completely right on this, I can confirm this through my own testing with a freshly spun up Discourse instance. I went ahead and updated the documentation with instructions that actually work which consist of logging into the server and manually disabling the addon:
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit
I can confirm that safe mode is inaccessible when the “Enabled for All Visitors” setting is enabled and someone tries to access safe mode while connecting using a VPN/proxy.
Indeed, an about.json is redundant for standard plugins, I went ahead and removed it from the repo.
Thanks for all of your feedback @Moin. If you have any other remarks or suggestions feel free to leave them here. The code is fully open source and any contribution is welcome: GitHub - ProxyTracer/discourse-proxytracer.
테스트해 주셔서 감사합니다! README.md 문서에서 Cloudflare 통합에 대해 언급된 부분에서, "templates/cloudflare.template.yml" 파일의 포함을 명확히 권장하고 있습니다. 이는 포럼이 Cloudflare 뒤에 있는 경우 Discourse가 사용자의 실제 IP를 올바르게 추출하도록 보장하는 데 필수적이기 때문입니다. 따라서 해당 템플릿과 충돌하는 문제가 없으며, 오히려 이를 포함하는 것이 필요합니다.
그리고 네, 우리는 Discourse의 코어 업데이트를 따르겠다고 약속하며, 새로운 버전과의 완전한 호환성을 보장하기 위해 노력하고 있습니다.
사용자를 차단하는 대신 단순히 hCaptcha를 통과하도록 요구하는 옵션을 추가하고, 이를 기본값으로 설정하는 것이 좋은 타협점이 될 수 있을지 궁금합니다. 이렇게 하면 스팸 사용자나 밴 회피자에게는 충분히 마찰을 주어 접근을 어렵게 만들면서도, VPN이나 Tor 등을 통해 온라인 프라이버시를 보호하려는 합법적인 사용자의 접근은 허용할 수 있기 때문입니다. 물론 해당 네트워크에 대한 완전한 차단을 유지하길 원하는 관리자에게는 여전히 해당 옵션이 제공될 것입니다. 여러분의 생각은 어떠신가요?
모바일 네트워크의 IP/ASN 관련 기능을 추가할 계획이 있으신가요? 제 포럼에서 자주 발생하는 상황이 있는데, 사용자가 브로드밴드 네트워크에서 벗어나 통신사의 4G/5G 네트워크로 전환하여 다른 IP를 확보하고, 이를 통해 Discourse의 가입 또는 로그인 제한을 우회하려는 경우입니다.
IP가 모바일 통신사의 ASN에 속하는지 식별하고, 필요에 따라 이러한 IP가 가입/로그인 과정에서 다르게 처리되도록 허용할 수 있다면 유용할 것 같습니다.
이것은 VPN/프록시와 직접적인 관련이 없으므로 ProxyTracer의 범위를 약간 벗어나는 내용일 수 있지만, Discourse가 IP당 계정 수 제한을 처리하는 방식과 관련된 특정 문제에 있어서는 도움이 될 것입니다.
hCaptcha의 경우, 저는 이미 제 설치 환경에서 사용 중이며 매우 잘 작동하고 있습니다! Discourse 코어에 이미 포함된 것으로 보이는 플러그인과 여러분의 플러그인을 통합하여 추가 기능을 제공하는 것도 좋은 방법일 수 있겠네요.
완전한 차단을 유지하는 아이디어를 좋아합니다. 그것이 본래의 목적이기도 하니까요. 하지만 고정 및 모바일 네트워크의 IPv4와 IPv6에 관해서는, AI가 포럼에서 계정을 생성하는 것을 매우 좋아하기 때문에 챌린지를 통해 이러한 접근을 어렵게 만드는 것이 매우 유용해 보입니다.
흥미로운 사용 사례입니다. 사용자에게 이러한 세밀한 제어를 제공하는 데 가치를 인정합니다. 이는 v1 엔드포인트가 범위가 다소 제한적이고 특정 IP가 프록시/VPN인지 여부에 대한 불리언 값만 제공하기 때문에 완전히 새로운 API 엔드포인트가 필요합니다.
이러한 기능을 구현하려는 시도에 대해 데이터 정확성에 대한 몇 가지 우려가 있습니다. IP가 4G/5G 네트워크에 사용되는지 여부를 판별하는 정확도는 아직 이상적이지 않으며, 4G/5G 홈 무선 광대역 사용자와 같이 무고한 사용자가 부당하게 불이익을 받을 수 있는 애플리케이션이 있기 때문입니다.
그러나 현재는 API의 v1 엔드포인트를 개선하여 커버리지를 확장하는 데 집중하고 있습니다.
캡차 옵션이 포함된 확장 프로그램의 새로운 테스트 릴리스를 작업 중이며, 이 기능도 고려하고 있습니다. 이러한 탭이 충분하다고 생각하시나요, 아니면 더 많은 컬럼을 추가할 수 있다고 생각하시나요?
수신된 IP 주소가 VPN/프록시인지 아닌지를 결정하기 위해 플러그인은 ProxyTracer API를 쿼리해야 합니다.
그러나 결과(깨끗한 IP인지 VPN/프록시인지)는 포럼의 Redis 데이터베이스에 즉시 캐시됩니다. 설정된 ‘캐시 지속 시간(Cache Duration hours)’ 시간 창 내에서 해당 IP가 다시 로그인하는 경우, Discourse는 Redis에서 직접 답변을 제공합니다. 따라서 API 요청이 차감되지 않습니다. 모든 사이트 페이지에서 VPN/프록시를 차단하는 옵션을 활성화한 경우에도 동일한 원리가 적용됩니다.
방문자 수준 차단(Visitor-level blocking)은 익명 트래픽으로 인해 로그인 전용 보호(Login-only protection)보다 더 많은 요청을 소비합니다. 그러나 Redis 캐싱 덕분에 복귀 방문자의 반복적인 페이지 뷰는 불필요한 API 차감을 발생시키지 않습니다.
동적 주거용/모바일 IP는 때때로 순환하며, 새로운 VPN 출구 노드(Exit Node)도 시간이 지남에 따라 생성됩니다. 따라서 30일 캐시를 사용하면 이전에 깨끗했던 동적 IP가 VPN 제공업체에 재할당된 경우에도 캐시가 만료될 때까지 다시 확인되지 않을 수 있습니다. 이것이 30일보다 4일 정도가 훨씬 더 좋은 이유입니다.
For ProxyTracer to function effectively, the Discourse application must receive the true client IP address.
