나는 192.168.100.1/24에서 "허브"로 지정한 Wireguard [wg0]를 실행하는 OpenBSD 시스템을 성공적으로 설정했습니다. 또한 IP 주소 192.168.100.0/24를 사용하여 다양한 하드웨어 유형 및 운영 체제로 Wireguard를 성공적으로 실행하는 고객도 있습니다. 그 목적은 OpenBSD가 NAT를 통해 외부 세계와 통신할 수 있고, 클라이언트가 중앙 OpenBSD 시스템을 통해 서로 통신할 수 있다는 것입니다.
작동 방식(핑 응답):
(wg0:network) -> 192.168.100.1
192.168.100.1 -> (wg0:network)
(wg0:network) -> 8.8.8.8 (for example)
작동하지 않는 것:
(wg0:network) -> (wg0:network)
이것이 작동하지 않는 경우 OpenBSD 자체는 ICMP 리디렉션으로 응답합니다. 이런 행동은 이해하실 수 있지만 제가 원하는 것은 아닙니다. 다음 구성도 작동하지 않지만 내 생각에는 OpenBSD를 192.168.100.1로 변경하면 될 것 같습니다./32그리고 192.168.100.0/24 경로를 추가합니다. 이로 인해 응답이 전혀 생성되지 않습니다(업데이트: 전달이 발생하지 않으므로 요청이 대상에 도달하지 않는다는 것을 명확히 해야 합니다).
# /etc/hostname.wg0
inet 192.168.99.1 255.255.255.255 NONE
up
!/usr/local/bin/wg setconf wg0 /etc/wireguard/wg0.conf
!route add 192.168.99.0/24 -link -iface wg0
나는 BSD가 어떻게 패킷을 수신한 인터페이스 밖으로 패킷을 보낼 수 없는지에 대한 토론을 온라인에서 본 적이 있습니다. 일반적인 상황에서는 이것이 현명한 전략이지만, 주변의 다양한 블로그를 오해하지 않는 한 이것이 유효한 사용 사례라고 생각합니다.
참고로 이 설정은 Linux 중심 시스템용입니다. 스포크 간 통신이 가능합니다.
(업데이트) pf.conf에 추가한 내용은 다음과 같습니다.
block in
pass on wg0
pass in inet proto udp from any to (em0) port 1984
pass out on em0 to 8.8.8.8 nat-to (em0)
pass in from (em0:network) to (em0)
답변1
Justin Ludwig에게 감사드립니다. 답을 찾았습니다. 이곳은 내가 기대했던 곳이 아니다.
ping 횟수가 1인 tcpdump를 실행하면 ping 요청이 실제로 wg0 인터페이스를 떠나는 것을 두 번 볼 수 있습니다. 나는 ping을 무한정 실행했고 그것이 반복되는 것을 발견하지 못했기 때문에 이전에는 이것을 알아차리지 못했습니다.
이로 인해 제가 Wireguard에 대해 깨닫지 못했던 사실을 발견하게 되었습니다. 즉, 다른 지점에 대한 보다 구체적인 /32 경로가 있는 경우 에지 클라이언트에 허용된 IP 192.168.100.0/24를 배치하는 것이 작동하지 않는다는 것입니다.
[Interface]
PrivateKey= ....
Address= 192.168.100.200/32
# Central OpenBSD hub
[Peer]
PublicKey = ....
AllowedIPs = 192.168.100.0/24, 8.8.8.8/32
# Another Spoke
[Peer]
PublicKey = ....
AllowedIPs = 192.168.100.10/32
위의 예를 사용하여 OpenBSD 허브를 통해 192.168.100.10에서 클라이언트에 접속할 수 있다고 생각했지만 그렇지 않습니다. 아마도 Wireguard가 패킷을 해독하기 전에 패킷을 삭제하기 때문일 것 입니다 tshark -i wg0.
즉, 위의 192.168.100.10/32에 대한 피어링을 제거하면 트래픽이 내가 원하는 방식으로 흐르게 됩니다.
도움을 주신 저스틴에게 다시 한 번 감사드립니다.