☰

NAT 뒤의 웹 서버, 공용 IP 주소를 수신하는 방법

tag-icon • tag-icon debian web-server routing ip nat
NAT 뒤의 웹 서버, 공용 IP 주소를 수신하는 방법

NAT를 사용하여 방화벽 뒤에서 실행되는 데비안 웹 서버(nginx)가 있습니다. 웹 서버는 SSL과 자체 IP 주소가 필요한 여러 사이트를 호스팅하고 있습니다. SSL 사이트는 특정 IP 주소만 수신하고 공유 사이트는 공유 IP만 수신하도록 하고 싶습니다.

지금은 모든 도메인에 대해 와일드카드 *를 듣고 있습니다. 이는 단일 LAN 주소를 듣고 IP 주소가 아닌 호스트 이름을 기반으로 사이트 콘텐츠를 제공한다는 의미입니다. 이 부분을 수정하고 싶습니다.

올바른 행동 방침은 무엇입니까? 각 IP 주소에 대해 1:1 NAT를 생성하고 LAN IP를 수신할 네트워크 인터페이스에 추가한 다음 LAN IP를 특정 도메인에 할당하는 것입니까? 아니면 더 좋은 방법이 있나요? 공인 IP를 전달하고 이를 기반으로 조치를 취할 수 있는 방법이 있나요? 감사해요.

답변1

아니요. NAT를 수행한 후에는 적어도 직접적으로는 원래 대상 IP 주소를 통과할 수 없습니다.

192.0.2.0/24를 외부 IP 블록으로 사용하고 198.51.100.0/24를 내부 IP 블록으로 사용하겠습니다(RFC5737 참조).

당신이 할 수 있는 일은 다음과 같습니다:

  • 각 외부 IP의 대상 포트를 내부 IP의 다른 포트 집합으로 NAT합니다. 예를 들어 NAT 192.0.2.1:80 및 192.0.2.1:443 ~ 198.51.100.1:80 및 198.51.100.1:443, NAT 192.0.2.2:80 및 192.0.2.2:443 ~ 198.51.100.1:81 및 198.5 1 .100.1:444. 적절한 서비스에 대해 차별화된 포트를 수신하도록 웹 서버를 구성합니다. 다른 용도로 사용하지 않는 포트를 선택하고 방화벽 설정을 확인하세요.
  • 웹 서버에 추가 내부 IP를 할당합니다. 예를 들어 웹 서버 198.51.100.1 및 198.51.100.2를 할당합니다. 적절한 외부 IP/포트 쌍을 해당 내부 IP/포트 쌍(예: 192.0.2.1 ~ 198.51.100.1 및 192.0.2.2 ~ 198.51.100.2)으로 NAT합니다. 적절한 서비스를 적절한 내부 IP에 바인딩하도록 nginx에 지시합니다.

후자의 솔루션을 선택하면 비정상적인 포트 번호 및 포트 변환을 처리하지 않기 때문에 환경이 더 간단해지고 표준을 더 잘 준수하게 되지만 각 웹 서버에 여러 개의 내부 IP를 할당해야 합니다. 딱 하나만). 또한 후자의 솔루션을 사용하는 경우 1:1 NAT를 사용할 수 있습니다.

즉, 웹 서버를 NAT 뒤에 배치할 이유가 전혀 없다면(NAT는 방화벽이 아님) 외부 IP만 수신하면 됩니다(이렇게 하려면 토폴로지 변경도 필요함).

답변2

사이트마다 다른 공용 IP 주소를 원하는 것 같습니다. 이는 방화벽이 다양한 공용 IP 주소를 제공해야 함을 의미합니다. 그런 다음 방화벽은 다른 IP 주소에 대한 요청을 nginx 서버로 전달하거나 해당 요청을 동일한 IP 주소의 다른 포트로 전달할 수 있습니다. 그런 다음 nginx 서버가 그에 따라 응답하도록 할 수 있습니다.

방화벽을 구성하는 방법은 방화벽에 따라 다릅니다. 예를 들어, iptables를 사용하면 스크립트에서 다음과 같은 작업을 수행할 수 있습니다.

KINCAID=192.168.1.112
EXTIPJMN=50.60.70.80
iptables -t nat -A PREROUTING -d $EXTIPJMN -p tcp -i $EXT --dport 8081 -j DNAT --to-destination $KINCAID:8080

그러면 IP 주소 EXTIPJMN(50.60.70.80) 및 포트 8081에서 들어오는 요청을 IP 주소 KINCAID(192.168.1.112) 및 포트 8080의 내부 서버로 라우팅합니다.

https를 통해서도 동일한 IP 주소로 다른 사이트를 제공할 수 있으며 이는 대부분의 최신 클라이언트에서 지원되지만 전부는 아닙니다.

관련 정보