ProxyTracer LogoProxyTracer
Skip to Content
Documentation플랫폼 및 CMSDiscourse

Discourse

Discourse에 대한 공식 ProxyTracer 통합입니다. 이 플러그인은 엔터프라이즈급 IP 인텔리전스를 커뮤니티에 제공하여 알려진 VPN, 프록시, 데이터 센터 및 Tor 노드를 자동으로 감지하고 등록, 로그인을 방지하거나 Discourse 포럼 전체를 보는 것을 방지하는 옵션을 제공합니다.

플러그인은 이 Github 저장소를 통해 배포됩니다.

특징

  • 관리자가 신규 사용자 등록, 기존 사용자 인증 중 또는 모든 사이트 방문자에 대해 전역적으로 IP 검증을 시행할 수 있도록 세분화된 제어가 가능합니다.
  • 내장된 Redis 캐싱은 최근 IP 주소 평가를 저장하여 외부 API 호출을 대폭 줄이고 대기 시간을 보장합니다.
  • API 시간 초과 또는 네트워크 오류가 발생하는 경우 플러그인은 사용자 액세스의 우선 순위를 지정하여 대규모 잠금을 방지합니다. 이 동작은 옵션을 통해 변경할 수 있습니다.
  • 정확한 IP 및 CIDR 서브넷 화이트리스트 지원 기능이 내장되어 있습니다.

설치

  1. SSH를 통해 서버에 액세스하고 Discourse 디렉터리로 이동합니다: 
    cd /var/discourse
  2. 편집을 위해 컨테이너 구성 파일을 엽니다. 
    nano containers/app.yml
  3. hooks 섹션을 찾아 docker_manager 설치 바로 아래에 저장소 복제 명령을 추가하세요. 
    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/proxytracer/discourse-proxytracer.git
  4. 구성 파일을 저장하고 Discourse 컨테이너를 다시 빌드하여 플러그인을 컴파일합니다. 
    ./launcher rebuild app

구성:

  1. ProxyTracer 대시보드에서 표준 API 키를 확보하세요.
  2. Discourse 관리 패널(관리자 → 플러그인 → ProxyTracer)로 이동하여 ProxyTracer의 설정을 찾으세요.
  3. 'ProxyTracer API Key' 필드에 API 키를 입력하세요.
  4. '가입 중 활성화', '로그인 중 활성화' 및/또는 '모든 방문자에 대해 활성화'를 전환하여 보호 매개변수를 활성화합니다.
  5. 신뢰할 수 있는 IP 또는 CIDR 범위를 '허용 목록에 있는 IP' 목록에 추가하세요.
  6. (선택 사항) 서버의 특정 트래픽 요구 사항에 맞게 API 시간 초과 및 Redis 캐시 기간 제한을 조정합니다.
  7. (선택 사항) 차단된 사용자에게 표시되는 차단 메시지를 사용자 정의합니다. 예를 들어, 차단이 보증되지 않고 프록시나 VPN을 통해 사이트에 액세스하지 않는다고 판단되는 경우 사이트 관리팀에 문의하기 위한 지침을 추가할 수 있습니다.

Settings Screenshot

네트워크 구성: Cloudflare 및 리버스 프록시

ProxyTracer가 효과적으로 작동하려면 Discourse 애플리케이션이 실제 클라이언트 IP 주소를 받아야 합니다. 인프라가 Cloudflare 또는 다른 역방향 프록시를 활용하는 경우 Discourse는 기본적으로 프록시 노드의 IP 주소를 기록하여 ProxyTracer의 작업을 신뢰할 수 없게 만들 수 있습니다.

정확한 IP 전달을 보장하려면 서버 아키텍처와 일치하는 아래 구성 지침을 따르십시오.

직접 Cloudflare 연동 (기본 설치)

이는 Discourse 서버가 인터넷에 직접 연결하고 DNS 및 에지 프록시에만 Cloudflare를 사용하는 경우에 적용됩니다. 이 표준 설정에서는 Cloudflare의 IP 범위를 신뢰하고 수신 헤더에서 실제 클라이언트 IP를 추출하도록 Discourse를 구성해야 합니다.

  1. SSH를 통해 서버에 연결하고 컨테이너 구성을 편집합니다: nano /var/discourse/containers/app.yml
  2. templates: 블록을 찾아 공식 Cloudflare 템플릿 templates/cloudflare.template.yml을 추가합니다. 
    templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
  - "templates/cloudflare.template.yml"
  3. 파일을 저장하고 Discourse 컨테이너를 다시 빌드하여 변경 사항을 적용합니다. ./launcher rebuild app

다중 계층 프록시 아키텍처 (Cloudflare + 로컬 리버스 프록시)

이는 Discourse 인스턴스가 Cloudflare 뒤에 있는 로컬 서버 관리 패널이나 역방향 프록시(예: CloudPanel, Nginx Proxy Manager, Traefik, Plesk)를 통해 라우팅되는 경우에 적용됩니다. 다중 계층(또는 "이중") 역방향 프록시 아키텍처에서는 트래픽이 Cloudflare에 의해 직접 전달되는 것이 아니라 로컬 네트워크 인터페이스에 의해 Discourse로 전달되기 때문에 표준 Discourse cloudflare.template.yml이 실패합니다. 이 시나리오에서는 Cloudflare 템플릿을 사용하지 마세요.

대신 'CF-Connecting-IP' 헤더에서 실제 클라이언트 IP를 추출하도록 로컬 역방향 프록시를 구성해야 합니다. 단, 신뢰할 수 있는 Cloudflare IP 주소에서 발생하는 트래픽에만 해당됩니다. 소스를 확인하지 않고 이 헤더를 무작정 전달하면 악의적인 사용자가 IP 주소를 스푸핑하여 속도 제한과 차단을 우회할 수 있습니다.

Nginx 예: 먼저, 서버 블록 구성(위치 블록 외부)에서 Cloudflare의 IP 범위를 신뢰할 수 있는 프록시로 정의하세요. 
# IPv4 Cloudflare IP, https://www.cloudflare.com/ips/ 참조
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
 
# IPv6 Cloudflare IP
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;
 
real_ip_header CF-Connecting-IP;

다음으로 location / 또는 @reverse_proxy 지시문을 찾으세요. 위 구성으로 인해 Nginx는 이제 요청이 실제로 Cloudflare를 통과한 경우에만 '$remote_addr'을 실제 클라이언트 IP로 안전하게 확인합니다. IP 전달 헤더를 다음과 같이 수정하십시오.

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
    ...    
}

구성을 저장하고 호스트의 Nginx 서비스를 다시 로드합니다. 이 단계에는 Discourse 컨테이너 재구축이 필요하지 않습니다.

검증 및 테스트

네트워킹 구성이 올바른 데이터를 ProxyTracer에 성공적으로 전달하는지 확인하려면:

  1. Discourse 관리 대시보드(관리자 → 사용자)로 이동합니다.
  2. 최근 활동에 대해서는 '등록 IP' 또는 '마지막 IP' 열을 검토하세요.
    • 잘못된 설정: Cloudflare IP(전체 목록은 여기 참조) 또는 로컬 네트워크 IP(예: 127.0.0.1, 172.x.x.x)를 관찰하면 IP 전달이 실패합니다. ProxyTracer는 이 상태에서 사이트를 보호할 수 없습니다.
    • 올바른 설정: 표준 고유 주거용 IP 주소를 관찰하는 경우 네트워크 아키텍처가 올바르게 구성된 것이며 ProxyTracer가 트래픽을 적극적으로 모니터링하고 있는 것입니다.

긴급 접근

💡
잠겼습니까? ProxyTracer를 구성하는 동안 실수로 자신의 IP 주소를 차단한 경우(예: 현재 VPN에 연결되어 있음) SSH를 통해 플러그인을 비활성화하여 액세스를 다시 얻을 수 있습니다.
cd /var/discourse
./launcher enter app
rails c
SiteSetting.proxytracer_enabled = false
exit
exit

라이센스

이 플러그인은 GNU Affero General Public License v3.0(AGPLv3)에 따라 라이센스가 부여되었습니다.

최종 수정일:
Discord 봇Flarum