Proxmox의 LXC 또는 VM에서 WireGuard: 어디에서 실행해야 할까?

WireGuard는 자신의 인터페이스를 소유할 커널을 정확히 하나 필요로 하며, 이 사실만으로 Proxmox 배치 논쟁의 대부분은 성능이 화제에 오르기도 전에 정리됩니다. LXC 컨테이너는 호스트 커널의 네임스페이스 뷰이고, VM은 자체 커널을 부팅합니다. 따라서 유용한 질문은 어느 쪽이 더 가벼운가가 아니라, 어떤 커널을 기꺼이 수정할 것인가 그리고 어떤 복구 경로와 함께 살 수 있는가입니다. 그 답을 내리면 호스트, 컨테이너, VM 중 무엇을 고를지는 대개 저절로 정해집니다.

LXC 게스트는 호스트 커널 안에서 동작한다

컨테이너 안에 wireguard-tools를 설치하면 제어 프로그램을 얻을 뿐 전용 커널은 아닙니다. 생성한 wg0 인터페이스는 호스트의 네트워크 스택에 등록되고 호스트의 모듈 목록에 나타납니다. 그래서 컨테이너는 모든 패키지 검사를 통과하고도 호스트 커널에 모듈이 없으면 첫 wg 명령에서 실패할 수 있습니다. 그리고 Proxmox 컨테이너 레퍼런스 는 그 공유 커널 모델과 함께 여러분이 작업하는 네임스페이스 및 권한 경계를 문서화합니다.

권한은 두 번째 제약입니다. 인터페이스를 올리고 주소를 붙이려면 그것을 소유한 네임스페이스 내부의 네트워크 관리 권한 이 필요하며, 비특권 컨테이너는 그 권한을 직접 보유하지 않고 사용자 네임스페이스를 통해 매핑합니다. 첫 번째 답으로 절대 전체 권한을 선택하지 마세요. 컨테이너에 실제로 무엇을 요구하는지 보고, 그것만 부여하세요.

호스트 커널도 공유 의존성입니다. Proxmox 커널 업데이트는 모든 컨테이너 아래의 WireGuard 구현을 한 번에 바꾸며, 이는 업데이트와 컨테이너의 기대가 어긋나기 전까지는 편리합니다.

호스트, 컨테이너, VM: 각 배치가 실제로 소유하는 것

호스트 배치는 VPN을 하이퍼바이저 자체의 네트워크에 둔다. 경로, 방화벽 규칙, 터널이 호스트 복구의 일부가 되며, 그곳의 실수는 관리 인터페이스까지 가져갈 수 있습니다. 콘솔로 접근할 수 있는 호스트의 인프라 라우팅에는 받아들일 만하지만, 대역 외 접근이 없는 원격 장비에서는 고통스럽습니다.

컨테이너는 서비스를 패키지화하고 재시작 가능하게 유지하면서도 호스트 커널을 빌려 씁니다. 의도적으로 공유 커널을 쓰는 서비스에 어울리고 재구축할 작은 단위를 줍니다. 독립 커널을 주지는 않으므로 특정 모듈 빌드가 필요한 것은 이 선택지에서 멀어집니다.

VM은 더 많은 메모리와 패치할 시스템 하나를 더 쓰는 대신, 터널이 자기 커널과 자기 라우팅 테이블, 스냅샷 경계를 얻습니다. 나쁜 변경 뒤에 VPN을 되돌려야 한다면 그 스냅샷은 추가 비용을 감당할 만합니다.

여러분 대신 선택해 주는 세 가지 조건

터널이 Proxmox 호스트가 제공하지 않는 커널 버전이나 WireGuard 기능을 필요로 한다면 여기서 멈추고 VM을 쓰세요. 컨테이너에 더 새로운 커널을 설치할 수 없고, 게스트 하나를 만족시키기 위해 하이퍼바이저 커널을 바꿔서는 안 됩니다.

터널이 실제 LAN 프리픽스를 위한 사이트 게이트웨이라면, 반환 경로를 이미 누가 소유하는지 물으세요. 컨테이너도 트래픽을 라우팅할 수 있지만 그 인터페이스는 호스트 스택에 있으므로, 계획했든 아니든 호스트가 구성의 일부를 떠안게 됩니다. 호스트 배치는 이 점에서 정직하고, 컨테이너 배치는 흔히 그렇지 않습니다.

다음으로 실수의 영향 반경을 따져 보세요. 컨테이너 재시작은 저렴하고, VM 스냅샷 복원은 예측 가능하며, 호스트 네트워크 복구는 물리적 또는 콘솔 접근을 요구할 수 있습니다. 옳은 선택은 최악의 경우를 사건이 일어난 그 시간에 실제로 복구할 수 있는 쪽입니다.

네 번째 질문은 좀처럼 결정적이지 않지만 말할 가치가 있습니다. 호스트의 다른 무엇인가가 터널 인터페이스를 봐야 하는가? 그렇다면 호스트나 컨테이너 배치가 그 가시성을 국소적으로 유지하고, VM은 게스트와 호스트 사이를 라우팅하도록 강제합니다.

트래픽을 통과시키기 전에 배치를 증명하라

설치 후에는 어느 커널이 실제로 인터페이스를 제공하는지, 그리고 컨테이너에 그것을 유지할 만큼의 권한이 주어졌는지 확인하세요:

$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
  listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0

그다음 호스트에서 포워딩 쪽을 확인하세요. 핸드셰이크만으로는 터널이 올라와 있다는 것만 증명되기 때문입니다. 클라이언트 주소에는 ip route get를 사용하고 다음 홉과 인터페이스가 설계와 일치하는지, 반대편에 반환 경로가 있는지 확인하세요.

배포는 문서화된 소유자와 함께 남기세요. 어느 커널이 구현을 담당하고, 어느 네임스페이스가 인터페이스를 보유하며, 게이트웨이가 어떤 프리픽스를 포워딩할 수 있는지. 그 한 문장이 세 배치에 대한 어떤 벤치마크 비교보다 많은 사고를 막습니다.