이 플러그인은 ProxyTracer API를 사용하여 Discourse에서 VPN, Tor 및 프록시 트래픽을 감지하고 차단합니다.
기능
새 사용자 등록, 기존 사용자 인증 또는 모든 사이트 방문자를 대상으로 전역적으로 VPN, Tor 및 프록시 사용자를 차단하는 데 대한 세밀한 제어를 제공합니다. VPN, Tor 및 프록시 사용자가 포럼에 읽기 전용으로 접근하는 것이 괜찮다면 API 요청을 절약하기 위해 사용자 등록 및 인증에만 활성화할 수 있습니다.
최근 IP 주소 평가를 저장하여 API 요청을 줄이고 지연 시간을 낮추기 위해 캐싱을 사용합니다. 설정에서 IP 주소 평가를 기억할 시간을 제어할 수 있습니다.
API 타임아웃 또는 네트워크 장애가 발생하면 대규모 계정 잠금을 방지하기 위해 사용자 접근을 우선시합니다. 이 동작은 옵션을 통해 변경할 수 있습니다.
상황에 따라 다릅니다. 안전 모드를 비활성화할 수 있는 사이트 설정이 있습니다. 이는 게이트된 토픽 컴포넌트나 사용자가 쉽게 비활성화해서는 안 되는 기타 컴포넌트/플러그인(광고, 게스트 게이트 등)에 유용합니다. 하지만 로그아웃 상태에서는 관리자가 안전 모드를 사용하는 것도 어려워집니다. 그래도 admin-login을 통해 활성화할 수 있다고 생각합니다.
이 플러그인의 경우, 안전 모드가 도움이 될 것이라고는 생각하지 않습니다. 안전 모드는 플러그인의 프론트엔드 부분만 비활성화하는데, 이 플러그인은 100% Ruby로 작성되어 있습니다. 따라서 JavaScript 커스터마이징을 비활성화하는 것이 도움이 될 것이라고 보지 않습니다. 이 사실 때문에 이 플러그인에 대해 조금 회의적입니다. 테마 컴포넌트인 것처럼 about.json 파일을 포함하고 있다는 사실도 회의적인 이유 중 하나입니다. 하지만 결국 각자는 자신의 포럼에 설치하는 코드에 대해 책임을 져야 합니다.
테스트해 주셔서 감사합니다! 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일 정도가 훨씬 더 좋은 이유입니다.
ProxyTracer가 효과적으로 작동하려면 Discourse 애플리케이션이 실제 클라이언트 IP 주소를 수신해야 합니다.
