DHCP 동작 원리와 IP 주소 자동 할당, DORA 패킷 분석
DHCP 동작 원리와 IP 주소 자동 할당, DORA 패킷 분석
1. DHCP란 무엇인가?
서버나 PC가 네트워크에 연결되면 다른 장비와 통신하기 위해 IP 주소가 필요하다. IP 주소뿐만 아니라 Subnet Mask, Default Gateway, DNS 서버 주소도 적절하게 설정해야 한다.
소규모 네트워크에서는 관리자가 각 장비에 IP 주소를 직접 입력할 수 있다. 하지만 수백 대 이상의 서버와 PC를 운영하는 환경에서 모든 장비의 네트워크 설정을 수동으로 관리하면 설정 오류가 발생하기 쉽고 운영 부담도 커진다.
이 문제를 해결하기 위해 사용하는 프로토콜이 **DHCP(Dynamic Host Configuration Protocol)**다.
DHCP는 네트워크 장비에 IP 주소와 네트워크 설정 정보를 자동으로 할당하는 프로토콜이다.
DHCP 서버는 미리 설정된 주소 범위에서 사용 가능한 IP 주소를 할당하고, 클라이언트는 할당받은 주소를 일정 시간 동안 사용한다.
DHCP를 통해 전달할 수 있는 대표적인 정보는 다음과 같다.
항목설명예시IP Address장비에 할당되는 IP 주소192.168.10.100Subnet Mask네트워크와 호스트 구분255.255.255.0Default Gateway다른 네트워크로 통신할 때 사용하는 경로192.168.10.1DNS Server도메인 이름을 IP 주소로 변환하는 서버192.168.10.53Lease TimeIP 주소를 사용할 수 있는 임대 기간86400초Domain Name클라이언트가 사용할 도메인 정보example.local
예를 들어 서버가 DHCP를 통해 다음 정보를 할당받았다고 가정해 보자.
IP Address : 192.168.10.100 Subnet Mask : 255.255.255.0 Default Gateway : 192.168.10.1 DNS Server : 192.168.10.53 Lease Time : 86400 seconds
이 경우 서버는 192.168.10.100/24 주소를 사용하고, 다른 네트워크로 통신할 때는 192.168.10.1을 Gateway로 사용하며, 도메인 이름 조회에는 192.168.10.53 DNS 서버를 사용할 수 있다.
단, DHCP 서버가 어떤 옵션을 제공하는지는 DHCP 서버 설정과 네트워크 환경에 따라 달라진다.
2. DHCP는 어떤 방식으로 동작할까?
DHCP의 핵심은 클라이언트가 네트워크에 접속했을 때 적절한 IP 주소와 네트워크 설정을 전달받는 것이다.
일반적인 DHCPv4 주소 할당 과정은 다음 네 단계로 진행된다.
DHCP Client DHCP Server
| |
|---- DHCP Discover --------------->|
| |
|<--- DHCP Offer -------------------|
| |
|---- DHCP Request ---------------->|
| |
|<--- DHCP ACK ---------------------|
| |
| IP 주소 사용 시작 |
이 네 단계를 각각 Discover, Offer, Request, Acknowledge라고 한다.
앞 글자를 따서 DORA 과정이라고 부른다.
단계메시지방향목적1DiscoverClient → ServerDHCP 서버 탐색2OfferServer → Client사용 가능한 IP 주소 제안3RequestClient → Server제안된 주소 사용 요청4ACKServer → Client주소 할당 승인
이제 각 단계에서 실제로 어떤 일이 발생하는지 살펴보자.
3. DHCP Discover — DHCP 서버 탐색
클라이언트가 처음 네트워크에 연결되었고 사용할 IP 주소가 없다고 가정하자.
클라이언트는 DHCP 서버를 찾아야 하지만, 아직 자신의 IP 주소도 모르고 DHCP 서버의 IP 주소도 모른다.
이때 DHCP 클라이언트는 일반적으로 다음과 같이 패킷을 전송한다.
Source IP : 0.0.0.0 Destination IP : 255.255.255.255 Source Port : UDP 68 Destination Port : UDP 67 Message Type : DHCP Discover
주요 특징은 다음과 같다.
- 출발지 IP 주소는
0.0.0.0을 사용한다. - 목적지 IP 주소는 제한적 브로드캐스트 주소인
255.255.255.255를 사용한다. - 클라이언트는 UDP 68번 포트를 사용한다.
- 서버는 UDP 67번 포트를 사용한다.
클라이언트가 브로드캐스트를 사용하는 이유는 DHCP 서버의 위치를 아직 알지 못하기 때문이다.
일반적인 DHCPv4 초기 주소 할당에서는 클라이언트가 같은 네트워크의 DHCP 서버를 찾기 위해 브로드캐스트 Discover 메시지를 전송한다.
Switch
|
+-----------+-----------+
| | |
Client A Client B DHCP Server
|
| DHCP Discover
| 0.0.0.0 -> 255.255.255.255
|
같은 브로드캐스트 도메인에 있는 장비들은 해당 브로드캐스트를 수신할 수 있지만, 일반적인 라우터는 브로드캐스트 패킷을 다른 네트워크로 그대로 전달하지 않는다.
따라서 클라이언트와 DHCP 서버가 서로 다른 서브넷에 있다면 DHCP Relay가 필요할 수 있다.
이 부분은 뒤에서 자세히 설명한다.
4. DHCP Offer — IP 주소 제안
DHCP 서버는 Discover 메시지를 수신하면 주소 할당 정책에 따라 사용 가능한 IP 주소를 선택한다.
예를 들어 DHCP 서버의 주소 풀을 다음과 같이 설정했다고 가정하자.
DHCP Server : 192.168.10.10 Address Pool: 192.168.10.100 192.168.10.101 192.168.10.102 192.168.10.103 192.168.10.104
서버는 정책과 주소 사용 상태에 따라 클라이언트에 192.168.10.100을 제안할 수 있다.
DHCP Offer Your IP Address : 192.168.10.100 Subnet Mask : 255.255.255.0 Default Gateway : 192.168.10.1 DNS Server : 192.168.10.53 Lease Time : 86400
Offer는 주소 할당 제안이다. 클라이언트가 해당 주소를 최종적으로 사용할 수 있도록 승인받는 과정은 아직 남아 있다.
DHCP 서버가 여러 대라면 하나 이상의 Offer 메시지를 수신할 수도 있다. 이 경우 클라이언트는 정책에 따라 제안을 선택한다.
5. DHCP Request — 주소 사용 요청
클라이언트가 사용할 DHCP Offer를 선택하면 DHCP Request 메시지를 전송한다.
초기 주소 할당 과정에서는 이 메시지가 브로드캐스트로 전송되는 경우가 일반적이다.
DHCP Request Requested IP Address : 192.168.10.100 Server Identifier : 192.168.10.10
이 메시지는 클라이언트가 어떤 주소를 사용하려고 하는지, 어떤 DHCP 서버의 제안을 선택했는지 알리는 역할을 한다.
DHCP 서버가 여러 대 존재하는 환경에서는 선택되지 않은 DHCP 서버가 Request 메시지를 확인하고 자신이 제안한 주소를 다른 클라이언트에 할당할 수 있도록 정리할 수 있다.
여기서 중요한 점은 DHCP Request가 단순히 IP 주소를 요청하는 메시지라는 사실만이 아니다.
클라이언트가 선택한 DHCP 서버와 IP 주소를 네트워크에 알리는 과정이라는 점을 이해해야 한다.
6. DHCP ACK — 주소 할당 승인
DHCP 서버는 요청을 검증한 후 DHCP ACK 메시지를 전송한다.
DHCP ACK Assigned IP : 192.168.10.100 Subnet Mask : 255.255.255.0 Default Gateway : 192.168.10.1 DNS Server : 192.168.10.53 Lease Time : 86400 seconds
클라이언트는 이 정보를 바탕으로 네트워크 설정을 적용한다.
다만 DHCP ACK를 받았다고 해서 모든 네트워크 통신이 정상이라는 뜻은 아니다.
다음과 같은 문제가 여전히 존재할 수 있다.
- Gateway가 실제로 응답하지 않는다.
- DNS 서버 주소가 잘못되었다.
- VLAN이 잘못 설정되어 있다.
- IP 주소가 다른 장비와 충돌한다.
- 방화벽에서 필요한 트래픽을 차단한다.
따라서 DHCP 주소 할당 성공과 실제 네트워크 통신 성공은 구분해서 확인해야 한다.
7. DHCP 패킷은 어디에서 확인할까?
DHCP 장애를 분석할 때는 설정 파일만 확인하는 것으로 부족할 수 있다.
클라이언트가 Discover를 전송하는지, Offer가 돌아오는지, Request와 ACK까지 정상적으로 진행되는지 직접 확인하면 장애 위치를 좁힐 수 있다.
Linux 서버에서 tcpdump를 사용해 보자.
먼저 네트워크 인터페이스를 확인한다.
ip -br link ip -br addr
예를 들어 인터페이스 이름이 ens160이라고 가정한다.
DHCP 트래픽을 확인하는 명령어는 다음과 같다.
sudo tcpdump -ni ens160 -vvv 'udp port 67 or udp port 68'
옵션의 의미는 다음과 같다.
옵션의미-nIP 주소와 포트를 이름으로 변환하지 않음-i ens160지정한 인터페이스에서 캡처-v패킷 상세 정보 출력-vvv더 상세한 패킷 정보 출력udp port 67 or udp port 68DHCPv4 관련 UDP 트래픽 필터
환경과 tcpdump 버전에 따라 DHCP 필드가 모두 표시되지는 않을 수 있다. 상세한 옵션과 임대 정보는 Wireshark로 PCAP 파일을 분석하면 더 편리하다.
패킷을 파일로 저장하려면 다음과 같이 실행한다.
sudo tcpdump -ni ens160 \ -s 0 \ -w /tmp/dhcp-capture.pcap \ 'udp port 67 or udp port 68'
캡처를 종료한 후 파일을 확인한다.
tcpdump -nn -vvv -r /tmp/dhcp-capture.pcap
PCAP 파일을 Wireshark에서 열면 Discover, Offer, Request, ACK 메시지를 구분하고 각 메시지의 DHCP 옵션을 확인할 수 있다.
단, DHCP 패킷이 보이지 않는다고 해서 반드시 DHCP 서버가 고장 난 것은 아니다. 잘못된 인터페이스에서 캡처했거나, 실제 트래픽이 다른 VLAN 또는 물리 포트에서 발생하고 있을 수도 있다.
8. 실제 장애 사례 1 — DHCP Discover만 반복되는 경우
현장에서 자주 만날 수 있는 상황이다.
클라이언트는 DHCP 서버에서 IP 주소를 받으려고 하지만 주소가 할당되지 않는다.
tcpdump 결과가 다음과 같다고 가정하자.
0.0.0.0.68 > 255.255.255.255.67: DHCP Discover 0.0.0.0.68 > 255.255.255.255.67: DHCP Discover 0.0.0.0.68 > 255.255.255.255.67: DHCP Discover
클라이언트가 Discover를 반복해서 전송하지만 Offer를 받지 못하고 있다.
이때는 다음 순서로 점검한다.
8-1. 네트워크 인터페이스 확인
ip -br link ip -br addr
인터페이스가 DOWN 상태인지, 링크가 정상인지 확인한다.
물리 서버라면 다음 명령어로 링크 상태와 속도를 점검할 수 있다.
sudo ethtool ens160
출력에서 다음 항목을 확인한다.
Link detected: yes
가상 머신이라면 가상 NIC 연결 상태, 하이퍼바이저의 가상 스위치, 포트 그룹 및 VLAN 설정도 확인해야 한다.
8-2. DHCP 서버와 같은 네트워크인지 확인
DHCP 서버가 클라이언트와 같은 브로드캐스트 도메인에 있는지 확인한다.
서로 다른 서브넷에 있다면 DHCP Relay가 올바르게 설정되어 있어야 한다.
8-3. DHCP 서버 확인
서버 측에서도 패킷을 캡처한다.
sudo tcpdump -ni ens160 -vvv 'udp port 67 or udp port 68'
클라이언트에서 Discover를 보냈는데 서버에서 수신되지 않는다면 다음 항목을 확인한다.
- 스위치 VLAN 설정
- DHCP Relay 설정
- 네트워크 ACL
- 가상 스위치 설정
- 중간 방화벽
- DHCP 서버가 연결된 인터페이스
반대로 서버에서 Discover를 수신했지만 Offer를 전송하지 않는다면 주소 풀 고갈, DHCP 서버 설정, 주소 할당 정책 및 서비스 상태를 확인한다.
핵심은 Discover가 클라이언트에서 나가는지, DHCP 서버까지 도달하는지, 서버가 Offer를 생성하는지를 각각 구분하는 것이다.
9. 실제 장애 사례 2 — IP 주소는 받았지만 Gateway 통신이 안 되는 경우
이번에는 DHCP 할당 자체는 성공했지만 외부 네트워크에 접속할 수 없는 상황이다.
클라이언트에 다음 주소가 할당되었다고 가정한다.
IP Address : 192.168.10.100 Subnet Mask : 255.255.255.0 Default Gateway : 192.168.20.1
클라이언트 IP는 192.168.10.100/24인데 Gateway는 192.168.20.1이다.
일반적인 단일 서브넷 구성에서는 Gateway가 클라이언트와 직접 연결된 네트워크에 있어야 하므로 이 설정은 의심 대상이다. 특수한 라우팅 구성이 없는지 먼저 확인해야 한다.
Linux에서는 다음 명령어로 확인한다.
ip -4 addr show ip route ip route get 8.8.8.8
정상적인 예시는 다음과 같다.
default via 192.168.10.1 dev ens160 192.168.10.0/24 dev ens160 proto kernel scope link
잘못된 Gateway가 설정되었다면 DHCP 서버에서 전달하는 Router 옵션, 일반적으로 DHCP 옵션 3을 확인한다.
이때 주의할 점은 DHCP 임대 정보를 수정했다고 해서 기존 클라이언트의 설정이 즉시 변경되는 것은 아니라는 점이다. 클라이언트가 임대를 갱신하고 새로운 설정을 적용해야 할 수 있다.
DHCP 서버에서 Router 옵션을 수정한 뒤에는 클라이언트가 실제로 어떤 값을 적용했는지 다시 확인한다.
ip route
또한 Gateway에 대한 ARP 상태를 확인한다.
ip neigh
Gateway 주소가 192.168.10.1이라면 다음과 같이 확인할 수 있다.
ping -c 3 192.168.10.1
Ping이 실패한다고 해서 무조건 Gateway 장애라고 단정하면 안 된다. ICMP가 차단되어 있을 수 있으므로 ARP, 라우팅 테이블, 패킷 캡처를 함께 확인해야 한다.
10. 실제 장애 사례 3 — DHCP 서버의 IP 주소 풀 고갈
DHCP 서버가 정상적으로 동작하더라도 할당할 수 있는 IP 주소가 부족하면 새로운 클라이언트에 주소를 제공하지 못할 수 있다.
예를 들어 주소 풀이 다음과 같다고 가정한다.
DHCP Pool: 192.168.10.100 - 192.168.10.110
총 11개 주소만 사용할 수 있다.
이미 모든 주소가 할당되어 있고 재사용 가능한 주소도 없다면 신규 클라이언트가 DHCP Discover를 전송해도 정상적인 Offer를 받지 못할 수 있다.
이때 확인할 항목은 다음과 같다.
- DHCP 주소 풀의 전체 범위
- 현재 임대 중인 주소 수
- 임대 만료 시간
- 예약 주소 및 제외 주소
- 실제 네트워크에 연결된 클라이언트 수
- 사용하지 않는 장비의 임대 정보
- 중복 DHCP 서버의 존재 여부
주소 풀 고갈이 확인되었다면 무작정 임대 시간을 줄이기보다는 네트워크 규모와 실제 사용량을 확인해야 한다.
주소 범위를 확장할 수 있는지 검토하고, Subnet Mask 변경이 필요한 경우에는 기존 장비와의 호환성 및 라우팅 설계까지 고려해야 한다.
예를 들어 /24 네트워크를 단순히 /23으로 확장하는 것은 DHCP 서버의 주소 풀만 변경하는 작업이 아니다. Gateway, VLAN, 라우팅, 다른 장비의 서브넷 설정도 함께 검토해야 한다.
11. DHCP Lease Time과 IP 주소 갱신
DHCP로 할당받은 IP 주소는 일반적으로 영구적으로 사용할 수 있는 주소가 아니다.
클라이언트는 DHCP 서버로부터 임대 기간(Lease Time)을 전달받는다.
예를 들어 임대 기간이 24시간이라면 클라이언트는 해당 기간을 기준으로 주소 사용 권한을 갱신한다.
DHCPv4의 일반적인 임대 갱신 과정은 다음과 같다.
임대 시작
|
v
T1 도달: 일반적으로 임대 시간의 50%
|
v
기존 DHCP 서버에 갱신 요청
|
+---- 성공 ----> 새 임대 기간 적용
|
+---- 실패
|
v
T2 도달: 일반적으로 임대 시간의 87.5%
|
v
다른 DHCP 서버에도 갱신 시도
|
+---- 성공 ----> 새 임대 기간 적용
|
+---- 실패
|
v
임대 만료 시 주소 사용 중단
T1과 T2는 일반적인 기본값이며, DHCP 서버가 다른 값을 제공할 수도 있다.
T1 시점에는 일반적으로 기존 DHCP 서버에 유니캐스트로 갱신을 요청한다. T2 시점에는 기존 서버에 접근할 수 없는 경우 다른 DHCP 서버를 찾기 위해 브로드캐스트 방식으로 재요청할 수 있다.
임대가 만료되었는데 갱신하지 못하면 클라이언트는 해당 IP 주소를 계속 사용할 수 없게 될 수 있다.
따라서 네트워크 장애가 특정 시간 간격으로 반복된다면 DHCP 임대 갱신과 서버 가용성을 확인할 필요가 있다.
12. Linux에서 DHCP 상태 확인하기
Linux 배포판과 네트워크 관리 방식에 따라 DHCP를 관리하는 서비스가 다를 수 있다.
Rocky Linux나 RHEL 계열에서는 NetworkManager를 사용하는 구성이 일반적이다.
12-1. IP 주소와 인터페이스 확인
ip -br addr ip -4 addr show
12-2. 라우팅 테이블 확인
ip route ip route get 8.8.8.8
12-3. NetworkManager 연결 정보 확인
nmcli device status nmcli connection show
특정 연결의 상세 설정은 다음과 같이 확인할 수 있다.
nmcli connection show "System ens160"
연결 이름은 실제 환경에 맞게 변경해야 한다.
DHCP 사용 여부와 IP 설정 방식을 확인하려면 출력에서 다음 항목을 확인한다.
ipv4.method: auto ipv4.addresses: ipv4.gateway: ipv4.dns:
ipv4.method가 auto라면 일반적으로 DHCP를 통해 IPv4 설정을 얻도록 구성된 것이다.
반면 manual이면 정적 IPv4 설정을 사용하는 구성이다.
12-4. DHCP 관련 로그 확인
NetworkManager 로그를 확인한다.
sudo journalctl -u NetworkManager --since "30 minutes ago"
실시간으로 확인하려면 다음 명령어를 사용한다.
sudo journalctl -u NetworkManager -f
로그에서 DHCP 요청, 임대 획득 실패, 연결 재시도, 주소 충돌 관련 메시지를 확인한다.
다만 모든 배포판이 동일한 로그 메시지를 사용하는 것은 아니다. DHCP 클라이언트 구현과 NetworkManager 버전에 따라 메시지가 달라질 수 있다.
12-5. 주의: 무작정 DHCP 갱신 명령을 실행하지 않는다
운영 서버에서 DHCP 갱신을 시도하면 기존 IP 주소나 라우팅 정보가 변경될 수 있다.
원격 SSH 접속 중인 서버라면 네트워크 설정 변경으로 연결이 끊길 위험도 있다.
따라서 운영 환경에서는 다음 순서를 권장한다.
- 현재 IP 주소와 라우팅 테이블을 저장한다.
- NetworkManager 연결 설정을 확인한다.
- DHCP 서버와 네트워크 장비 상태를 점검한다.
- 작업 시간과 복구 방법을 확보한다.
- 승인된 절차에 따라 갱신 또는 재연결을 수행한다.
- IP, Gateway, DNS, 서비스 통신을 다시 검증한다.
특히 원격 접속 중인 운영 서버에서는 콘솔 접근이나 별도의 복구 경로를 확보한 뒤 작업하는 것이 안전하다.
13. DHCP Relay란 무엇인가?
대규모 네트워크에서는 DHCP 서버와 클라이언트가 서로 다른 서브넷에 있는 경우가 많다.
예를 들어 다음과 같은 구성을 생각해 보자.
[Client VLAN 10]
192.168.10.0/24
|
|
[L3 Switch]
DHCP Relay
|
|
[Server VLAN 100]
192.168.100.0/24
|
|
[DHCP Server]
192.168.100.10
클라이언트가 보내는 DHCP Discover는 일반적으로 브로드캐스트다. 라우터는 이를 기본적으로 다른 서브넷으로 전달하지 않는다.
이때 DHCP Relay가 클라이언트의 요청을 받아 DHCP 서버로 전달한다.
Relay는 요청을 전달할 때 클라이언트가 속한 네트워크 정보를 서버가 판단할 수 있도록 관련 정보를 제공한다. 대표적으로 giaddr 필드가 사용된다.
DHCP 서버는 이 정보를 바탕으로 적절한 서브넷의 주소 풀을 선택할 수 있다.
예를 들어 DHCP 서버에는 다음과 같은 주소 풀이 설정되어 있을 수 있다.
Subnet 1: 192.168.10.0/24 Gateway: 192.168.10.1 Subnet 2: 192.168.20.0/24 Gateway: 192.168.20.1
Relay 정보에 따라 서버는 클라이언트가 속한 서브넷에 맞는 주소와 옵션을 제공한다.
DHCP Relay 장애 점검 항목
DHCP Discover는 발생하지만 Offer가 돌아오지 않는 상황에서는 다음을 확인한다.
- 클라이언트 VLAN과 DHCP Relay 설정
- Relay가 지정한 DHCP 서버 주소
- DHCP 서버까지의 라우팅
- UDP 67번 포트 통신
- DHCP 서버의 해당 서브넷 주소 풀
- DHCP 서버에서 Relay 요청을 수신하는지
- DHCP 응답이 Relay를 거쳐 클라이언트까지 돌아오는지
단순히 DHCP 서버 프로세스가 실행 중이라는 사실만으로 DHCP 서비스가 정상이라고 판단해서는 안 된다.
14. DHCP와 DNS는 어떻게 연결될까?
앞선 네트워크 11편에서는 DNS의 동작 원리를 살펴보았다.
DHCP와 DNS는 서로 다른 역할을 하지만 일반적인 클라이언트 네트워크에서는 밀접하게 연결된다.
DHCP
|
+-- IP Address
|
+-- Subnet Mask
|
+-- Default Gateway
|
+-- DNS Server
|
v
DNS
|
v
Domain -> IP Address
DHCP는 클라이언트가 사용할 DNS 서버 주소를 전달할 수 있다.
클라이언트가 example.com에 접속하려면 먼저 DNS 서버에 질의하여 IP 주소를 확인해야 한다.
따라서 DHCP에서 잘못된 DNS 서버 주소를 전달하면 IP 주소와 Gateway가 정상이어도 도메인 기반 접속에 문제가 발생할 수 있다.
이때 다음 명령어로 DNS 설정을 확인한다.
cat /etc/resolv.conf
NetworkManager 환경에서는 다음과 같이 확인할 수도 있다.
nmcli device show
실제 DNS 서버에 직접 질의하려면 다음과 같이 실행한다.
dig @192.168.10.53 example.com
여기서 192.168.10.53은 예시 DNS 서버 주소다. 실제 환경에 맞게 변경해야 한다.
DNS 질의가 실패한다면 다음 두 가지를 구분해야 한다.
- DHCP가 잘못된 DNS 서버 주소를 전달한 문제
- DNS 서버 주소는 정확하지만 DNS 서버에 접근할 수 없는 문제
두 문제는 원인과 해결 방법이 다르다.
15. 실전 장애 분석: DHCP가 정상인지 확인하는 순서
운영 현장에서 신규 서버나 PC에 IP 주소가 할당되지 않는다고 가정하자.
다음 순서로 확인하면 장애 원인을 단계적으로 좁힐 수 있다.
1단계. 인터페이스 상태 확인
ip -br link ip -br addr
인터페이스가 활성화되어 있는지, 예상한 IP 주소가 설정되어 있는지 확인한다.
2단계. DHCP 패킷 확인
sudo tcpdump -ni ens160 -vvv 'udp port 67 or udp port 68'
Discover, Offer, Request, ACK 중 어디까지 진행되는지 확인한다.
3단계. DHCP 서버 로그 확인
DHCP 서버의 구현에 따라 서비스 이름과 로그 위치는 다르다.
서비스 상태를 확인하고 해당 서버의 로그에서 요청 수신, 주소 할당, 주소 풀 부족 및 정책 관련 오류를 찾는다.
4단계. IP 주소와 라우팅 확인
ip -4 addr show ip route ip route get 8.8.8.8
주소와 Gateway가 올바르게 적용되었는지 확인한다.
5단계. ARP와 Gateway 확인
ip neigh ping -c 3 <gateway-ip>
ARP 상태와 Gateway 응답을 확인한다. Ping 결과만으로 장애 여부를 확정하지 않는다.
6단계. DNS 확인
cat /etc/resolv.conf dig example.com
IP 통신은 되지만 도메인 접속이 실패한다면 DNS 설정과 질의 결과를 확인한다.
7단계. 실제 서비스 통신 확인
예를 들어 HTTPS 서버에 접근해야 한다면 다음과 같이 확인한다.
nc -zv <server-ip> 443 curl -vk https://<server-ip>/
이 단계에서는 DHCP 문제가 해결되었는지뿐 아니라 실제 서비스에 필요한 네트워크 경로와 포트가 정상인지 검증한다.
16. DHCP 장애 분석 핵심 정리
DHCP 문제를 분석할 때는 단순히 IP 주소가 있는지만 확인해서는 안 된다.
관찰 결과우선 점검할 항목IP 주소가 없음인터페이스, DHCP Discover, DHCP 서버Discover만 반복됨DHCP 서버 응답, VLAN, Relay, 주소 풀Offer는 있지만 ACK가 없음Request 전달, 서버 정책, DHCP 서버 로그주소는 있지만 Gateway가 없음DHCP Router 옵션, 클라이언트 설정주소와 Gateway는 정상이나 외부 통신 실패라우팅, ARP, 방화벽, 상위 네트워크IP로는 접속되지만 도메인 접속 실패DNS 서버 주소, DNS 질의, DNS 경로특정 VLAN에서만 DHCP 실패VLAN, Relay, 해당 서브넷 주소 풀일정 시간이 지나면 통신 장애 발생Lease 갱신, DHCP 서버 가용성, IP 충돌
핵심은 DHCP 패킷이 어느 단계까지 정상적으로 진행되는지 확인하고, IP 주소 할당 문제와 이후의 네트워크 통신 문제를 분리하는 것이다.
DHCP가 정상적으로 주소를 할당하더라도 Gateway, DNS, 라우팅, 방화벽 중 하나에 문제가 있으면 실제 서비스 접속은 실패할 수 있다.
따라서 DHCP 장애를 해결한 뒤에는 IP 주소, 라우팅 테이블, DNS 설정, 실제 서비스 통신까지 확인해야 한다.
마무리
이번 편에서는 DHCP의 역할과 DORA 과정, DHCP 패킷 분석, Lease Time, DHCP Relay, Linux 기반 장애 진단 방법을 살펴보았다.
시스템 엔지니어는 DHCP 서버가 실행 중인지 확인하는 것만으로 장애 분석을 끝내서는 안 된다.
클라이언트에서 Discover가 발생하는지, 서버가 Offer를 전송하는지, Request와 ACK가 정상적으로 오가는지 확인해야 한다. 이후 할당된 IP 주소와 Gateway, DNS 설정이 올바른지 검증해야 한다.
이러한 과정을 이해하면 신규 서버 구축, 가상 머신 네트워크 연결, 사내 PC의 IP 할당 실패, 특정 VLAN의 네트워크 장애 등을 보다 체계적으로 분석할 수 있다.
다음 편에서는 HTTP와 HTTPS의 동작 원리를 살펴본다.
브라우저가 웹 서버에 접속할 때 어떤 요청과 응답이 오가는지, HTTP 상태 코드와 TCP 연결은 어떤 관계인지, HTTPS 연결 실패 시 curl, ss, tcpdump로 어떻게 원인을 분석하는지 실전 중심으로 알아보겠다.
다음 편은 **「시스템 엔지니어를 위한 네트워크 13편 — HTTP와 HTTPS 동작 원리 및 Linux 실전 장애 분석」**입니다. DNS 조회부터 TCP 연결, HTTP 요청·응답, HTTPS 접속 실패까지 실제 웹 서비스 장애를 분석하는 흐름으로 이어가면 됩니다.
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.