해당 커밋은 여러분이 의존하고 있던 구성 오류를 수정한 것이었지만, 동시에 해당 헤더를 설정하여 최종 사용자가 자신의 IP 주소를 위장할 수 있는 문제를 허용했을 수도 있습니다.
컨테이너에 다른 어떤 프로세스도 통신할 수 없다고 확신한다면, 소켓 사용이 필요 없는 더 쉬운 방법이 실제로 있습니다. 이 방법에 대한 가이드를 방금 작성했습니다.
@CLOUD_PHT 님의 구성에 대해, 컨테이너 정의에 다음을 추가해야 합니다(이미 run 섹션이 존재한다면 해당 지시문들을 그 섹션에 추가하고, 그렇지 않다면 run 섹션을 추가하세요):
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
```\n
다음 내용도 필요할 수 있습니다:
```yaml
- file:
# 호스트에서 하나, CloudFlare에서 하나이므로 최소 두 개의 항목이 있으므로 재귀적 처리를 켜야 합니다.
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
이는 서버에서 실행 중인 nginx가 최종 사용자의 실제 IP를 결정하기 위해 Cloudflare 헤더를 자체적으로 처리하는지(권장됨) 아니면 단순히 자신의 헤더를 위에 추가하는지에 따라 달라집니다. 자세한 내용은 https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7를 참조하세요.
다른 독자들에게: 이 지시문은
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
모든 구성에 적합하지 않다는 점을 유의하세요. 이 IP에서 Discourse 컨테이너로의 모든 연결이 신뢰할 수 있는 경우에만 이 작업을 수행하십시오.
구체적으로, IPv6 구성의 알려진 문제는 서버로의 IPv6 연결이 docker에 의해 IPv4를 통해 전달된다는 점입니다. 이 방식은 모든 연결이 호스트의 docker0 IP 주소에서 온 것처럼 보이게 만듭니다. 위의 지시문을 구성에 적용하면 IPv6으로 연결하는 모든 사용자가 마음대로 IP 주소를 위장할 수 있게 됩니다.