☰

Ubuntu를 다시 시작한 후 Wireguard 클라이언트는 더 이상 네트워크의 다른 호스트에 연결할 수 없습니다

tag-icon • tag-icon networking wireguard
Ubuntu를 다시 시작한 후 Wireguard 클라이언트는 더 이상 네트워크의 다른 호스트에 연결할 수 없습니다

나는 재택근무자입니다. 저는 WireGuard VPN을 약 16개월 동안 잘 사용해왔습니다. 가상 머신 내부의 Ubuntu Server 설치에서 실행됩니다. 하이퍼바이저는 TrueNAS CORE에서 실행됩니다.

WireGuard를 처음 설정한 이후로 클라이언트가 VPN을 통해 공용 인터넷에 연결할 수 없는 문제가 있었습니다. 그러나 VPN을 설정하는 주된 목적은 단지 내 서버를 원격으로 관리하고 네트워크에 있는 장치에 액세스하는 것이기 때문에 이는 큰 문제가 되지 않습니다. AllowedIPs클라이언트 구성의 설정을 사용하여 192.168.10.0/24VPN을 통해 내 서브넷으로만 트래픽을 라우팅하고 공용 인터넷으로의 트래픽은 WireGuard에 영향을 주지 않습니다.

최근에 Ubuntu 가상 머신을 다시 시작했습니다. 다시 온라인 상태가 되었을 때 WireGuard VPN에 연결할 수 있었고 VPN을 통해 Ubuntu VM(192.168.10.240)에서 실행되는 모든 서비스에 연결할 수 있었습니다. 하지만 네트워크의 다른 장치에는 연결할 수 없습니다.

Ubuntu VM을 사용하고 있는데 curl여전히 다른 장치(예: TrueNAS Core)를 볼 수 있습니다. 또한 SSH 터널링을 사용하여 이러한 다른 장치에 액세스할 수도 있습니다. 하지만 평소처럼 WireGuard를 통해 액세스할 수는 없습니다.

마지막으로 Ubuntu VM을 재부팅한 이후 제가 알고 있는 유일한 변경 사항은 Docker에 Pterodactyl Wings를 설치했다는 것입니다. 그러면 Docker 브리지 인터페이스가 추가됩니다. (서브넷 172.19.0.0/16, 게이트웨이 172.19.0.1) 하지만 제가 아는 한 이것이 WireGuard의 네트워크와 충돌할 이유는 없습니다.

저는 이 문제를 어디서부터 시작해야 할지 잘 모르겠습니다. 여러분의 조언을 듣고 싶습니다.

편집: 아래에서 볼 수 있듯이 IP 테이블이 MASQUERADE를 올바르게 처리하는지 확인하기 위해 PostUp/PostDown 명령을 사용했습니다. 내 WireGuard 서브넷( 10.8.0.1/24)은 네트워크의 다른 서브넷과 충돌하지 않습니다. 여러 피어를 구성했으며 각 피어는 /32이 서브넷에 고유한 피어를 가지고 있습니다. 내 클라이언트의 AllowedIP는 트래픽을 192.168.10.0/24.

내 클라이언트가 연결되면 10.8.0.2서버와 클라이언트에서 성공적으로 ping을 보낼 수도 있습니다. 또한 다른 클라이언트에서 한 클라이언트를 ping할 수도 있습니다.

192.168.10.240에 연결할 수 있으므로 이는 아마도 WireGuard 서버가 10.8.0.0/24에서 까지의 경로를 제공한다는 의미일 것입니다 192.168.10.0/24. 트래픽이 물리적으로 해당 호스트를 떠나야 할 때 문제가 발생하는 것 같습니다. 그렇다면 문제는 내 USG 라우터에 있는 것일 수도 있고(그러나 VM을 다시 시작할 때 아무 것도 변경하지 않은 경우) 아니면 Ubuntu가 NIC에서 관련 트래픽을 받아들이지 않는 것일 수도 있습니다.

이 문제를 해결하는 방법을 모르겠습니다.

편집 2: 클라이언트 장치를 홈 랩 네트워크에 물리적으로 연결했고 예상대로 모든 서버에 액세스할 수 있었습니다. 그런데 (물리적 연결은 유지하면서) WireGuard를 활성화했는데 192.168.10.240을 제외한 모든 서버에 액세스할 수 없었습니다. 따라서 이는 WireGuard 클라이언트가 확실히 터널을 통해 이러한 주소로 트래픽을 라우팅하고 있음을 나타냅니다.

또한 아주 최소한의 구성(아래 참조)을 일시적으로 사용해 보았지만 iptables변경되지 않았습니다.

WireGuard 서버 구성:

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = [redacted]
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.2/32

WireGuard 클라이언트 구성:

[Interface]
PrivateKey = [redacted]
Address = 10.8.0.2/24

[Peer]
PublicKey = [redacted]
AllowedIPs = 10.8.0.1/24, 192.168.10.0/24
Endpoint = example.org:51820

네트워크 세부정보:

  • 서브넷 192.168.10.0/24
  • 게이트웨이 192.168.10.1 (UniFi USG)
  • DHCP 범위 192.168.10.100 - 192.168.10.199

관련 호스트:

  • TrueNAS 서버(물리적) - 192.168.10.221
  • QuickSync 서버(물리적) - 192.168.10.222
  • TrueNAS용 IPMI(물리적) - 192.168.10.231
  • TrueNAS 서버에서 호스팅되는 Ubuntu VM - 192.168.10.240(WireGuard 서버!)
  • QuickSync 서버(macvlan)의 Docker 컨테이너 - 192.168.10.241

길:

C:\Users\test>tracert 192.168.10.221

Tracing route to 192.168.10.221
over a maximum of 30 hops:

  1     *       25 ms    20 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

서버에서 클라이언트로 ping

PING 10.8.0.2 (10.8.0.2) 56(84) bytes of data.
64 bytes from 10.8.0.2: icmp_seq=1 ttl=128 time=20.4 ms
64 bytes from 10.8.0.2: icmp_seq=2 ttl=128 time=27.0 ms
64 bytes from 10.8.0.2: icmp_seq=3 ttl=128 time=19.4 ms
64 bytes from 10.8.0.2: icmp_seq=4 ttl=128 time=27.1 ms
64 bytes from 10.8.0.2: icmp_seq=5 ttl=128 time=27.2 ms
^C
--- 10.8.0.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 19.409/24.223/27.209/3.536 ms

클라이언트에서 자체적으로 핑(VPN에서)

Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128
Reply from 10.8.0.2: bytes=32 time<1ms TTL=128

Ping statistics for 10.8.0.2:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

클라이언트에서 다른 클라이언트로 ping

Pinging 10.8.0.2 with 32 bytes of data:
Reply from 10.8.0.2: bytes=32 time=64ms TTL=127
Reply from 10.8.0.2: bytes=32 time=41ms TTL=127
Reply from 10.8.0.2: bytes=32 time=39ms TTL=127

Ping statistics for 10.8.0.2:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 64ms, Average = 48ms

미니멀리스트 iptables 구성

# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*filter
:INPUT DROP [0:0]
:FORWARD DROP [119314:15037722]
:OUTPUT ACCEPT [169491:32755967]
:DOCKER-USER - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -j ACCEPT
-A FORWARD -j DOCKER-USER
-A FORWARD -i wg0 -j ACCEPT
-A FORWARD -o wg0 -j ACCEPT
-A DOCKER-USER -j RETURN
COMMIT
# Completed on Sun Apr 14 14:57:35 2024
# Generated by iptables-save v1.8.7 on Sun Apr 14 14:57:35 2024
*nat
:PREROUTING ACCEPT [222:56161]
:INPUT ACCEPT [14:1327]
:OUTPUT ACCEPT [248:13567]
:POSTROUTING ACCEPT [256:16075]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sun Apr 14 14:57:35 2024

답변1

WireGuard 서버에서 LAN 인터페이스 이름이 변경되었거나 이전에 전달된 NAT 연결에 임시 iptables 규칙을 추가했지만 서버를 다시 시작할 때 규칙이 손실되었을 수 있습니다.

서버에서 WireGuard 서버에서 해당 LAN으로의 WireGuard 연결을 스푸핑하는 일반적인 패턴은 다음과 같습니다.

  1. 전달을 활성화하는 커널 매개변수(예 sysctl net.ipv4.conf.all.forwarding=1: )입니다.
  2. 방화벽을 통한 WireGuard 연결 전달 허용(예: iptables -A FORWARD -i wg0 -j ACCEPT그 반대)
  3. NAT는 해당 연결을 LAN으로 전달합니다(예 iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE: )

고객의 경우:

  1. 해당 설정에 LAN 서브넷을 추가합니다 AllowedIPs.

이러한 모든 사항이 있지만 NAT 규칙의 인터페이스 이름은 eth0첫 번째 이더넷 인터페이스의 전통적인 이름이지만 많은 Linux 배포판에서는 그럴 수 있습니다.미끄럽게 다르다.

가능한 문제를 확인하기 위해 서버에서 실행할 수 있는 좋은 명령 세트는 다음과 같습니다.

sudo wg
sudo cat /etc/wireguard/wg0.conf
sysctl net.ipv4.conf.all.forwarding
ip address
ip route
ip rule
sudo iptables-save
sudo nft list ruleset

다른 모든 방법이 실패하면 다음을 실행해 볼 수도 있습니다.tcpdump각 호스트에서(이와 같이Tcpdump를 사용하여 WireGuard 문제 해결기사 설명)은 트래픽이 삭제되는 정확한 위치를 식별하려고 시도합니다.

관련 정보