DHCP 임대와 예약

주소가 있어도 설정이 완성된 것은 아닙니다

학생 단말을 추가할 때 IP만 적고 DNS와 게이트웨이를 빠뜨리면 같은 VLAN 안의 통신은 되지만 학교 웹 이름 조회가 실패할 수 있습니다. DHCP는 주소와 관련 설정을 함께 전달하는 역할을 합니다. 이번에는 기존 s1의 정적 주소를 임대로 바꾸고 ACK에 포함된 주소·마스크·라우터·DNS·임대 시간을 검사합니다. 주소표와 받은 옵션이 일치하는지 확인하는 것이 목표이며 서버에 설정 파일이 있다는 사실만으로 배포 성공을 보고하지 않습니다.

초기 임대의 네 메시지를 따라갑니다

DISCOVER는 사용할 설정을 찾는 요청이고 OFFER는 서버의 제안입니다. REQUEST로 선택한 제안을 요청하면 서버가 ACK로 확정된 설정을 전달합니다. DORA는 초기 임대를 읽기 위한 기억 도구입니다. 갱신에서는 항상 같은 네 메시지를 반복하는 것이 아니므로 캡처에 DISCOVER가 없다는 이유만으로 고장이라고 판단하지 않습니다. 제공 단일 클라이언트는 초기 흐름만 구현하므로 이번 관측과 실제 운영의 갱신을 구분합니다.

주소가 없는 단말이 보낼 수 있는 이유

단말은 초기 단계에서 자신의 IPv4 주소를 아직 갖지 않습니다. 이 실습에서는 브로드캐스트를 사용해 같은 학생 VLAN의 서버에 요청합니다. 서버 UDP 67과 클라이언트 UDP 68을 사용하고 요청의 트랜잭션 식별자와 단말 식별 정보로 응답을 대응시킵니다. 라우터가 있다고 다른 VLAN의 브로드캐스트를 그대로 전달하는 것은 아닙니다. 여러 VLAN에서 중앙 서버를 사용할 때는 해당 VLAN에서 직접 제공하거나 DHCP 릴레이를 설계해야 합니다.

풀은 배정 가능한 범위를 정합니다

학교 학생 대역은 10.20.10.0/24이고 풀은 10.20.10.100부터 10.20.10.120까지입니다. 네트워크 주소 .0과 브로드캐스트 .255를 단말에 배정하지 않습니다. 라우터 .1, 기존 학생 s2 .12, 다른 고정 장비의 주소도 동적 할당과 겹치지 않도록 제외합니다. 풀의 양 끝도 할당 범위에 포함되므로 .100과 .120을 경계 사례로 생각합니다. 실제 운영에서는 사용 중인 주소와 충돌 검사를 함께 해야 하며 이번 앱은 이를 구현하지 않습니다.

예약은 클라이언트와 주소의 대응입니다

예약은 특정 클라이언트 식별 정보에 정해진 주소를 제안하는 서버 규칙입니다. 단말에서 수동 주소를 적는 것과 다르게 DHCP 메시지로 설정을 받습니다. 제공 검사기는 s1의 실제 MAC을 읽어 client.json에 보존하고 .111을 예약합니다. 재구성 때 MAC이 달라질 수 있으므로 이전 실행의 문자열을 하드코딩하지 않습니다. 이 실습의 예약 주소는 풀 안에 있지만 실제 제품별로 풀 포함 여부와 중복 방지 규칙을 확인해 구성해야 합니다.

네 가지 옵션을 따로 확인합니다

ACK의 마스크는 255.255.255.0, 라우터는 10.20.10.1, DNS는 10.20.30.1, 임대 시간은 600초입니다. 게이트웨이는 현재 링크에서 도달해야 하며 DNS는 경로를 통해 다른 VLAN에 있어도 됩니다. 둘을 같은 IP로 강제할 이유는 없습니다. ACK를 받았지만 게이트웨이가 다른 대역이면 다음 홉을 설정할 수 없거나 통신이 실패합니다. DNS 주소만 잘못된 경우에는 IP를 직접 사용한 요청과 이름 요청의 결과가 달라질 수 있습니다.

서버 제안과 단말 적용을 나눕니다

서버는 메시지로 설정을 전달하고 클라이언트가 운영체제의 주소와 경로를 적용합니다. 제공 dhcp_client.py는 ACK를 읽은 뒤 s1의 eth0에 .111/24를 추가하고 기본 경로를 설정합니다. lease.json은 받은 값을 기록합니다. 호스트의 resolv.conf는 건드리지 않으며 DNS 옵션은 후속 dig의 대상에 사용합니다. 따라서 이 과제가 일반 데스크톱의 자동 DNS 설정까지 검증한다고 말하지 않습니다. 수신 설정과 시스템 적용 모두를 보는 습관이 필요합니다.

옛 정적 주소를 이력으로 남깁니다

앞 모듈의 addresses.csv에는 s1 .11이 적혀 있습니다. 이번 실행은 앞 모듈 회귀 검사를 먼저 끝낸 뒤 소유한 s1에서 그 주소를 제거하고 임대를 받습니다. .11과 .111이 동시에 남아 있으면 어떤 주소로 연결했는지 혼란이 생깁니다. 옛 표를 몰래 현재 상태로 표시하지 않고 입력 이력으로 보존합니다. 현재 상태는 lease.json의 임대와 ip -n bcnet-s1 -4 addr show dev eth0의 실측을 연결해 기록합니다.

설정 실수를 작은 검사로 찾습니다

DHCP starter의 gateway는 학생 대역 밖의 값입니다. services.json에서 gateway를 학생 VLAN의 .1로 고치고 python3 test_services.py를 실행합니다. 풀과 예약까지 전부 삭제해 오류를 숨기지 않습니다. PASS: gateway는 학교 주소표와 설정이 맞다는 뜻이며 실제 OFFER와 ACK는 Linux 검사에서 확인합니다. 검사 로그에서 pool과 reservation은 통과하는데 gateway만 실패하면 임대 범위 계산보다 전달 옵션부터 검토하는 것이 합리적입니다.

응답이 없는 경우를 좁힙니다

TimeoutError 또는 timed out은 클라이언트가 기다린 메시지를 얻지 못했다는 뜻입니다. 서버 프로세스가 시작됐는지, v10의 UDP 67에 묶였는지, s1이 같은 VLAN에 있는지 차례로 확인합니다. 다른 네임스페이스에서 도구를 실행하면 정상 서비스가 있어도 보이지 않습니다. 이번 브로드캐스트는 VLAN 10으로 제한됩니다. 아무 ACK도 없는 상태에서 DNS 레코드를 바꾸는 것은 임대 실패의 직접 해결이 아니므로 메시지 흐름부터 회복합니다.

임대 시간과 주소 유효성을 구분합니다

600초는 이번 ACK가 알려 주는 사용 시간입니다. 실제 클라이언트는 갱신 시점과 만료를 관리하고 갱신이 실패하면 정해진 상태 전이를 따릅니다. 제공 앱은 갱신·만료 제거·NAK 처리를 교육 범위에서 제외하며 실습 자체는 35초 서비스 수명 안에서 끝납니다. 따라서 600초가 지난 뒤의 재사용을 이 코드로 시험했다고 쓰지 않습니다. 임대 만료 뒤에도 계속 사용하는 주소는 중복 위험이 있으므로 운영 도구에서는 수명 관리가 필요합니다.

예약 없는 단말과 확장의 경계

제공 서버는 예약 MAC이 맞으면 .111, 다른 단일 클라이언트면 풀의 첫 주소 .100을 제안합니다. 복수 클라이언트에 대한 빈 주소 탐색과 영속 임대 저장은 구현하지 않습니다. 두 장비가 동시에 .100을 받는 상황을 허용할 운영 서버로 사용해서는 안 됩니다. 이번 제출물은 s1 한 대의 실제 교환을 증명합니다. 학교 전체로 확장할 때는 장비 수·예약 목록·풀 여유·서버 장애 시 임대 정책을 별도 설계 항목으로 남깁니다.

임대 성공 후에도 왕복을 확인합니다

새 주소 .111은 학생 /24에 속하므로 앞 모듈 server1의 10.20.10.0/24 응답 경로를 계속 사용할 수 있습니다. 서버에 .11/32만 적었다면 새 임대 주소로 응답하지 못할 수 있습니다. 주소를 바꾼 뒤 학교 DNS 조회와 웹 응답을 확인하는 이유가 이 경로 의존성입니다. 주소 수신 성공, 적용 성공, 실제 서비스 성공을 각각 기록합니다. 이번 미션에서는 services.csv의 DHCP 행과 DNS·HTTP 행이 서로 다른 근거를 나타냅니다.

임대 장애 보고의 완성 기준

보고서에는 사용한 VLAN, 단말 MAC, 트랜잭션 흐름, 배정 주소, 마스크, 게이트웨이, DNS, 임대 시간을 넣습니다. 재현 명령과 실패 단계가 있으면 다른 담당자가 이어서 확인할 수 있습니다. 주소 하나가 풀 안에 있다는 사실만 보고하지 않습니다. 잘못된 DNS를 받은 단말은 웹 이름만 실패할 수 있고 잘못된 마스크는 같은 망 판단부터 달라집니다. 어떤 옵션이 어떤 증상을 만들었는지 설명하는 것이 설정 값을 외우는 것보다 실무에서 도움이 됩니다.

기술 확인: DHCP 초기 메시지 교환의 공식 명세를 참고했습니다. 설명과 학교망 예제는 이 레슨의 과제에 맞춰 작성했습니다.