리눅스 (3) - 네트워크 설정

게시 2026/07/27

By eta_kyung

9 분읽는 시간

리눅스 (3) - 네트워크 설정

이 글은 mac os UTM 가상머신을 이용하는 환경이다.

Netplan 고정 IP 설정 오류 해결기 (.yml 확장자 문제와 MAC 주소 충돌)

우분투(Ubuntu) 환경에서 netplan을 이용해 고정 IP를 설정하던 중, 분명 설정을 완료했음에도 계속 DHCP로 원치 않는 IP를 받아오는 문제가 발생했다.

단순한 오타나 설정 오류인 줄 알았으나, 원인을 추적해 보니 확장자 인식 이슈와 가상머신(VM) 클론 과정에서 생긴 MAC 주소 불일치, 그리고 Netplan의 설정 파일 병합(Merge) 동작 방식이 복합적으로 작용하고 있었다.

나중에 문제가 발생했을 때 참고하고, 네트워킹 트러블슈팅 절차를 기억하기 위해 해당 내용을 정리한다.

1. 문제 증상

목표: /etc/netplan/netcfg.yml 파일에 고정 IP(192.168.64.16/24, Gateway: 192.168.64.1)를 할당.
증상: sudo netplan apply를 실행했음에도 고정 IP가 적용되지 않고, enp0s1 인터페이스가 계속 DHCP를 통해 다른 IP(192.168.64.20 등)를 할당받음.

2. 원인 분석

원인을 파악해 보니 아래 두 가지 문제가 복합적으로 작용하고 있었다.

① `.yml` 확장자 무시 문제 (진짜 원인)

Netplan의 백엔드 라이브러리(libnetplan)는 /etc/netplan/ 디렉터리 내에서 *.yaml 확장자만 스캔하도록 작성되어 있다. 새로 작성했던 설정 파일명이 netcfg.yml(.yml)이었기 때문에, Netplan은 이 파일을 아예 읽지 않고 무시하고 있었다.

② 인터페이스 매칭 충돌 (MAC 주소 불일치)

확장자를 수정하는 것만으로는 해결되지 않았다. 기존 OS 설치 시 자동 생성되었던 /etc/netplan/00-installer-config.yaml 파일에 아래와 같은 설정이 남아 있었다.

  
match:
  macaddress: 96:6c:29:36:e4:c2
set-name: enp0s1

VM 환경을 클론하거나 재설정하면서 실제 NIC의 MAC 주소(6e:d5:07:63:13:bb)가 변경되었으나, 기존 설정 파일에는 옛날 MAC 주소가 고정되어 있었다.

Netplan이 같은 ID (enp0s1)를 가진 두 설정을 병합하는 과정에서 이 match 조건이 살아남아 “Cannot find unique matching interface for enp0s1” 에러를 뱉으며 고정 IP 적용 자체가 실패했던 것이다.

③ Netplan의 파일 병합(Merge) 동작과 우선순위

Netplan은 파일 단위로 이전 설정을 완전히 “덮어쓰는(Overwrite)” 것이 아니라, 같은 인터페이스 이름(ID)에 대해 여러 파일의 설정을 키(Key) 단위로 “병합(Merge)” 한다.

이때 알파벳 순서상 나중에 오는 파일이 우선권을 가져간다.

00-installer-config.yaml (기존): dhcp4: true, dhcp6: true
netcfg.yaml (신규): dhcp4: no, addresses: [...], gateway4: ...

netcfg.yaml의 n이 00-installer-config.yaml의 0보다 사전순으로 뒤에 오므로, dhcp4: no 키는 기존의 dhcp4: true를 성공적으로 덮어썼다.

최종 병합 결과:

  
enp0s1:
  dhcp4: no                      # netcfg.yaml 승리 (덮어씀)
  dhcp6: true                     # 덮어쓰지 않아 installer 설정 그대로 유지!
  addresses: [192.168.64.16/24]   # netcfg.yaml 추가
  gateway4: 192.168.64.1           # netcfg.yaml 추가

실제로 ip addr show enp0s1 결과를 확인해 보면 이 특성이 그대로 나타난다.

inet 192.168.64.16/24 ... scope global enp0s1              # IPv4: dynamic 제거됨 (고정)
inet6 fdca:... scope global dynamic mngtmpaddr noprefixroute # IPv6: 여전히 dynamic 유지!

IPv4는 고정으로 바뀐 반면 IPv6는 여전히 dynamic 상태인 이유가 바로 이 키 단위 병합 메커니즘 때문이다.

3. 해결 과정

Step 1. 파일 확장자 변경

확장자를 Netplan이 인식할 수 있는 .yaml로 변경했다.

sudo mv /etc/netplan/netcfg.yml /etc/netplan/netcfg.yaml

Step 2. 기존 설정 파일 정리

/etc/netplan/00-installer-config.yaml에서 더 이상 유효하지 않은 match 및 set-name 블록을 제거하고 기본 DHCP 설정만 남겼다. 커널이 이미 예측 가능한 이름 규칙(Predictable Network Interface Names)으로 enp0s1을 잘 잡고 있었기 때문에 불필요한 매칭을 제거한 것이다.

Step 3. 안전한 테스트 및 적용

SSH 세션이 끊기는 불상사를 방지하기 위해 netplan try 명령어로 사전 검증을 진행했다. (설정 오류 시 일정 시간 후 자동 롤백되는 명령)

  
sudo netplan try
# 정상 작동 확인 후 적용
sudo netplan apply

Step 4. 권한 및 최종 상태 확인

Netplan 설정 파일의 권한이 너무 열려있으면 경고(Warning)가 발생하므로 소유자만 읽고 쓸 수 있도록 변경했다.

sudo chmod 600 /etc/netplan/netcfg.yaml

ip addr 명령어로 확인한 결과, IPv4는 dynamic 표시 없이 valid_lft forever 상태로 192.168.64.16/24 고정 IP가 정상 할당되었으며, IPv6는 dhcp6: true 설정이 살아 있어 정상적으로 DHCP 동작을 이어가는 것을 확인했습니다.

4. 리눅스 네트워크 트러블슈팅 체크리스트

네트워크 연결이 안 될 때는 아래와 같이 OSI 계층 하부에서 상부로 좁혀가며 확인하면 원인을 빠르게 찾을 수 있다.

1단계: Link 계층 확인 (물리/가상 연결)

ip link show enp0s1

state DOWN 상태라면 물리/가상 NIC 자체가 꺼진 상태이다.
인터페이스 이름이 변경되지 않았는지도 여기서 확인한다.

2단계: IP 할당 상태 확인

ip addr show enp0s1

IP가 없다면 Netplan 적용 실패이다.
원하는 IP가 아닌 dynamic 표시의 다른 IP가 잡힌다면 DHCP로 넘어간 상황(설정 파일 미인식 등)이다.

3단계: Netplan 설정 및 서비스 확인

  
sudo netplan generate --debug   # 문법 및 파싱 오류 검사
sudo netplan apply              # 적용 시 에러 메시지 확인
systemctl status systemd-networkd # networkd 서비스 상태 확인

4단계: 라우팅 테이블(Gateway) 확인

ip route

default via <게이트웨이IP> dev enp0s1 항목이 없으면 외부 인터넷 통신이 불가능하다.

5단계:단계별 통신 테스트

  
ping -c3 192.168.64.1   # 1. 게이트웨이 통신 (L2/L3 확인)
ping -c3 8.8.8.8        # 2. 외부 IP 통신 (라우팅/NAT 확인)
ping -c3 google.com     # 3. 도메인 통신 (DNS 확인)

6단계: DNS 설정 확인 (google.com만 안 될 때)

resolvectl status enp0s1
cat /etc/resolv.conf

요약

Netplan 설정 파일 확장자는 반드시 .yaml 이어야 한다. (.yml 무시됨)
VM 환경에서는 MAC 주소 변경으로 인한 match 조건 충돌을 주의해야 한다.
Netplan은 파일 전체를 덮어쓰지 않고 알파벳 순서대로 키(Key) 단위 병합(Merge)을 수행한다.
네트워크 문제는 Link ➔ IP ➔ Netplan ➔ Routing ➔ Ping ➔ DNS 순서로 좁혀 나가면 쉽게 원인을 파악할 수 있다.

리눅스

네트워크 리눅스