우리는 고객의 일반 LAN과 케이블을 공유할 IoT 장치를 많이 보유하고 있습니다. 우리는 그것들이 논리적으로 분리되기를 원합니다. 일반 LAN이 198.162.xx를 사용하고 우리는 10.10.xx를 사용하고 싶다고 가정해 보겠습니다. 이러한 가젯은 정적 주소를 사용하는 것이 비실용적일 정도로 많습니다. LAN을 통해 고객의 장비와 통신할 필요는 없지만 이와 관련하여 완전히 독립적입니다.
LAN 자체(케이블 연결, 스위치 등)는 우리의 하드웨어가 아닙니다. 우리는 이를 관리하지 않으며 관리자의 기존 사용을 복잡하게 만들고 싶지 않습니다. VLAN을 사용하거나 기존 스위치가 VLAN을 지원할 것이라고 기대할 수 없으며 추가 하드웨어(예: 트렁크)를 추가할 수도 없습니다. 우리는 기존 케이블링 인프라를 활용하고 싶었습니다. 일반 LAN은 Windows 워크스테이션이 될 것이며 우리 장비는 GNU/Linux를 실행할 것입니다.
지금까지 동일한 LAN에 있는 여러 DHCP 서버에 대해 읽은 모든 내용은 a) "하지 마세요. 버그입니다." 또는 b) "예, 그들이 협력하고 로드 공유를 하고 있다면 괜찮습니다. 같은 논리입니다. 네트워크이며 클라이언트가 어느 서버에서 주소를 가져오는지는 중요하지 않습니다."
사용자 정의 옵션을 포함하여 dhcp 클라이언트에 사용할 수 있는 옵션이 많이 있는 것 같습니다. 클라이언트가 dhcp 서버의 주소 제안만 수락하고 다른 dhcp 서버의 주소 제안을 거부하거나 무시하도록 dhcp 서버(하드웨어)와 dhcp 클라이언트(또한 하드웨어)를 설정하는 방법이 있습니까?
구체적으로, dhcp 클라이언트가 "옵션 dhcp-server-identifier"를 인식하고 시행하도록 하는 방법이 있습니까? 이것이 가능해야 할 것 같지만 예제나 토론을 찾지 못했습니다.
답변1
예, 기술적으로는 가능합니다. DHCP 서버는 새로운 옵션을 정의할 수 있으며, DHCP 클라이언트는 이러한 옵션이 포함되지 않은 제안을 거부하도록 설정할 수 있습니다( ISC용 클라이언트 require의 설명 참조).dhclient.conf
그러나 네트워크의 모든 DHCP 서버와 클라이언트를 제어할 수는 없기 때문에 이는 좋지 않은 생각입니다. 기본 DHCP 서버는 클라이언트에 문제를 일으키지 않을 수 있지만, 자신의 DHCP 서버가 작동하지 않는 기존 네트워크 호스트 주소를 사용하여 다른 클라이언트의 요청에 응답하는 것을 막을 수는 없습니다.