저는 VirtualBox를 정말 좋아합니다. 다양한 테스트와 실험 작업에 늘 활용해 왔고, 대체로 만족스러운 도구입니다. 그런데 이렇게 훌륭한 프로그램도 이따금 말썽을 부리며 제 발목을 잡을 때가 있습니다. 대표적인 사례가 바로 브리지 네트워킹(Bridged Networking)입니다.
지난 몇 년간 저는 VirtualBox의 네트워크 기능과 관련해 여러 가이드를 작성해 왔습니다. 네트워크 및 공유 튜토리얼, NAT 환경에서 포트 포워딩으로 공유하는 방법, NAT 네트워크 구성법 등이 그 예입니다. 저 역시 유선·무선 어댑터 모두에서 안정적으로 잘 동작하고 설정이 간편한 브리지 네트워크 기능을 즐겨 사용해 왔습니다. 오랜 세월 아무 문제 없이 잘 쓰던 기능인데, 어느 날 갑자기 고장 나 버렸습니다. Linux 호스트에서 VirtualBox 6.x를 실행할 때 브리지 네트워킹이 더 이상 동작하지 않게 된 것입니다. 네트워크가 '안 되는' 네트워크가 되어 버린 셈이죠.
문제 상황 자세히 살펴보기
저는 Kubuntu 18.04에 VirtualBox 6.1을 설치해 사용 중인 Slimbook 노트북에서 이 문제를 만났습니다. 이 노트북에는 인텔 듀얼밴드 무선 어댑터가 장착되어 있고, 한동안은 브리지 네트워킹을 아무런 이상 없이 사용할 수 있었습니다. 그러나 몇 주 전부터 게스트 운영체제(Windows든 Linux든)가 이 네트워크 구성에서 더 이상 IP 주소를 받지 못하기 시작했습니다.
라우터 문제를 배제하기 위해 Windows 호스트에서 VirtualBox를 돌려 테스트했지만, 거기서는 아무런 문제가 발생하지 않았습니다. 반대로 리눅스 자체의 문제를 배제하기 위해 여러 다른 배포판에서도 시험해 보았지만, 커널 버전이나 시스템 아키텍처가 달라도 결과는 똑같았습니다. 결국 이 문제는 Linux용 VirtualBox 빌드에 국한된 것으로 보이며, 그렇다고 리눅스 자체의 탓은 아니었습니다. 공식 포럼을 뒤져보면 이 주제에 관한 스레드가 수없이 많은데, 대부분 해결책을 찾거나 '브리지 네트워킹은 원래 신뢰성이 떨어지니 작동하는 것만으로도 다행으로 여겨야 한다'는 식의 막연한 답변으로 끝납니다. 하지만 저는 그렇게 받아들이지 않았습니다.
어쩌면 제가 네트워크 스택의 새로운 회귀(regression) 버그를 우연히 마주친 것일 수도 있고, 여러분은 이 문제를 영원히 겪지 않을 수도 있습니다. 그러나 만약 같은 상황에 처한다면, 제가 찾아낸 준수한 수준의 우회 방법이 도움이 될 수 있습니다. 어떤 버전의 VirtualBox에서든, 어떤 형태의 브리지 네트워킹 문제든 공식적으로 해결될 때까지 임시방편으로 활용할 수 있는 방법입니다.
해결 방법
상황을 정리하면 이렇습니다. 브리지 네트워킹은 설정되어 있는데 클라이언트(게스트 OS)가 IP 주소를 받지 못합니다. 고정 IP를 직접 지정해 봐도 소용이 없었습니다. 제 경우 원인은 가상 네트워크 어댑터에 무작위로 생성된 MAC 주소와 브리지 대상이 되는 물리적 카드의 MAC 주소 사이의 충돌로 추정됩니다. 과거에는 이 충돌이 기능에 영향을 주지 않았기 때문에 명백한 버그처럼 보이지만, 어쨌든 현실로 닥친 문제입니다. 우회 방법은 간단합니다. 가상 어댑터의 MAC 주소를 호스트 물리 카드의 MAC 주소와 일치하도록 수동으로 지정하는 것입니다.
설정 방법은 다음과 같습니다. 해당 가상 머신의 설정(Settings) → 네트워크(Network) → 고급(Advanced) 메뉴로 이동합니다. 여기서 MAC 주소(MAC Address) 필드에 호스트 어댑터의 MAC 주소를 입력하면 됩니다. 그런 다음 가상 머신을 시작하면 다시 네트워크 작업을 문제없이 진행할 수 있습니다.
주의사항
물론 이것은 근본적인 해결책이 아니라 임시 우회 방법이라는 점을 분명히 해 두겠습니다. 이 변경을 적용하면 가상 머신이 호스트와 동일한 IP 주소를 갖게 됩니다. 네트워크상에 같은 주소를 공유하는 두 개의 동일한 호스트가 존재하는 셈이므로, 일부 응용 프로그램은 제대로 작동하지 않을 수 있습니다. 따라서 가상 머신이 부팅된 후에는 별도의 고유 IP 주소를 수동으로 할당해 주는 것이 좋습니다.
마치며
완벽하지 못한 튜토리얼을 작성하는 일은 언제나 즐겁지 않습니다. 하지만 때로는 끝없이 완벽을 추구하며 미루기보다, 필요한 주의사항과 함께라도 독자에게 실질적인 도움을 주는 편이 낫다고 생각합니다. 오늘 소개한 내용이 바로 그런 사례입니다. 소프트웨어 자체의 문제라는 것이 분명하므로, 가장 합리적인 해결책은 공식 수정 패치를 기다리는 것입니다. 과거에도 그랬고, 앞으로도 그럴 수 있습니다.
그럼에도 불구하고 위 정보가 누군가에게는 도움이 되기를 바랍니다. 완벽한 해결책은 아니지만, 곤경에서 벗어나는 데는 충분히 유용할 것입니다. 특히 이런 문제는 가장 곤란한 순간, 즉 가상 머신을 켜고 모든 것이 정상적으로 작동할 것이라 기대하는 바로 그때 나타나 네트워크 관련 작업 전체를 마비시키곤 합니다. 이 주제에 대해 아이디어, 제안 또는 경험이 있으시다면 언제든지 메일로 알려주세요. 이상으로 글을 마무리하겠습니다.
감사합니다.