좋아, pfSense가 포함된 서버 1개와 많은 가상 서버가 있습니다. 동일한 공용 IP에서 여러 웹 서버를 실행하기 위해 Nginx 업스트림 기능을 사용하고 있습니다. 물론 Nginx 프록시인 192.168.2.2가 아닌 실제 사용자의 IP를 알아야 하는데 pfSense(요즘 간단한 소비자 라우터가 있는)로 전환한 후 웹 서버에서는 실제 사용자의 IP를 볼 수 없습니다.
시스템/고급/방화벽 및 NAT에서 다음과 같은 다양한 설정을 변경해 보았습니다. 포트 전달을 위한 NAT 반사 모드 반사가 활성화된 자동 아웃바운드 NAT
또한 방화벽/NAT/아웃바운드에서 모든 모드를 시도했지만 도움이 되지 않았지만 모든 사용자는 여전히 내 프록시 서버의 IP를 가지고 있습니다.
그러면 어떻게 매스커레이딩을 비활성화하거나 실제 클라이언트 IP를 전달할 수 있습니까?
고쳐 쓰다
문제는 도메인이 아닌 하위 도메인에 있는 것 같습니다. 현재 상황:
클라이언트가 domain.com에 액세스하는 경우 모든 것이 정상이며 백엔드 서버가 실제 클라이언트 IP를 볼 수 있습니다.
클라이언트가 subdomain.domain.com에 액세스하는 경우 백엔드 서버는 프록시 서버 IP를 확인합니다.
모든 도메인 A 레코드는 외부 IP를 가리키고, pfSense는 포트 80을 프록시로 전달하고, 프록시는 도메인을 기반으로 해당 내부 서버로 전달합니다.
2개의 물리적 서버가 있습니다. 1개는 pfSense 라우터이고 다른 하나는 많은 가상 머신을 실행하는 virtualbox가 있는 서버입니다. 이 경우에는 4개의 가상 머신이 있습니다.
또 다른 흥미로운 점은 로컬 네트워크 내부에서 문제가 있는 subdomain.domain1.com에 액세스하려고 하면 다음과 같은 결과가 나온다는 것입니다.
마찬가지로 domain1.com, domain2.com 등도 문제 없습니다...
답변1
기본적으로 포트를 전달하는 방법에는 두 가지가 있습니다. 하나는 pfSense가 현재 수행하는 작업입니다(Linux의 "전체" NAT, conntrack). 클라이언트가 새 연결을 시작하면 pfSense는 NAT 테이블에 새 매핑을 생성하고 소스 출력을 전환합니다. 주소를 자체 주소로 변경하고 소스 포트(해당하는 경우)를 변경한 다음 수정된 패킷을 웹 서버로 보냅니다. 웹 서버는 자동으로 응답을 pfSense 시스템에 보냅니다. 그런 다음 필드를 다시 교환하고 패킷을 클라이언트에 보낼 수 있습니다. 이 접근 방식의 장점은 웹 서버가 작동하기 위해 이를 인식할 필요가 없다는 것입니다. 내가 기억하는 한, NAT 모드를 "AON"으로 전환하고 (webserverip, targetport)에 대해 NAT를 비활성화하면 pfSense에서 이 기능을 비활성화할 수 있습니다.
소비자 라우터는 간단한 포트 전달(Linux의 DNAT)을 수행합니다. 즉, 패킷이 도착하면 대상 주소를 교환하고 패킷을 웹 서버로 보냅니다. 이제 패킷에는 실제 소스 주소가 있으므로 웹 서버는 클라이언트의 실제 주소를 볼 수 있습니다. 불행히도 응답을 보낼 때 라우터는 자신의 (개인) 주소를 소스 필드에 입력하며, 라우터는 나가는 동안 공용 IP(Linux의 SNAT)와 교환해야 합니다. 웹 서버는 패킷을 클라이언트에 직접 주소 지정하므로 라우터는 기본 게이트웨이인 경우에만 이 작업을 수행할 수 있습니다! (또는 웹 서버에 꽤 멋진 라우팅 정책을 설정할 때)
답변2
문제는 pfSense나 프록시에 있는 것이 아니며 특정 백엔드 서버(녹색 사각형) 구성에 문제가 있습니다. 실수로 "헤더에 클라이언트 IP 사용" 옵션을 비활성화했습니다. 이 옵션이 활성화되어 있고 이 옵션에 대해 알고 있으므로 백엔드 서버 구성 오류입니다. 백엔드 서버는 Litespeed입니다.