네트워크 네임스페이스의 WireGuard: 소켓이 뒤에 남은 이유

인터페이스는 원한 네임스페이스에 나열되어 있고 애플리케이션도 그것에 묶여 있는데, 터널 트래픽은 전혀 나타나지 않습니다. 이것은 한 네임스페이스에서 만들어 다른 네임스페이스로 올간 Linux 커널 WireGuard 장치의 특징입니다. 인터페이스는 올겨졌지만 암호화된 UDP 소켓은 올겨지지 않았습니다. 내부 트래픽이 의미를 가지려면 둘 다 올바른 위치에 있어야 합니다. 하나가 아니라 두 컨텍스트를 봐야 한다는 것을 알면 확인은 빨리 끝납니다.

증상: 네임스페이스는 맞지만 패킷이 없음

네임스페이스 안에서는 터널이 정상으로 보입니다. 장치가 있고 주소가 할당되었으며 피어 구성이 있습니다. 바깥에서는 지켜보던 인터페이스에 기대한 UDP 교환이 전혀 나타나지 않고, 반대쪽은 핸드셔이크가 없었다고 보고합니다.

이유는 애플리케이션의 내부 패킷이 올간 장치에 도달하고, 장치는 다른 네트워크 컨텍스트에 속한 소켓으로 그것을 보내려 하기 때문입니다. 장치가 사용하는 언더레이 경로와 그에 적용되는 모든 방화벽 규칙은 장치를 만든 네임스페이스의 것입니다.

이것은 이동의 결함도, 피어의 잘못된 구성도 아닙니다. 커널 구현이 그렇게 동작하는 것이며, WireGuard의 네임스페이스 문서가 생성 규칙을 직접 설명합니다.

소켓에 태어난 자리가 있는 이유

WireGuard 장치는 암호화된 전송을 위해 UDP 소켓 하나를 소유하며, 그 소켓은 장치가 만들어지는 네임스페이스에서 열립니다. 링크 명령으로 인터페이스를 올기면 보이는 장치는 이동하지만 전송은 시작된 곳에 남습니다. 그러면 두 객체의 소유자가 달라집니다.

결과를 놓치기 쉬운 이유는 두 절반을 서로 다른 곳에서 점검하기 때문입니다. 내부 경로는 애플리케이션이 실행되는 네임스페이스에서 결정되고, 외부 경로는 소켓이 있는 곳에서 결정됩니다. 하나만 확인하면 자신 있지만 틀린 결로에 이릅니다. 둘 다 확인하면 보통 한 번의 조사로 끝납니다.

소켓을 원하는 곳에서 만드십시오

해결책은 장치를 바깥에서 만들어 올기는 대신 대상 네임스페이스 안에서 만드는 것입니다. 승인된 네임스페이스가 이미 있고 이름이 사용되지 않는다고 가정합니다:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

이제 인터페이스와 그 소켓이 모두 그 컨텍스트에 속하므로 언더레이 경로와 적용되는 필터 규칙은 그곳에 구성된 것입니다. 설계상 평문 쪽을 다른 곳에 두어야 한다면 먼저 기반 인터페이스를 네임스페이스에 넣고 그다음 터널을 만드십시오. 순서는 설계의 일부이며 구현 세부가 아닙니다.

이것들은 조리법이 아니라 네트워크 관리 명령으로 다루십시오. 장치를 만들고 상태를 보여줄 뿐이며, 키와 피어, 주소, 경로는 여전히 승인된 구성에서 와야 하고, 기존 운영 인터페이스를 예시에 대신 넣어서는 안 됩니다.

경로의 양쪽을 읽십시오

장치가 올바른 위치에 오면 두 판단을 따로 검증합니다. 애플리케이션 컨텍스트에서 내부 조회를 시작하고, 그다음 소켓을 소유한 컨텍스트에서 외부 경로를 확인합니다:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

내부 조회가 터널을 통해 해결되고 외부 캐처에 암호화된 교환이 보이면 두 절반이 일치합니다. 캐처가 비어 있다면 소켓이 아직 다른 곳에 있거나, 그 네임스페이스의 언더레이 경로가 끝점에 도달하지 못한 것입니다.

기록에 한 가지 확인이 더 들어가야 합니다. 재시작 후 장치가 어떻게 만들어지는지입니다. 다른 생성 컨텍스트로 인터페이스를 다시 만드는 관리자는 소켓의 태어난 자리를 바꿉니다. 한 번 성공한 수동 이동은 관리되는 경로에 대한 증거가 아닙니다.