☰

웹 서버는 nftables 포트 전달의 공용 IP 주소를 통해 자체적으로 액세스할 수 없습니다.

tag-icon • tag-icon port-forwarding nftables wireguard
웹 서버는 nftables 포트 전달의 공용 IP 주소를 통해 자체적으로 액세스할 수 없습니다.

에지 라우터로 WireGuard 서버가 있습니다. 모든 http 트래픽을 내 웹 서버로 전달합니다. 모든 것이 잘 작동하지만 문제가 있습니다. 웹 서버는 WireGuard 공용 IP 주소를 통해 자체적으로 연결할 수 없습니다. 웹 서버 컴퓨터에서 웹 브라우저를 사용하여 웹사이트에 접속할 수 없습니다.

NAT 기반이 이 문제를 해결할 수 있다는 것을 알았지만 daddr, IP 주소는 다를 수 있지만 고정될 수 있기 때문에 더 좋은 방법이 있는지 알고 싶습니다 iif. 내 Netgear WiFi 라우터는 이러한 문제 없이 포트 전달을 수행할 수 있습니다. 하지만 내부 규칙을 확인할 수 없으며 daddrNAT 기반을 사용하지 않는 것 같습니다.

이는 다음의 구성입니다.WireGuard 서버.

작업 그룹 0

interface: wg0
  Address = 10.0.0.1/24
  public key: (hidden)
  private key: (hidden)
  listening port: 51820
peer: (hidden)
  endpoint: (hidden):51820
  allowed ips: 10.0.0.2/32
  latest handshake: 56 seconds ago
  transfer: 20.69 MiB received, 115.85 MiB sent

nftables

table ip firewall {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        udp dport {51820} accept
        tcp dport {22} accept
        ip saddr 10.0.0.0/24 accept
    }
    chain prerouting {
        type nat hook prerouting priority dstnat;
        iif eth0 tcp dport {80,443} dnat to 10.0.0.2
    }
    chain postrouting {
        type nat hook postrouting priority srcnat;
        ip saddr 10.0.0.0/24 masquerade
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
        ct state established,related accept
        ct status dnat accept
        ip saddr 10.0.0.0/24 accept
    }
}

이는 다음의 구성입니다.네트워크 서버.

작업 그룹 0

interface: wg0
  Address = 10.0.0.2/24
  public key: (hidden)
  private key: (hidden)
  listening port: 51820
  fwmark: 0xca6c
peer: (hidden)
  endpoint: (hidden):51820
  allowed ips: 0.0.0.0/0
  latest handshake: 25 seconds ago
  transfer: 114.69 MiB received, 3.56 MiB sent
  persistent keepalive: every 25 seconds

답변1

이것은 사건이다NAT 루프백다루다.

현재 WireGuard 서버("WGS")는 다음에서만 사용할 수 있습니다.이더넷 0이므로 수신된 트래픽에는 아무 일도 일어나지 않습니다.작업 그룹 0.

On에서는 자체 공용 IP 주소에 대해 WGS 수신 트래픽을 포트 80,443으로 리디렉션해야 합니다. 하지만 질문이 있습니다. 규칙에서 이 로컬 대상 IP 주소를 알지 못한 채 패킷이 로컬로 분류될 것이라고 사전 라우팅 단계에서 어떻게 추측할 수 있습니까? 이 분류는 아직 발생하지 않은 라우팅 결정 단계에서 발생합니다. (이거 봐요개략도패킷 수명주기의 다양한 단계에 대한 요약을 확인하세요.

다음을 사용하여 패킷 경로에서 커널이 패킷을 어떻게 라우팅할지 동적으로 물어볼 수 있습니다.nftables'fib표현식(필수커널 >= 4.10):

FIB 발현

fib {saddr | daddr | mark | iif | oif} [. ...] {oif | oifname | type}

ㅏ거짓말하다표현식 쿼리거짓말하다(전달 정보 베이스) 특정 주소가 사용할 출력 인터페이스 색인과 같은 정보를 가져옵니다. 입력은 입력으로 사용되는 요소의 튜플입니다.거짓말하다기능을 찾아보세요.

이는 라우팅 단계 이전에 수행될 수 있으며 패킷이 다음과 같은 경우에만 리디렉션을 수행하는 데 사용됩니다.잠정적으로로컬 대상으로 분류됨: WGS에 속한 주소입니다. 이것이기 때문에사전 라우팅, 실제 라우팅 결정이 발생하면 더 이상 로컬 패킷으로 분류되지 않고 라우팅된 패킷(발신자에게 다시 전송)으로 분류됩니다.

수신된 트래픽 리디렉션작업 그룹 0(따라서 웹 서버("WS")에서) WGS에 속한 모든 주소로:

nft add rule ip firewall prerouting iif wg0 tcp dport '{ 80, 443 }' fib daddr type local dnat to 10.0.0.2

이는 WGS에 로컬이지만 원하는 경우 존재하지 않는 대상으로만 추가로 필터링할 수 있습니다(예: 여전히 WGS의 wg0 주소에서만 수신 대기하는 개인 관리 인터페이스에 액세스할 수 있음).작업 그룹 010.0.0.1은 다음을 사용하여 일치됩니다.

nft add rule ip firewall prerouting iif wg0 daddr != 10.0.0.1 tcp dport '{ 80, 443 }' fib daddr type local dnat to 10.0.0.2

nat/postrouting 체인은 이미 10.0.0.0/24 소스 범위 내의 모든 항목을 가장하고 있으므로 추가 단계가 필요하지 않습니다. WS의 소스 주소는 wg0의 WGS 주소로 대체됩니다. NAT 루프백을 위해서는 소스 변경이 필요합니다(WS는 자체 IP 주소에서 패킷을 받아들일 수 없습니다).

선택적으로 이 가장 규칙 앞에 전용 규칙을 삽입하여 다른 IP 주소를 선택할 수 있습니다.스나트교체. WS에서 WGS를 통해 라우팅되는 한 WGS 로컬인지 여부에 관계없이 모든 주소(생성된 소스 10.0.0.1 제외)가 가능합니다. 다음 예는 WS 및 WGS에 대한 라우팅 테이블이 제공되지 않기 때문에 정확하지 않을 수 있습니다. WS의 자체 10.0.0.2를 대체하기 위해 존재하지 않는 10.0.1.2 주소를 선택하면 WS의 자체 로그가 자체적으로 요청을 쉽게 식별할 수 있습니다.

nft insert ip firewall postrouting ip saddr 10.0.0.2 ip daddr 10.0.0.2 snat to 10.0.1.2

아니면 너무 보수적이다:

nft insert ip firewall postrouting ip saddr 10.0.0.2 ip daddr 10.0.0.2 tcp dport '{ 80, 443 }' ct status dnat oif wg0 snat to 10.0.1.2

관련 정보