☰

네임스페이스와 Wireguard를 공유하는 방법은 무엇입니까?

tag-icon • tag-icon routing iproute network-namespaces void-linux wireguard
네임스페이스와 Wireguard를 공유하는 방법은 무엇입니까?

wg0$DAYJOB 관리 네트워크 내의 신뢰할 수 있는 시스템에 대한 와이어가드 연결(인터페이스 이름)이 있습니다. 일반적으로 wg0을 사용하고 싶지 않습니다.모두내 트래픽은 172.16.0.0/12 범위의 IP 주소에만 적용됩니다. 이는 다음과 같은 스탠자를 사용하여 쉽게 수행할 수 있습니다 /etc/wireguard/wg0.conf.

[Peer]
# ...
AllowedIPs  = 172.16.0.0/12

그러나 Firefox 프로필의 경우 트래픽이 172.16.0.0/12로 이동하지 않더라도 모든 것이 wg0을 통해 라우팅되기를 원합니다. 또한 DNS의 경우 일반적으로 dnscrypt-proxy + dnsmasq를 사용하지만 wg0 트래픽의 경우 $DAYJOB의 네임서버를 사용하고 싶습니다.

저 할 수 있어요거의ip netnsveth 쌍을 사용하여 네트워크 네임스페이스를 생성하여 이러한 제약 조건을 일치시킵니다. 네임스페이스 내에서 기본 resolv.conf를 대체 이름 서버가 포함된 resolv.conf로 바꾸면 됩니다. 유일한 문제는 wg0을 다음과 같이 사용하는 방법을 아직 찾지 못했다는 것입니다.오직패킷이 네임스페이스를 벗어나는 방법.

  • 기본이 아닌 DNS 사용:✓
  • 네임스페이스에서 172.16.0.0/12로의 트래픽은 wg0을 통해 올바르게 라우팅됩니다. ✓
  • 네임스페이스에서 나가는 다른 모든 트래픽도 wg0을 통과합니다. ✗

라인배커들은netns 관련 문서하지만 여전히 네임스페이스 외부의 wireguard 인터페이스가 필요하지 않다고 가정하는 것 같습니다. 나는 네임스페이스 외부의 모든 것이 여전히 Wireguard 인터페이스에 액세스할 수 있기를 원합니다.

일부 소스:1, 유사한 작업에는 VLAN을 사용하는 것이 좋습니다. 그러나 wireguard 인터페이스는 VLAN을 지원하지 않는 것 같습니다. 일어나는 일은 다음과 같습니다.

$ sudo ip link add link wg0 name wg0.4 type vlan id 4
$ sudo ip netns add ns-wg-test-1
$ sudo ip link set wg0.4 netns ns-wg-test-1
$ sudo ip netns exec ns-wg-test-1 su -c "/bin/bash -l" $USER
$ sudo ip addr add 192.168.126.2 dev wg0.4
$ sudo ip link set dev wg0.4 up
RTNETLINK answers: Cannot assign requested address

이제 저는 문제가 있는 다양한 대안 사이에서 갈등을 겪고 있습니다.

가능성 1: 두 번째 Wireguard 인터페이스를 추가합니다. 이 작업은 에서 수행되어야 합니다 /etc/wireguard/wg1.conf. 이것이 가능한지 또는 좋은 생각인지는 확실하지 않습니다.여러 개의 와이어 가드 인터페이스와 중복 구성을 갖는 것은 우아하지 않은 것 같습니다.

가능성 2:ip route및 규칙의 일부 조합을 추가하여 iptables -A네임스페이스에서 나가는 모든 항목을 강제로 wg0으로 지정합니다. 하지만,한 인터페이스에서 들어오는 모든 트래픽을 다른 인터페이스를 통해 강제로 라우팅하는 방법을 명확하게 설명하는 예제나 문서를 본 적이 없습니다.다시 말하지만, 나는 이것이 좋은 접근 방식인지에 대해 어느 정도 회의적입니다.

가능성 3:Wireguard 문서를 신뢰하십시오. wg0을 네임스페이스 안에 넣고 네임스페이스 외부의 모든 172.16.0.0/12 트래픽이 네임스페이스에 연결된 veth 쌍을 통과하도록 지시합니다. 네임스페이스 내에는 veth 쌍의 모든 항목을 wg0으로 전달하는 라우팅/방화벽 규칙이 있을 수 있습니다.이 솔루션의 문제점은 작동하더라도 네임스페이스가 항상 활성화되어 있어야 한다는 것입니다. 오늘 아침에 네임스페이스를 활성화했는지 여부에 관계없이 172.16.0.0/12에 대한 트래픽이 항상 wg0으로 가는 길을 찾도록 하고 싶습니다.

따라서 질문은: 네임스페이스 외부의 WireGuard에 대한 액세스를 계속 유지하면서 WireGuard 인터페이스를 네트워크 네임스페이스와 공유하는 가장 좋고 가장 표준적인 방법은 무엇입니까?

이것은 의견에 근거한 것이 아닙니다. 강력하고 효율적이며 안전하고 스크립트 가능한 실제 예제를 보면 그 대답이 옳다는 것을 알 수 있습니다. 크로스 플랫폼일 필요는 없습니다. 저는 Void Linux(때때로 Arch Linux)에서만 이 작업을 수행합니다.

또는 전체 벤처가 나쁜 생각이거나 어떤 이유로 구현이 불가능한 경우 부정적인 대답에는 이유를 설명하는 주장, 증거 및 인용이 포함될 수 있습니다. 더 나은 결과가 나오지 않으면 여전히 올바른 것으로 표시하겠습니다.

답변1

따라서 질문은: 네임스페이스 외부의 WireGuard에 대한 액세스를 계속 유지하면서 WireGuard 인터페이스를 네트워크 네임스페이스와 공유하는 가장 좋고 가장 표준적인 방법은 무엇입니까?

IMO, 좋은 접근 방식은 다음을 사용하는 것입니다.정책 기반 라우팅이를 위해. 예를 들어, "인터페이스 A에서 오는 모든 패킷은 경로 테이블 B를 사용해야 합니다. 여기서 인터페이스 A는 netns 외부의 veth/bridge 인터페이스이고 경로 테이블 B에는 wireguard 인터페이스를 통한 경로만 포함됩니다(물론 원래 네트워크로 돌아가는 라우팅). ) 네임스페이스). iproute2다음과 같이 를 사용하십시오 .

# echo "100 dayjob" >> /etc/iproute2/rt_tables
# ip route add <wireguard glue net> dev wg0 table dayjob
# ip route add default via <wireguard gw> dev wg0 table dayjob
# ip route add <netns net> dev <veth/bridge interface> table dayjob
# ip rule add iif <veth/bridge interface> lookup table dayjob

답변2

귀하의 질문에는 서버를 통해 Firefox 트래픽을 라우팅해야 합니다. 더 쉬운 방법은 SOCKS 프록시를 사용하도록 구성 파일을 구성하는 것입니다.

ssh를 사용하여 서버에 연결하기만 하면 됩니다 ssh -D 1080 SERVERNAME.

 -D [bind_address:]port
         [...] Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will
         act as a SOCKS server.

network.proxy.socks_remote_dnsFirefox에서도 구성할 수 있습니다.

관련 정보