☰

2개의 Wireguard 터널 간 트래픽 라우팅

tag-icon • tag-icon networking iptables ssh-tunneling route
2개의 Wireguard 터널 간 트래픽 라우팅

이것은 내 로컬 네트워크의 아치입니다.

기계 아키텍처:

<wg_client_1 (int워킹그룹 1 )> ----- <(int워킹그룹 1 ) wg_term_1 (int워킹그룹 0 워킹 )> ----- <(int그룹 0) wg_term_2 (int eth2)>

네트워크 아키텍처:

<||wg_client_1|| (int wg1 : 10.242.0.2)(10.242.0.0/24 network)> ----- <(int wg1 : 10.242.0.1)(10.242.0.0/24 network)||wg_term_1||(int wg0 : 10.241.0.1)(10.241.0.0/24 network)> ----- <(int wg0 : 10.241.0.2)(10.241.0.0/24 network) ||wg_term_2|| (int eth2 :10.243.0.1) (10.243.0.0/24 network)>

  • 모든 머신은 내 로컬 네트워크의 가상 머신입니다.
  • 모든 컴퓨터에는 "실제" 주소( 192.168.123.0/24)가 있지만 터널을 통해 통신하기를 원합니다. 네트워크 주소를 사용하여 SSH를 통해 컴퓨터에 연결합니다 192.168.123.0/24.
  • wg_client_1(int wg1) 와 (int) wg_term_1사이에 터널이 있습니다 wg1. 터널이 작동 중입니다. wg_term_1핑할 수 있고 10.242.0.2, 여전히 wg_client_1핑할 수 있습니다 10.242.0.1.
  • wg_term_1와 사이에 터널을 만들었습니다 wg_term_2. 터널도 운영 중입니다. wg_term_1핑할 수 있고 10.241.0.2, 여전히 wg_term_2핑할 수 있습니다 10.241.0.1.

wg이는 명령의 결과입니다 wg_client_1.

# wg
interface: wg1
  public key: yQO6xpv+3HC+xTyfxzC503vr+E84VBnphntfwFJXREA=
  private key: (hidden)
  listening port: 49149

peer: CywdYs8L0TD7zLvMqHnqL/N2WoqRmDuDvn6skg+8wUc=
  endpoint: 192.168.123.21:51821
  allowed ips: 10.0.0.0/8
  latest handshake: 8 seconds ago
  transfer: 11.39 KiB received, 236.84 KiB sent

wg이는 명령의 결과입니다 wg_term_1.

# wg
interface: wg1
  public key: CywdYs8L0TD7zLvMqHnqL/N2WoqRmDuDvn6skg+8wUc=
  private key: (hidden)
  listening port: 51821

peer: yQO6xpv+3HC+xTyfxzC503vr+E84VBnphntfwFJXREA=
  endpoint: 192.168.123.23:49149
  allowed ips: 10.0.0.0/8
  latest handshake: 58 seconds ago
  transfer: 236.84 KiB received, 11.43 KiB sent

interface: wg0
  public key: HGF89Hcphaf+Uua214hSc/mZa/p2vmIUeT6IwrN7I3Y=
  private key: (hidden)
  listening port: 51820

peer: +xTyPmYo9+IPBC72MFzIWFHrQyz5N6v67rjZz3q5CR4=
  endpoint: 192.168.123.22:51820
  allowed ips: 10.241.0.2/32
  latest handshake: 17 seconds ago
  transfer: 10.03 KiB received, 233.33 KiB sent
  persistent keepalive: every 25 seconds

wg이는 명령의 결과입니다 wg_term_2.

# wg
interface: wg0
  public key: +xTyPmYo9+IPBC72MFzIWFHrQyz5N6v67rjZz3q5CR4=
  private key: (hidden)
  listening port: 51820

peer: HGF89Hcphaf+Uua214hSc/mZa/p2vmIUeT6IwrN7I3Y=
  endpoint: 192.168.123.21:51820
  allowed ips: 10.241.0.1/32
  latest handshake: 1 minute, 3 seconds ago
  transfer: 1.23 KiB received, 6.79 KiB sent
  persistent keepalive: every 25 seconds

이제 클라이언트 네트워크 트래픽을 10.242.0.0/24두 번째 터널( wg_term_1. wg_term_2나는 wg_client_1( )가 ( 또는 ) 10.242.0.1핑을 할 수 있기를 원합니다 .wg_term_210.241.0.210.243.0.1

그래서 wg_client_1에 다음 경로를 추가했습니다.

ip route add 10.241.0.0/24 via 10.242.0.1
ip route add 10.243.0.0/24 via 10.242.0.1

wg_term_1에 대한 경로는 다음과 같습니다.

ip route add 10.242.0.0/24 via 10.242.0.1
ip route add 10.241.0.0/24 via 10.241.0.2
ip route add 10.243.0.0/24 via 10.241.0.2

ping 10.241.0.2하지만 에서 실행하면 wg_client_1작동하지 않습니다. 다음은 wg_term_1의 tcpdump입니다.

# tcpdump -i wg0 -i wg1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg1, link-type RAW (Raw IP), capture size 262144 bytes
03:58:31.451778 IP 10.242.0.2 > 10.241.0.2: ICMP echo request, id 432, seq 1, length 64
03:58:32.464024 IP 10.242.0.2 > 10.241.0.2: ICMP echo request, id 432, seq 2, length 64
03:58:33.488174 IP 10.242.0.2 > 10.241.0.2: ICMP echo request, id 432, seq 3, length 64

아무것도 표시되지 않습니다. 따라서 트래픽이 라우팅되지 않습니다 tcpdump.wg_term_2

wg_term_1IPv4 전달은 다음에서 활성화됩니다 wg_term_2. net.ipv4.ip_forward=1

무슨 일이 일어나고 있고 트래픽이 올바르게 라우팅되지 않는 이유를 설명할 수 있는 사람이 있습니까? 감사해요

답변1

고쳐 쓰다: 이 답변의 대부분을 다시 작성했으며 OP의 질문이 작동하는 동안 내가 수정한 결함이 있는 설명을 사용합니다. 물론 암호화 키 연결은 두 WireGuard 인터페이스 간에 독립적이며 서로 상호 작용하지 않습니다. WireGuard 인터페이스당 여러 피어 간의 상호 작용만 있지만 OP는 인터페이스당 하나의 피어만 사용하므로 여기에는 특정 문제가 존재하지 않습니다.

라인 수비수키 라우팅커널의 표준 네트워크 스택 라우팅을 넘어서는 키 기반 라우팅의 추가 계층입니다. 각 인터페이스에서는 allowed-ips피어와 연결됩니다. 이는 송신을 위해 올바른 피어로 라우팅하고, 수신을 위해 패킷을 지정된 피어와 연결한 다음 이 패킷을 수락하는 데 사용됩니다. 그러므로 올바른 의사소통을 위해서는 올바른 경로가 있어야 하며,그리고호환 가능허용된 IPWireGuard 인터페이스의 항목입니다.

작성되지 않았지만 OP도 추가된 것 같습니다.wg_term_2경로wg_client_1LAN(예:

10.242.0.0/24 via 10.241.0.1 dev wg0

또는 간단하게(계층 3 터널이므로 게이트웨이가 필요하지 않음):

10.242.0.0/24 dev wg0

언제wg_client_1ping 10.241.0.2(예:wg_term_2) 데이터 패킷은 다음과 같습니다.

  • 경로를 통해워킹 그룹 1상호 작용
  • 피어로의 암호화된 라우팅워킹 그룹 1대상이 허용된 IP 10.0.0.0/8과 일치하는 경우
  • 도착하다wg_term_1통과하다UDP 192.168.123.23:49149 -> 192.168.123.21:51821
  • ~에게 인정 받다워킹 그룹 1소스가 허용된 IP 10.0.0.0/8과 일치하기 때문에
  • 경로를 통해작업 그룹 0상호 작용
  • 피어로의 암호화된 라우팅작업 그룹 0대상이 허용된 IP 10.241.0.2/32와 일치합니다.
  • 도착하다wg_term_2통과하다UDP 192.168.123.21:51820 -> 192.168.123.22:51820
  • 떨어지다작업 그룹 0소스가 허용된 IP와 일치하지 않으므로 피어와 연결할 수 없습니다.

차례로,wg_term_2도착하다wg_client_1(여전히 올바른 경로이지만 올바른 경로는 아닙니다.허용된 IP) 여기서 특정 오류가 발생합니다.

# ip route get 10.242.0.2
10.242.0.2 via 10.241.0.1 dev wg0 src 10.241.0.2 uid 0 
    cache 
# ping 10.242.0.2
PING 10.242.0.2 (10.242.0.2) 56(84) bytes of data.
From 10.241.0.2 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Required key not available
^C
--- 10.242.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

이 작업을 수행하는 데 필요한 유일한 최소 설정은 다음을 추가하는 것입니다.wg_client_1IP 주소wg_term_2~의작업 그룹 0피어가 허용하는 IP:

# wg set wg0 peer HGF89Hcphaf+Uua214hSc/mZa/p2vmIUeT6IwrN7I3Y= \
    allowed-ips 10.241.0.1/32,10.242.0.2/32

관련 LAN을 허용할 수도 있습니다.

# wg set wg0 peer HGF89Hcphaf+Uua214hSc/mZa/p2vmIUeT6IwrN7I3Y= \
     allowed-ips 10.241.0.0/24,10.242.0.0/24

그리고 10.243.0.0/24 LAN의 설정과 암호화된 라우팅을 완료하면 다음과 같은 작업을 수행할 수 있습니다.wg_term_1(또한 이전 /32를 /24로 다시 작성):

# wg set wg0 peer +xTyPmYo9+IPBC72MFzIWFHrQyz5N6v67rjZz3q5CR4= \
     allowed-ips 10.241.0.0/24,10.243.0.0/24

이 특정한 경우에는 WireGuard 인터페이스가 있을 수 있습니다.wg_term_1두 개가 함께 사용되지만 가장 작은 것을 쓸 때는 주의해야 합니다.허용된 IP각 피어에 대한 항목: 한쪽의 10.242.0.0/24(10.0.0.0/8 대신), 다른 쪽의 10.241.0.0/24,10.243.0.0/24: 넓은 범위보다 좁은 범위에 더 좋음 범위 지정 라우팅과 대조적으로 , WireGuard의 암호화된 라우팅은 중복을 허용하지 않습니다.

관련 정보