랜 케이블의 링크 표시가 켜져도 IP 주소를 받지 못할 수 있습니다. 이때는 단말이 요청을 보냈는지, 서버가 받았는지, 응답이 돌아왔는지를 같은 교환으로 연결합니다. 스위치나 라우터 이름보다 마지막으로 확인된 경계가 다음 점검을 결정합니다.
대상은 DHCPv4로 주소를 받는 관리 가능한 LAN입니다. 고정 IP, IPv6 주소 설정, 인증에 실패한 무선 접속은 별도 절차가 필요합니다. 이미 업무 중인 단말의 임대를 임의로 해제하지 말고 승인된 시험 단말에서 관측합니다.
1. 단말에서 주소와 연결 상태를 먼저 기록합니다.
Windows에서는 ipconfig /all로 해당 어댑터의 DHCP 사용 여부, IPv4, 서브넷 마스크, 게이트웨이, DHCP 서버와 DNS를 확인할 수 있습니다. Microsoft 명령 안내의 표시 항목을 참고하되 전체 출력을 공개할 때 호스트명·물리 주소·내부 주소를 가립니다. 읽기 전용 확인부터 시작하고 갱신 명령은 영향이 허용될 때만 사용합니다.
| 관찰 | 다음 확인 | 아직 단정할 수 없는 것 |
|---|---|---|
| 링크 자체가 없음 | 전원·포트 관리 상태·패치코드·양끝 연결 | DHCP 서버 장애. |
| 주소가 기대한 대역과 다름 | 연결 어댑터·SSID·VLAN·DHCP 서버 ID | 다른 주소라는 이유만으로 해킹이나 장비 고장. |
| 주소를 받지 못함 | 요청·응답과 관측 지점 | 서버가 꺼졌는지, 요청 경로가 끊겼는지. |
| 주소는 정상인데 서비스 실패 | 게이트웨이·DNS·대상 서비스 경로 | DHCP 성공이 모든 통신의 정상이라는 판단. |
2. 요청이 지나갈 경로를 짧게 그립니다.
L2 스위치는 VLAN 안에서 프레임을 전달하고, 다른 네트워크로 가는 경로는 라우터 또는 L3 기능을 가진 장비가 처리합니다. DHCP 서버가 다른 서브넷에 있으면 구성에 따라 릴레이가 요청과 응답을 전달합니다. RFC 2131 §3.1은 초기 주소 할당 교환과 릴레이 처리를 설명합니다.
시험 PC → 액세스 포트/VLAN → 스위치 간 링크 → DHCP 릴레이 → DHCP 서버를 적습니다. 같은 VLAN의 서버라면 릴레이 단계는 없습니다. 장비를 추정해 그리지 말고 포트 설정과 담당자의 구성 자료로 확인합니다.
| 경계 | 필요한 관찰 | 자료를 못 얻으면 |
|---|---|---|
| 액세스 포트 | 시험 MAC이 학습된 포트·VLAN, 링크 상태 | 실제 연결 포트부터 담당자에게 확인. |
| 스위치 간 링크 | 필요한 VLAN의 양쪽 허용·태그 상태 | 트렁크 정상 대신 양쪽 설정 미확인으로 기록. |
| 릴레이 | 수신 VLAN·인터페이스 주소·서버 대상 | 릴레이 사용 여부부터 확인. |
| 서버 | 요청 수신·스코프·정책·응답 결과 | 서버 담당자에게 시험 시각·식별자 전달. |
3. 같은 교환의 Discover·Offer·Request·ACK를 대조합니다.
초기 주소 할당에서는 Discover, Offer, Request, ACK가 대표 흐름입니다. 갱신이나 이전 주소 재사용에는 다른 흐름도 있으므로 모든 캡처에 네 메시지가 반드시 보여야 하는 것은 아닙니다. RFC 2131은 트랜잭션 ID xid와 클라이언트 식별 정보를 설명합니다. 시각만 비슷한 다른 단말의 패킷을 섞지 않습니다.
다음 주소·VLAN·XID·관찰 결과는 경로를 설명하는 가상 예제입니다. 실제 캡처가 아닙니다. 시험 PC는 VLAN 20, 릴레이는 192.168.20.1, DHCP 서버는 192.168.50.10이라고 둡니다.
합성 필드 기록에서 같은 교환을 찾습니다.
아래는 패킷에서 확인할 필드를 사람이 작성한 합성 기록입니다. 실제 캡처 출력이나 Wireshark 실행 결과가 아니며, Wireshark로 직접 열 수 있는 패킷 파일도 아닙니다. 상대 시각과 관측 위치도 설명을 위해 정했습니다. VLAN 20은 이 예제의 구성 조건이지 IP 주소의 숫자에서 알아낸 값이 아닙니다.
먼저 필드의 의미를 맞춥니다. RFC 2131의 메시지 형식과 필드 설명에 따라 xid는 요청·응답을 대조할 트랜잭션 ID, chaddr는 클라이언트 하드웨어 주소, giaddr는 릴레이 주소입니다. yiaddr는 이 예제의 Offer에서 클라이언트에게 제안하는 주소입니다. 제안 주소가 보인다는 것과 PC가 그 주소를 적용했다는 것은 다릅니다.
아래 R1~R5는 모두 xid=0x1A2B3C4D, chaddr=02:00:00:00:20:01로 놓습니다. Ethernet 단말의 MAC을 chaddr로 대조하는 예제이며, 실제 자료에서는 클라이언트 식별자 옵션이 있으면 그 값과 시간·인터페이스도 함께 확인합니다. 메시지 종류는 RFC 2132 §9.6의 Option 53에서 Discover가 1, Offer가 2입니다.
| 기록·상대 시각 | 관측 위치·방향 | 종류·Option 53 | giaddr | yiaddr |
|---|---|---|---|---|
| R1 · 0.000초 | PC NIC 송신 | Discover · 1 | 0.0.0.0 | 0.0.0.0 |
| R2 · 0.001초 | 릴레이 단말 측 인터페이스 수신 | Discover · 1 | 0.0.0.0 | 0.0.0.0 |
| R3 · 0.004초 | 서버 NIC 수신 | Discover · 1 | 192.168.20.1 | 0.0.0.0 |
| R4 · 0.007초 | 서버 NIC 송신 | Offer · 2 | 192.168.20.1 | 192.168.20.101 |
| R5 · 0.009초 | 릴레이 서버 측 인터페이스 수신 | Offer · 2 | 192.168.20.1 | 192.168.20.101 |
NIC는 해당 장비의 네트워크 인터페이스입니다. R2는 릴레이가 단말의 요청을 받은 위치이고, R5는 서버의 응답을 받은 위치입니다. 같은 릴레이 장비라도 인터페이스와 방향을 생략하면 요청을 받았다는 사실과 단말에게 응답을 내보냈다는 사실을 혼동할 수 있습니다.
같은 XID여도 다른 단말인 반례를 하나 더 놓습니다. R6은 0.012초 / 서버 NIC 수신 / Discover(1) / xid=0x1A2B3C4D / chaddr=02:00:00:00:20:02인 합성 기록입니다. XID만 검색하면 R6도 섞이지만, 이 예제에서 찾는 PC의 chaddr와 다르므로 R1~R5에 연결하지 않습니다. RFC 2131 §4.1도 다른 클라이언트와 XID가 겹칠 가능성을 줄이도록 설명하며, XID를 장비 고유 번호로 정의하지 않습니다.
실제 캡처를 Wireshark에서 열어 확인할 때는 표시 필터에 다음 형식을 사용할 수 있습니다. 캡처 필터나 PowerShell 명령이 아닙니다. 예제의 XID와 MAC은 자신의 허용된 자료에서 확인한 값으로 바꿉니다.
dhcp.id == 0x1a2b3c4d && dhcp.hw.mac_addr == 02:00:00:00:20:01같은 조건에서 Discover만 보려면 끝에 && dhcp.option.dhcp == 1, Offer만 보려면 && dhcp.option.dhcp == 2를 붙입니다. Wireshark 공식 DHCP 필터 문서에서 이 세 필드의 지원 범위를 3.0.0~4.6.8로 확인했습니다(2026-09-22). 필터는 확보한 파일의 표시 범위를 좁힐 뿐, 수집하지 못한 인터페이스나 시간을 채워 주지 않습니다.
필드 기록을 관측표로 옮깁니다.
R1R3은 다음 표의 Discover 행, R4R5는 Offer 행으로 옮깁니다. 이 합성 기록에는 PC가 받은 Offer, 해당 교환의 Request·ACK를 넣지 않았습니다. 예제에 기록이 없다는 이유로 실제 망에서 패킷이 사라졌다고 결론 내릴 수는 없습니다. 확보한 자료가 없는 칸은 미확인으로 남깁니다.
| 메시지 | 단말 쪽 관측 | 릴레이·서버 쪽 관측 | 현재 판단 |
|---|---|---|---|
Discover, XID 0x1A2B3C4D | R1에서 PC 송신 | R2에서 릴레이 수신, R3에서 서버 수신 | 예제상 서버까지 요청 도착을 연결함. |
| Offer, 같은 XID | PC 수신 기록 미확인 | R4에서 192.168.20.101 제안, R5에서 릴레이 수신 | 예제상 서버 응답은 있음. 반환 경계 추가 확인. |
| Request | 같은 PC 교환에서 미확인 | 서버에서도 미확인 | Offer가 PC에 도착했는지부터 확인. |
| ACK | 미확인 | 미확인 | 주소 할당 완료를 확인하지 못함. |
이 상태의 다음 관측점은 릴레이의 클라이언트 방향 송신과 액세스 VLAN 쪽입니다. VLAN 태그·허용 목록, 보안 정책과 캡처 조건을 확인합니다. 단말 캡처에 없다는 사실만으로 그 사이 스위치가 버렸다고 확정하지 않습니다. 미러링 누락, 캡처 필터와 드롭도 확인해야 합니다.
반대로 Discover가 서버에 도착했는데 서버가 주소를 제안하지 않는다면 스코프 잔여 주소, 서버 정책과 해당 요청의 로그를 봅니다. NAK가 있으면 응답 없음으로 묶지 않고 사유를 따로 남깁니다.
4. 마지막 증거에서 다음 관측을 정합니다.
위 DHCP 관측표에서 확인한 메시지와 위치를 기준으로 다음 시험 하나를 정합니다. Offer를 아직 보지 못했거나 주소가 할당되지 않았다면 그 상태를 그대로 남깁니다. 자료가 없는 항목을 정상으로 채우거나, 서로 다른 시각·VLAN에서 본 결과를 한 경로의 증거로 합치지 않습니다.
| 마지막 증거 | 다음 시험 하나 |
|---|---|
| 단말 요청을 확인하지 못함 | 시험 어댑터와 올바른 캡처 지점에서 송신 여부 확인. |
| 서버까지 요청만 도착 | 서버의 같은 XID 처리와 Offer·NAK·정책 로그 확인. |
| Offer 송신만 확인 | 반환 경로의 다음 관측점에서 같은 제안 확인. |
| ACK까지 단말 도착 | 실제 적용된 IP·프리픽스·게이트웨이·DNS와 임대 확인. |
| 주소 적용 후 업무만 실패 | 대상 이름 해석과 서비스 요청·응답 확인. |
ping 응답은 ICMP 경로의 관찰입니다. RFC 792의 Echo 교환이 성공해도 DNS나 업무 포트의 성공을 대신하지 않습니다.
5. 담당자에게 넘길 한 줄을 완성합니다.
시험 단말
____, 어댑터·MAC 식별____, 시각·시간대____. 액세스 포트/VLAN____, 릴레이____, DHCP 서버____. 같은 XID____에서 마지막으로 확인한 요청/응답과 위치____. 확인 못 한 경계____. 다음 관측 또는 요청할 로그____.
주소 할당이 복구되면 동일 단말·포트에서 설계한 값이 적용됐는지 확인하고 원래 업무를 다시 시험합니다. 선로 짝이 불명확하면 선로 식별 안내, 주소 이후 특정 서비스만 실패하면 허용 대상과 접근 경로 기록으로 이어갑니다.