서론

우분투가 netplan을 사용한지는 꽤 된걸로 알고있다. 17.04 부터 였던가? 아마 그쯤이었던걸로 기억한다. 그냥 알던데로 ifup, ifdown 명령어를 쓰거나 /etc/network에 들어가서 네트워크 설정을 분명 수정했는데 제대로 반영이 안되서 멘붕왔던게 지금도 기억난다. ㅋㅋㅋㅋ

뭐 그건 그때고, netplan을 한번 알고나니깐 이렇게 직관적이고 간편한것도 없다는게 지금생각이다. 덕분에 CentOS쪽을 사용도 못해보겠다는게 함정이라면 함정이지만 말이다.

그런 느낌으로 지내오다가 요즘 VM 가지고 놀다가 자체 NAT으로 돌리자니 불편한점이 너무 많고 어차피 iptime 공유기 안쪽에서 노는건데 ip관리는 전부 공유기한테 시키고 Host는 가상머신만 구동시키라는 느낌으로 브릿지 구성하면서 뻘짓들 기록으로좀 남겨본다.

Netplan 이란?

레드헷진영은 아직인거 같지면 우분투진영은 Netplan으로 옮겨왔다. 로우레벨 영역에서 돌아가는건 똑같지만 Netplanyaml형식으로 네트워크 구성을 명시해두면 알아서 설정파일을 만들어서 NetworkManager(좀더 하드웨어쪽) 이랑 Systemd-Networkd(좀더 소프트웨어쪽)의 설정을 한꺼번에 처리해주는 놈이다.

이거 하나로 브릿지 구성, 트래픽조절, 와이파이 연결, ip 설정 변경등 다양한 작업을 할 수 있어 사람을 예전에 여기저기 폴더 돌아다니면서 네트워크 설정하던 시절로 돌아가지 못하게 만드는 흉악한 녀석이다.

목표

다음과 같은 상황을 가정한다.

Host의 실제 물리적으로 존재하는 NIC는 eth0 하나만 존재한다.

VM의 NIC는 vm0, vm1, vm2 이런느낌으로 아주 많이 존재한다.

목표는 브릿지를 하나 만들어서 Host머신과 모든 VM에게 Public IP를 부여하는 것이다.

본론

간단하다. 일반적인 netplan이 설치된 환경이면
/etc/netplan 폴더 속에 eth0 interface가 정의된 설정파일이 있을것이다.
그 파일을 열어보면

network:
    ethernets:
        eth0:
            dhcp4: true
    version: 2

위와같이 정의가 되있을테고 그 뒤에 Bridge에 대한 정의를 해주면 된다.

network:
    ethernets:
        eth0:
            dhcp4: true
    bridges:
        br0:
            dhcp4: true
            interfaces: [ "eth0" ]
    version: 2

상식적으로 eth0 부분에 dhcp4 옵션은 꺼줘야 되지 않나? 생각하지만 호스트가 br0로 정의된 브릿지를 통해 네트워크를 실행하기 때문에 저 옵션은 무시되는거 같다.

이제 netplan apply 해주면 설정이 적용된다.

이렇게 할 경우 Host 는 br0라는 NIC를 통해 인터넷에 접속되며 (MAC주소도 바뀌니깐 dhcp 설정 주의하자) 나머지 가상머신들은 네트워크 설정할때 br0 랑 접속만 시켜두면 외부랑 통신이 가능하다.

VLAN을 특별히 설정해두지 않으면 가상머신간에 소통을 할때 쓸때없이 트래픽이 eth0를 통해 Host외부까지 갔다가 다시 돌아오지 않을까? 라는 염려를 조금 하긴 했으나, 실제 실험결과 내부간 소통은 트래픽이 내부에서만 처리되는걸로 확인했다. 이부분은 조금 공부가 필요.

단점

이게 실제 물리 디바이스를가지고 하면 잘된다. 안드로이드 스마트폰부터 라즈베리파이, x86서버 등등은 정말 잘된다.

근데 가상 브릿지가 물려있는 가상머신 속에서 또 브릿지를 하나 만들면 안된다. 일단 dhcp가 안되서 ip주소 할당이 안되고, 수동으로 ip할당해도 외부랑 통신은 커녕 Host와 VM 간의 통신도 안된다. KVM과 Hyper-V 두 환경 모두에서 확인한 결과고 KVM의 경우 NIC로 Virtio를 사용했다.

아마 가상 브릿지 두개이상 물리면 뭔가 문제가 생기는 모양이지만 필자의 경우 이 상황이 꼭 필요한건 아니므로 패스.

단점2

설정중에 당연하지만 네트워크가 끊긴다. SSH로 작업하는건 추천하지 않는다. 위와같이 가상머신 속 브릿지 구축처럼 알수없는 이유로 네트워크가 단절될수 있고, 이 상태에서 당황에서 리부팅하면 systemd-networkd-wait-online가 네트워크 연결 안됬다고 부팅을 막아버린다......;;;

근데 또 가끔 설정 완료하고 바로는 네트워크가 안되는데 재부팅하면 되는경우가 있어서 재부팅을 안해볼수도 없다는게 함정이다.

systemctl disable systemd-networkd-wait-online
systemctl mask systemd-networkd-wait-online

이 두가지는 꼭 실행하고 설정에 임하도록 하자.
전자는 부팅시 자동로딩되지 않게, 후자는 dependency 관계인 놈들이 이 서비스를 호출하지 않도록 막는 명령어다.

후기

네트워크는 짜증난다.

될꺼라 생각했는데 안될경우도 많고, 안될꺼 알지만 반쯤 자포자기로 해봤는데 갑자기 되는경우도 있다.

문제는 이렇게 어떻게든 한번만 성공하면, 영원히 방치다. 문제일어나기 전까지는 절대 안만지고, 문제가 일어나지도 않는다.
(지금도 어떻게 Bridge에다 NAT 환경을 하나 붙여두긴 했는데 이건 진짜 어떻게 했는지도 모르겠다.)

그러니 성공해도 왜 성공했는지 모르며, 경험이 쌓이지 않는것 같다는게 개인적인 감상이다.

그래서 작지만 성공한 케이스에 대해 이렇게 기록을 남겨보고자 한다.