Kea DHCP 서버: 네트워크의 클라이언트에 IPv4 주소, 기본 게이트웨이, DNS와 임대 시간을 자동 제공하는 현대적인 DHCPv4 구현입니다. 기존 CentOS 7.9용 dhcpd 구성은 두 가지 이유로 새 구축에 적합하지 않습니다. CentOS 7은 지원 종료됐고 ISC DHCP도 2022년을 끝으로 유지보수가 종료됐습니다.
이 글은 Rocky Linux 9과 Kea 3.0 LTS 공식 RPM을 기준으로 단일 서브넷을 먼저 안전하게 구성합니다. 실제 인터페이스와 주소 계획을 확인하고 JSON 문법 검사, 최소 방화벽, 패킷 캡처, 예약 충돌 방지, DHCP relay와 이중화 설계까지 연결합니다.
왜 ISC DHCP가 아니라 Kea DHCP 서버인가
ISC는 DHCP 4.4.3-P1을 마지막 유지보수 릴리스로 발표하고 새 환경에는 Kea 또는 다른 유지보수 중인 서버를 선택하라고 권고합니다. Kea는 JSON 구성, Control Commands, 통계, hook, memfile·MySQL·PostgreSQL lease backend, 고가용성 기능을 제공하며 3.0 계열은 장기 지원 브랜치입니다.
Kea DHCP 서버와 DORA 동작 흐름
| 단계 | 메시지 | 실무 확인점 |
|---|---|---|
| 1 | DHCPDISCOVER | 주소가 없는 클라이언트의 broadcast 또는 relay 전달 |
| 2 | DHCPOFFER | 서버가 subnet 선택 후 임대와 옵션 제안 |
| 3 | DHCPREQUEST | 클라이언트가 선택한 서버·주소를 요청 |
| 4 | DHCPACK | 서버가 lease를 기록하고 최종 설정 승인 |
클라이언트와 서버가 같은 broadcast domain이 아니면 L3 장비의 DHCP relay가 요청을 unicast로 전달합니다. 이때 relay 주소와 subnet 선택, 서버에서 relay로 돌아가는 경로, ACL의 UDP 67·68 허용이 모두 맞아야 합니다.
Kea DHCP 서버: Rocky Linux 9 사전 점검
예제 서버 주소는 192.168.100.2/24, 인터페이스는 ens192, 게이트웨이는 192.168.100.1입니다. 그대로 복사하지 말고 실제 NIC, VLAN, 중복 주소, 기존 DHCP 서버를 먼저 조사합니다.
cat /etc/os-release
ip -br link
ip -br address
ip route
nmcli -t -f NAME,DEVICE,TYPE,STATE connection show --active
ss -lunp | grep -E ':(67|68)\b' || true주소 풀 충돌 확인
- 동적 풀은 게이트웨이, 서버, 프린터, 네트워크 장비의 정적 주소와 겹치지 않게 만듭니다.
- 예약 주소는 예제처럼 동적 풀 밖에 두거나 Kea의 충돌 처리 정책을 명확히 검증합니다.
- 같은 VLAN에서 기존 DHCP 서버가 응답하는지 패킷 캡처로 확인합니다.
- 클라이언트의 MAC 무작위화 정책 때문에 hw-address 예약이 바뀔 수 있는지 점검합니다.
Kea DHCP 서버: 3.0 LTS 공식 RPM 설치
ISC는 RHEL 계열용 패키지를 Cloudsmith 저장소로 제공합니다. 편의를 위해 원격 스크립트를 바로 파이프로 실행하지 않고 로컬에 받아 내용과 TLS 출처를 검토한 뒤 실행합니다. 조직의 공급망 정책이 있으면 승인된 내부 저장소로 동기화하십시오.
curl --fail --location --proto '=https' --tlsv1.2 https://dl.cloudsmith.io/public/isc/kea-3-0/setup.rpm.sh --output /tmp/isc-kea-3-0-setup.rpm.sh
less /tmp/isc-kea-3-0-setup.rpm.sh
sudo bash /tmp/isc-kea-3-0-setup.rpm.shDHCPv4 구성 요소만 설치하고 버전 기록
sudo dnf install -y isc-kea-dhcp4
rpm -q isc-kea-dhcp4 isc-kea-common
kea-dhcp4 -V
dnf repolist --enabled | grep -i keaKea DHCP 서버 JSON 설정
공식 RPM의 기본 파일은 일반적으로 /etc/kea/kea-dhcp4.conf입니다. 먼저 백업하고 sudoedit로 아래 예제를 환경에 맞게 입력합니다. JSON은 주석·쉼표·따옴표 오류가 잦으므로 서비스 시작 전에 Kea 자체 검사기를 반드시 통과시킵니다.
sudo cp -a /etc/kea/kea-dhcp4.conf /etc/kea/kea-dhcp4.conf.before-$(date +%F-%H%M%S)
sudoedit /etc/kea/kea-dhcp4.conf{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "ens192" ]
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/kea-leases4.csv",
"lfc-interval": 3600
},
"valid-lifetime": 3600,
"renew-timer": 900,
"rebind-timer": 1800,
"subnet4": [
{
"id": 100,
"subnet": "192.168.100.0/24",
"pools": [
{ "pool": "192.168.100.100 - 192.168.100.200" }
],
"option-data": [
{ "name": "routers", "data": "192.168.100.1" },
{ "name": "domain-name-servers", "data": "192.168.100.53" },
{ "name": "domain-name", "data": "example.internal" }
],
"reservations": [
{
"hw-address": "00:11:22:33:44:55",
"ip-address": "192.168.100.50",
"hostname": "printer1"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"output-options": [ { "output": "syslog" } ],
"severity": "INFO"
}
]
}
}예제에서 바꿔야 하는 값
| 항목 | 예제 | 검증 방법 |
|---|---|---|
| interface | ens192 | ip -br address의 실제 서비스 NIC |
| subnet | 192.168.100.0/24 | VLAN의 실제 네트워크와 prefix |
| pool | .100-.200 | 정적·예약·다른 DHCP 풀과 비중복 |
| router | .1 | 클라이언트가 사용하는 실제 게이트웨이 |
| DNS | .53 | 클라이언트에서 접근 가능한 내부 DNS |
| reservation | .50 | 풀 밖의 미사용 주소와 안정적인 식별자 |
Kea DHCP 서버 문법 검사와 시작
sudo kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
sudo systemctl enable --now kea-dhcp4
sudo systemctl status kea-dhcp4 --no-pager
sudo journalctl -u kea-dhcp4 -b --no-pager | tail -n 100방화벽과 최소 노출
DHCPv4 서버는 UDP 67을 사용하고 클라이언트는 UDP 68을 사용합니다. 서버가 직접 연결된 VLAN만 처리한다면 서비스 NIC가 속한 firewalld zone에 DHCP 서비스를 허용합니다. relay 환경에서는 relay·ACL·라우팅을 함께 제한합니다.
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=internal --add-service=dhcp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --list-services
sudo ss -lunp | grep ':67'예제의 internal zone이 실제 서비스 NIC에 연결됐는지 먼저 확인하십시오. 모든 zone에 포트를 여는 방식은 사용하지 않습니다. 네트워크 장비에서는 DHCP snooping의 trusted 포트를 relay·정상 서버 경로에만 지정합니다.
Kea DHCP 서버 패킷과 lease 진단
실시간 DORA 패킷 확인
sudo tcpdump -ni ens192 -vvv '(udp port 67 or udp port 68)'서비스 로그와 lease 파일 확인
sudo journalctl -u kea-dhcp4 -f
sudo ls -lh /var/lib/kea/
sudo tail -n 20 /var/lib/kea/kea-leases4.csv| 증상 | 패킷에서 보이는 상태 | 우선 확인 |
|---|---|---|
| DISCOVER 없음 | 클라이언트 요청 자체가 안 보임 | VLAN, NIC, relay, 캡처 인터페이스 |
| DISCOVER만 있음 | OFFER 없음 | subnet 선택, pool 소진, 서버 로그, 방화벽 |
| OFFER 뒤 REQUEST 없음 | 클라이언트가 다른 서버 선택 가능 | rogue DHCP, 옵션, 클라이언트 정책 |
| ACK 후 통신 불가 | 임대는 정상 | gateway, DNS, ACL, 중복 IP |
| 예약이 안 됨 | 다른 식별자로 요청 | random MAC, client-id, 예약 식별자 |
DHCP relay와 여러 서브넷
DHCP 서버를 각 VLAN에 직접 연결할 필요는 없습니다. 라우터나 L3 스위치의 relay 주소가 요청을 전달하면 Kea는 relay가 지정한 링크 정보를 사용해 subnet을 선택합니다. 각 subnet에 고유한 id를 사용하고, 서버의 응답 경로와 relay 접근 ACL을 검증합니다. vendor별 relay 명령은 장비 공식 문서를 따릅니다.
ip route get <RELAY_IP>
sudo tcpdump -ni any -vvv 'host <RELAY_IP> and (udp port 67 or udp port 68)'
sudo journalctl -u kea-dhcp4 --since '-10 min'Kea DHCP 서버 예약 설계
예약은 ‘고정 IP를 수동 설정’하는 것과 다릅니다. 서버가 동일한 클라이언트 식별자를 볼 때 특정 lease를 제공하는 정책입니다. 관리형 프린터·서버 NIC는 MAC이 안정적일 수 있지만 모바일 단말은 SSID별 private MAC을 사용할 수 있습니다. 예약 대상을 선정할 때 hw-address, client-id, flex-id 정책을 함께 검토합니다.
- 예약 주소가 동적 풀과 겹칠 때의 충돌 방지 정책을 테스트합니다.
- 자산 관리 시스템의 MAC·소유자·용도와 예약 변경 이력을 연결합니다.
- 장비 교체 시 기존 식별자와 lease를 정리하는 승인 절차를 둡니다.
- 예약이 많아지면 JSON 수동 편집보다 지원되는 host backend와 변경 API를 검토합니다.
ISC DHCP에서 Kea로 마이그레이션
ISC의 Kea Migration Assistant는 기존 dhcpd.conf를 부분 변환하지만 결과를 그대로 운영에 적용할 수 있다는 뜻은 아닙니다. 조건문, DDNS, failover, class, lease 처리와 지원되지 않는 옵션을 사람이 검토해야 합니다. 기존 서버와 새 서버가 같은 풀을 동시에 권한 있게 제공하지 않도록 전환 창을 설계합니다.
- 기존 설정·lease·DNS 연동·relay·옵션·예약을 백업하고 목록화합니다.
- KeaMA 결과의 경고와 미변환 구문을 검토해 최소 JSON을 만듭니다.
- 격리 VLAN에서 DORA, 예약, 갱신, DNS, PXE와 장시간 lease 동작을 시험합니다.
- lease 시간이 지나도록 단계적으로 줄이거나 전환 중 주소 충돌 방지 방식을 정합니다.
- 변경 창에서 기존 응답을 중지하고 Kea를 시작해 패킷·로그·중복 주소를 관찰합니다.
- 복귀 조건과 기존 서버 재활성화 절차를 미리 문서화합니다.
Kea DHCP 서버 고가용성 설계
Kea HA hook은 hot-standby, load-balancing 등 partner 상태와 lease update를 관리할 수 있습니다. 단순히 두 서버가 같은 JSON을 가졌다고 HA가 되는 것은 아닙니다. heartbeat·상태 전환·lease 동기화, split-brain 시 응답 정책, relay 대상, hook 호환 버전과 장애 시나리오를 함께 설계합니다.
- 두 서버의 시간 동기화, 버전, hook과 subnet 설정을 일치시킵니다.
- HA 통신 포트를 관리망에서만 허용하고 TLS·인증 지원 범위를 확인합니다.
- primary 중지, HA 링크 단절, relay 경로 단절, lease backend 장애를 각각 시험합니다.
- partner-down 전환 시간 동안 클라이언트가 받는 영향을 실제 단말과 perfdhcp로 측정합니다.
- HA는 잘못된 옵션·삭제·운영자 오류를 복제하므로 설정 버전 관리와 백업이 별도로 필요합니다.
운영 체크리스트
- CentOS 7과 ISC DHCP EOL을 인지하고 지원되는 OS·Kea 브랜치를 선택했습니다.
- 실제 인터페이스, subnet, pool, gateway, DNS, relay와 기존 DHCP 응답을 확인했습니다.
- JSON 검사 뒤 서비스를 시작하고 DISCOVER·OFFER·REQUEST·ACK를 캡처했습니다.
- 방화벽은 서비스 VLAN 또는 relay 경로에만 최소 허용했습니다.
- 예약 주소·식별자·random MAC 정책과 pool 소진 경보를 관리합니다.
- 설정, lease backend, hook, 패키지 버전을 백업하고 복구를 시험합니다.
- HA는 서버 중지뿐 아니라 링크 분할과 lease 동기화 실패까지 검증했습니다.
공식 문서와 관련 가이드
- ISC DHCP 유지보수 종료 안내
- Kea 3.0 LTS 공식 관리자 문서
- ISC Kea 공식 패키지와 서비스 이름
- Kea 3.0 Cloudsmith 저장소 설정
- ISC DHCP에서 Kea 마이그레이션
- Kea HA 공식 Quickstart
- Linux 디스크·inode 장애 진단 가이드
정리
Kea DHCP 서버: 새 환경에서는 EOL된 dhcpd 예제를 반복하기보다 지원되는 Kea와 OS를 선택하고, 주소 설계와 실제 패킷을 기준으로 검증해야 합니다. 설치보다 중요한 것은 중복 DHCP 방지, pool·예약 관리, relay 경로, 최소 방화벽, lease·설정 복구와 네트워크 분할을 포함한 HA 시험입니다.
