그림과 같은 네트워크가 있다고 상상해보십시오. 하나의 레이어 2 네트워크에 6 개의 호스트가 있으며 VLAN이 없습니다. 네트워크는 각각 하나의 DHCP 서버와 함께 두 개의 서브넷으로 분할됩니다. DHCP 서버에는 고정 IP 주소가 있으므로 어떤 서브넷에 속하는지 알 수 있습니다.
그런 다음 새 클라이언트가 연결됩니다. 어떤 서브넷에 있어야하는지 알지 못하고 DHCPDISCOVER를 이더넷 브로드 캐스트 255.255.255.255로 전송하므로 두 DHCP 서버로 이동합니다. 두 서버 모두 오퍼로 응답합니다. 이제 내 질문은 다음과 같습니다. 클라이언트는 어떤 DHCPOFFER를 받아 들여야하는지 어떻게 알 수 있습니까?
답변
가장 간단한 답변-먼저 제공됩니다.
여러 개의 VLAN이 있고 10.10.10.0/24가 10.10.20.0/24와 다른 VLAN에있는 경우 브로드 캐스트는 VLAN을 통과하지 않습니다.
DHCP 서버가 클라이언트에 대해 별도의 VLAN에있는 경우 VLAN 간 라우팅 인터페이스의 iphelper는 브로드 캐스트를 올바른 위치로 보냅니다.
동일한 VLAN 내에 서로 다른 서브넷을 제공하는 두 개의 별도 네트워크가있는 시나리오 (레이스).
DHCP 다음 트랜잭션을 사용합니다.
- DHCP 검색 (DHCPDISCOVER)-클라이언트 브로드 캐스트- “DHCP 서버가 있습니까?”
- DHCP Offer (DHCPOFFER)-서버-클라이언트- “예, 여기 있습니다!”
- DHCP 요청 (DHCPREQUEST)-클라이언트와 서버 간 “멋지네요, 주소를 알려주시겠습니까?”
- DHCP 승인 (DHCPACK)-서버-클라이언트 “여기, IP, 마스크, 게이트웨이, 일부 DNS / WINS 서버, 시간 서버 및 범위에 맞게 구성된 다른 모든 것이 있습니다”
이 모든 것은 서버용 UDP 포트 67 및 클라이언트 용 68에서 발생합니다.
2 단계에 도달하자마자 클라이언트는 다른 DHCP 서버 응답에 대한 “청취”를 중지합니다. 첫 번째 서버를 처리하여주의를 기울입니다.
참고로 실제로이 권리를 남용하는 잘 알려진 일련의 DoS (Denial of Service) 공격이 있습니다. 공격자는 DHCPOFFER 패킷을 응답하고 전송하는 장치를 연결 한 다음 요청이있을 때 DHCPACK을 반복해서 보내지 않습니다. “가짜”DHCP 서버가 라우팅 할 수 없거나 네트워크를 망칠 수있는 다른 IP와 충돌하는 주소를 제공하는 다른 DoS 공격도 있습니다.
답변
@ Fazer87 의 기존 답변 은 실제로 정확하며 상향 조정하고 수락하는 것이 좋습니다. 이 답변은 사소한 세부 사항을 좀 더 정확하게 탐구합니다.
두 DHCP 서버 모두 DHCPOffer 메시지로 응답 할 수 있습니다.
DHCP 클라이언트는 “선착순”으로 수락 할 수 있습니다. 그러나이 방법을 사용할 필요는 없습니다.
RFC2131 은 다음을 지정합니다.
클라이언트는 하나 이상의 서버에서 하나 이상의 DHCPOFFER 메시지를받습니다. 클라이언트는 여러 응답을 기다리도록 선택할 수 있습니다. 클라이언트는 DHCPOFFER 메시지에 제공된 구성 매개 변수를 기반으로 구성 매개 변수를 요청할 서버를 하나 선택합니다.
따라서 두 번째 DHCP 서버가 더 긴 IP 주소 예약을 제공했거나 다른 서버가 클라이언트가 선호하지 않도록 프로그래밍 된 사용자 지정 필드를 갖지 않았거나 시간 서버를 제공 한 경우 두 번째 제안을 수락 할 수 있습니다.
일반적으로 “선착순”접근 방식은 여러 장치 (BOOTP 재방송)에서 여러 번의 홉을 거치지 않은 오퍼를 제공하므로 관심이없는 경우 따라야하는 좋은 프로토콜입니다.
나는 사용자 정의 장치가 업데이트 된 펌웨어를 찾을 수있는 TFTP 서버가 포함 된 DHCPOffer를 선호하는 한 프로젝트에있었습니다.