VM 네트워크 네 가지 모드

한 줄 요약

VM 네트워킹의 선택은 누가 패킷을 처리하는가로 갈린다. 유저 공간(SLIRP), 커널(TAP), 커널 브리지, 그리고 커널 안의 virtio 처리(vhost-net).

왜 이게 필요했나

"VM 에서 인터넷은 되는데 밖에서 VM 으로 못 들어갑니다." 이 신고의 원인은 거의 항상 user(SLIRP) 모드다. 개발 환경에서 기본값으로 쓰이는데, 그 특성을 모르면 프로덕션에 그대로 나간다.

어떻게 동작하나

user (SLIRP)

QEMU 가 유저 공간에 TCP/IP 스택을 통째로 구현한다. 게스트가 보낸 패킷을 QEMU 가 해석해 호스트의 평범한 소켓으로 다시 만들어 보낸다.

• 특권이 전혀 필요 없다. 이 실습 환경에서 유일하게 쓸 수 있는 이유다.
• 게스트는 10.0.2.0/24 대역에 놓이고 게이트웨이는 10.0.2.2, DNS 는 10.0.2.3 이다.
• 밖에서 게스트로 들어올 수 없다. hostfwd 로 개별 포트를 뚫어야 한다.
• ICMP 가 제한적이다. 게스트에서 ping 이 안 되는 경우가 많은데 정상이다.
• 성능이 낮다. 모든 패킷이 유저 공간을 한 번 더 거친다.

tap

커널의 가상 이더넷 장치를 만들고 QEMU 가 그 한쪽 끝을 잡는다. 패킷이 커널 네트워크 스택에 그대로 올라오므로 호스트에서 보면 진짜 인터페이스처럼 보인다. 대신 TAP 장치를 만들려면 특권(또는 미리 만들어 둔 장치에 대한 권한)이 필요하다.

bridge

TAP 을 리눅스 브리지에 꽂는다. 브리지에 물리 NIC 도 함께 꽂혀 있으면 VM 이 물리망에 직접 붙은 것처럼 동작한다. VM 이 DHCP 로 사내망 주소를 받고, 다른 서버에서 그 주소로 바로 접속된다. 프로덕션의 기본 구성이다.

ip link add br0 type bridgeip link set eth0 master br0ip link set br0 upqemu-system-x86_64 -netdev tap,id=n0,ifname=tap0,script=no -device virtio-net-pci,netdev=n0

vhost-net

virtio 링 버퍼 처리를 커널 안에서 한다. QEMU 유저 공간을 왕복하지 않으므로 지연과 CPU 사용이 크게 준다. -netdev tap,...,vhost=on.

| 모드 | 특권 | 밖→안 접속 | 성능 | 용도 |
| --- | --- | --- | --- | --- |
| user | 불필요 | hostfwd 로만 | 낮음 | 개발/테스트 |
| tap | 필요 | 가능 | 중 | 격리된 VM 망 |
| bridge | 필요 | 가능(물리망 직결) | 중~높음 | 프로덕션 |
| vhost-net | 필요 | 가능 | 높음 | 고성능 워크로드 |

현장에서 만나는 모습

개발 환경에서 잘 되던 것이 스테이징에서 안 되는 경우. 개발은 user 모드라 hostfwd 로 22 번만 뚫어 뒀고, 스테이징은 bridge 라 전부 열려 있다. 반대로 hostfwd 로만 접근하다가 브리지로 옮기면 방화벽을 새로 설계해야 한다 — 지금까지는 QEMU 가 사실상 방화벽 역할을 하고 있었기 때문이다.

MTU 문제. 브리지 위에 VXLAN 같은 오버레이가 겹치면 실효 MTU 가 줄어든다. VM 안에서는 여전히 1500 이라 큰 패킷이 조용히 사라진다. 게스트 MTU 를 낮추거나 MSS 클램핑이 필요하다.

다음에서 할 것

이 모듈은 개념만 다룬다. 앞의 vm-boot 실습에서 -netdev user,hostfwd=... 를 쓴 이유를 이제 설명할 수 있어야 한다 — 특권이 없는 환경에서 유일하게 가능한 선택이었기 때문이다.