Ubuntu 26.04 네트워크 구성: 고정 IP·nmtui·두 NIC 설정

Ubuntu 버전이 바뀌었다고 네트워크 설정을 처음부터 다른 방식으로 옮길 필요는 없습니다. 26.04에서도 먼저 볼 것은 그 NIC를 networkd가 관리하는지, NetworkManager가 관리하는지입니다. Server와 Desktop의 구성을 구분하면 Netplan과 nmtui가 왜 함께 언급되는지도 이해하기 쉬워요.

기준은 Ubuntu 26.04 LTS, 문서 확인일은 2026년 10월 18일입니다. 공식 LTS 변경 안내에는 Netplan 1.2와 systemd 259가 소개되어 있습니다. 업데이트 상태에 따라 설치된 패키지의 세부 버전은 다를 수 있으므로 자신의 출력도 확인합니다. Ubuntu 26.04 LTS 변경 안내를 기준으로 24.04에서 이어지는 부분과 관리 도구의 차이를 구분했습니다.

함께 보는 Linux 운영 글 · Rocky 9 고정 IP · Ubuntu 24.04 Netplan · Ubuntu 26.04·nmtui · systemd 서비스·로그 · LVM 루트 확장 · 일반 파티션 루트 확장

이 글의 목차

1. 버전과 NIC의 관리 주체부터 확인한다

cat /etc/os-release
dpkg-query -W netplan.io systemd
ip -br link
ip -4 -br address
ip -4 route
sudo netplan get
sudo netplan status -a
systemctl is-active systemd-networkd NetworkManager

현재 NIC의 관리 주체	설정 경로	주로 쓰는 도구
systemd-networkd	Netplan YAML → networkd 설정	sudoedit, netplan generate·try, networkctl
NetworkManager	NetworkManager 프로필과 Netplan 연동	nmtui, nmcli, 데스크톱 네트워크 설정
cloud-init·외부 관리 도구	해당 도구의 네트워크 원본 설정	배포 정책을 먼저 확인

Ubuntu의 NetworkManager는 Netplan과 연동할 수 있습니다. nmtui로 바꾼 값이 Netplan YAML에 반영되는 구성을 보고 서로 다른 프로그램이 충돌한다고 오해할 필요는 없어요. 저장 위치를 확인하되 /run의 생성 파일을 원본처럼 편집하지 않습니다. Netplan의 NetworkManager 연동 설명과 Ubuntu 26.04의 NetworkManager 패키지에서 연결 관계를 확인할 수 있습니다.

2. Server: 관리망과 내부망을 나눠 구성한다

NIC가 두 개면 양쪽에 게이트웨이를 넣고 싶어지지만, 내부 통신 전용 망에는 기본 경로가 필요하지 않은 경우가 많습니다. 이 예제는 ens33을 외부 통신·관리용, ens34를 별도 내부 실습망용으로 씁니다. 두 가상 NIC가 실제로 서로 다른 VMnet이나 VLAN에 연결되어 있어야 합니다.

역할	예시 주소	기본 경로·DNS
ens33: 관리망	192.168.50.26/24	게이트웨이 192.168.50.1, DNS 192.168.50.1
ens34: 내부 실습망	192.168.60.26/24	기본 경로 없음, 별도 DNS 없음

주소는 실제 망에 맞춰 바꿉니다. IP가 같은 서브넷인지, 사용 중인지, DHCP 예약과 충돌하지 않는지부터 확인하세요. Ubuntu 24.04 Netplan의 백업 절차로 기존 YAML을 보관하고 같은 NIC의 중복 정의를 정리한 뒤 적용합니다. 다른 NIC와 기존 IPv6 정책은 필요한 만큼 보존합니다.

sudoedit /etc/netplan/60-static.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      dhcp4: false
      addresses:
        - 192.168.50.26/24
      routes:
        - to: default
          via: 192.168.50.1
          metric: 100
      nameservers:
        addresses:
          - 192.168.50.1
    ens34:
      dhcp4: false
      addresses:
        - 192.168.60.26/24
      accept-ra: false
      optional: true

optional: true는 networkd가 부팅 시 ens34를 온라인 필수 조건으로 기다리지 않도록 합니다. 연결을 끄거나 장애를 자동 수리하는 옵션은 아닙니다. 이 내부망은 IPv4 실습망으로 가정해 accept-ra: false로 IPv6 라우터 광고를 받지 않게 했습니다. IPv6를 쓰는 내부망이라면 이 정책도 그 망의 주소 설계에 맞춰 변경합니다. ens33의 IPv6 동작까지 일괄 끄는 설정은 아닙니다.

sudo chmod 600 /etc/netplan/60-static.yaml
sudo netplan get
sudo netplan generate
sudo netplan try --timeout 120

VM 콘솔에서 확정 창을 유지하고 새 주소의 SSH·DNS·외부 통신을 확인한 뒤 확정합니다. try의 시간 초과가 디스크 파일까지 되돌렸다는 뜻은 아니므로 실패 시 백업과 현재 YAML을 비교해 복원합니다. 적용과 복구의 세부 조건은 Netplan try 매뉴얼을 함께 확인하세요.

3. Desktop: NetworkManager 장치에 nmtui를 사용한다

이 절은 netplan status와 nmcli device status에서 해당 NIC가 NetworkManager 관리 대상으로 확인되는 경우입니다. Server의 networkd NIC를 nmtui로 보이게 하려고 관리자 두 개를 무작정 설치·재시작하지 않습니다. 관리 주체를 바꾸는 일은 별도 전환 작업입니다.

systemctl is-active NetworkManager
nmcli device status
nmcli -f NAME,UUID,TYPE,DEVICE connection show
command -v nmtui

NetworkManager를 사용하는 설치인데 nmtui 실행 파일이 없다면 sudo apt update 후 sudo apt install network-manager로 패키지 상태를 확인합니다. 이미 networkd가 관리하는 서버에서는 이 명령을 설정 전환 절차로 사용하지 않습니다.

sudo nmtui

1. Edit a connection에서 해당 유선 연결을 선택합니다.
2. IPv4 CONFIGURATION을 Manual로 바꿉니다.
3. 주소 192.168.50.26/24, 게이트웨이 192.168.50.1, 실제 DNS 주소를 넣습니다.
4. 관리용 NIC의 기본 경로 사용과 Automatically connect를 확인합니다. 내부망 NIC라면 기본 경로를 만들지 않는 쪽으로 설정합니다.
5. 기존 IPv6 정책을 보존해 저장하고, 콘솔에서 해당 연결을 다시 활성화합니다.

명령으로 기록하려면 다음처럼 같은 프로필을 수정할 수 있습니다. nmtui와 nmcli 중 한 방법을 선택합니다. PROFILE은 장치명이 아니라 앞서 확인한 연결 이름 또는 UUID입니다. 아래는 단일 관리 NIC의 예제이며 기존 정적 라우트는 별도로 확인합니다.

NIC='ens33'
PROFILE='Wired connection 1'
BACKUP_PROFILE='before-static-ubuntu26'

sudo nmcli connection clone "$PROFILE" "$BACKUP_PROFILE"
sudo nmcli connection modify "$BACKUP_PROFILE" connection.autoconnect no
sudo nmcli connection modify "$PROFILE" \
  ipv4.method manual \
  ipv4.addresses '192.168.50.26/24' \
  ipv4.gateway '192.168.50.1' \
  ipv4.dns '192.168.50.1' \
  ipv4.ignore-auto-dns yes \
  ipv4.never-default no \
  connection.autoconnect yes
sudo nmcli connection up "$PROFILE" ifname "$NIC"

주소 변경이므로 SSH가 끊길 수 있습니다. 콘솔에서 진행하거나, 변경 전 Rocky 9 고정 IP에 나온 체크포인트 경로를 검토합니다. 복구할 때는 콘솔에서 백업 프로필을 다시 활성화하고, 잘못된 프로필이 재부팅 때 선택되지 않도록 자동 연결도 정리합니다.

4. 두 NIC에서는 목적지별 경로를 확인한다

ip -4 route show default
ip route get 1.1.1.1
ip route get 192.168.60.10
resolvectl status
resolvectl query example.com
networkctl status ens33

위 Server 예제라면 외부 목적지는 ens33의 게이트웨이로, 같은 내부 서브넷 목적지는 ens34로 선택되어야 합니다. 192.168.60.10이 실제로 존재한다는 뜻은 아니고 경로 선택을 살펴보는 예시입니다. 여러 기본 경로가 꼭 필요한 설계라면 metric이나 정책 라우팅까지 계획해야 합니다.

Desktop의 NetworkManager NIC는 networkctl 대신 nmcli -f GENERAL,IP4 device show ens33으로 상태를 살펴봅니다. DNS 질의가 실패하면 장치의 DNS와 경로부터 확인하고, IP 변경 직후 SSH가 안 되면 주소 중복·방화벽·실제 가상 NIC 연결도 나눠 점검합니다.

부팅이 네트워크를 기다리며 늦어질 때

systemd-analyze blame
sudo journalctl -b -u systemd-networkd-wait-online.service --no-pager
sudo journalctl -b -u NetworkManager-wait-online.service --no-pager

모든 wait-online 서비스를 끄기 전에 어떤 NIC를 필수로 기다리는지 확인합니다. 관리망은 준비되어야 하는데 실습용 케이블이 빠진 ens34만 기다리는 상황이라면 optional 정책을 검토할 이유가 있습니다. 서비스 자체의 생성·변경과 로그 조회는 systemd 서비스·로그에서 이어집니다.

확인 범위 · 2026-10-18: Ubuntu 26.04.1 컨테이너의 Netplan 1.2에서 고정 IP·두 NIC·DHCP 예제의 설정 생성, NetworkManager 1.54.3에서 프로필의 오프라인 생성·변경을 확인했습니다. 주소 활성화·복구 원리는 Ubuntu 24.04 VM의 보조 NIC에서 확인했으며, Ubuntu 26.04를 실제 부팅해 NIC를 전환한 검증은 수행하지 않았습니다.

네트워크·systemd 예제 파일 내려받기 · Netplan YAML, 서비스·환경 파일과 스토리지 구조를 읽는 스크립트를 묶었습니다. 주소와 장치 이름은 실제 환경에 맞춰 바꿉니다. 디스크를 자동 확장하는 스크립트는 포함하지 않습니다.