☰

Wireguard/iptables: ICMP 응답이 wg0으로 전달되지 않습니다.

tag-icon • tag-icon iptables wireguard
Wireguard/iptables: ICMP 응답이 wg0으로 전달되지 않습니다.

네트워크 다이어그램:Laptop (10.8.0.2) -> (wireguard) -> server A (10.8.0.1, 10.10.0.10) -> server B (10.10.0.20)

시퀀스 다이어그램

Wireguard를 통해 내 노트북(10.8.0.2)을 서버 A(10.8.0.1)에 연결했습니다. 서버 A(10.10.0.10)에는 ping/curl이 가능하지만 다른 서버 B(10.10.0.20)에는 불가능합니다.

내 노트북에서 서버 B를 실행하면 ping 10.10.0.20서버 A에서 다음을 찾을 수 있습니다.

  • tcpdump -nn -i wg0요청이 표시되지만 응답이 없습니다.
  • tcpdump -nn -i enp7s0요청과 응답을 보여줍니다

그래서문제는 응답이 enp7s0에서 wg0으로 전달되지 않는다는 것입니다.

그런데 왜 안되죠?

이것은 내 iptables 구성입니다.

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o enp7s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o enp7s0 -j MASQUERADE

노트북 와이어가드:

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

[Peer]
PublicKey = ...
AllowedIPs = 10.8.0.0/24,10.10.0.0/24
Endpoint = ...

서버 A 와이어가드:

[Interface]
PrivateKey = 
Address = 10.8.0.1/24
ListenPort = 51820
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o cilium_host -j MASQUERADE
PostUp = iptables -t nat -A POSTROUTING -o enp7s0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o cilium_host -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o enp7s0 -j MASQUERADE

[Peer]
PublicKey = 
AllowedIPs = 10.8.0.2/32

서버 B와 서버 A는 가상 사설망을 통해 연결됩니다.

업데이트: Wireguard 서비스 다시 로드

서비스를 다시 시작하는 것도 도움이 된 것 같습니다.

systemctl reload [email protected]
systemctl restart [email protected]

다음 규칙을 추가해 볼 수도 있지만 제거했는데도 여전히 작동했습니다.

PostUp = iptables -A FORWARD -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -o wg0 -j ACCEPT

업데이트: 기타 관련 문제(참고):

내 라우팅 테이블( )을 분석했을 때 ip route:

default via 172.31.1.1 dev eth0 
10.0.0.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.0.0.0/8 via 10.0.0.1 dev enp7s0 
10.0.0.1 dev enp7s0 scope link 
10.0.1.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 
10.0.1.50 dev cilium_host proto kernel scope link 
10.0.2.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.0.3.0/24 via 10.0.1.50 dev cilium_host proto kernel src 10.0.1.50 mtu 1400 
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.31.1.1 dev eth0 scope link

10.0.0.0/8 via 10.0.0.1 dev enp7s0더 큰 10.0.0.0/8 범위에 속하는 10.10.0.0/24 서브넷으로 인해 다른 경로와 충돌한다는 것을 깨달았습니다 . 그래서 Kubernetes/Cilium 네트워크를 이동하고(커피숍 등의 일반 네트워크와 충돌할 수 있는 10.0.0.0/8을 피하기 위해) VPC 네트워크도 좁혔습니다.

답변1

다시 생각해 본 결과, 작동하지 않는 이유는 아마도 AllowedIPs = 0.0.0.0/0서버 A에서 B로의 VPN 캡슐화 트래픽이 와이어 가드 터널로 라우팅되기 때문일 것입니다.

따라서 솔루션은 이를 AllowedIPs = 10.8.0.2/32.

관련 정보