나는 전체 내용을 읽고 RFC 3315IPv6 주소를 요청하기 위해 스푸핑된 노드를 생성하려고 했습니다. (연습용으로만)
지금은 wide-dhcpv6-server(DHCPv6 서버)가 있는 Ubuntu, 사용 가능한 DHCPv6 릴레이 에이전트가 있는 하나의 Cisco 2811 라우터, 두 개의 노드가 있습니다. 하나는 wide-dhcpv6-client(dhcp 클라이언트 프로그램)가 있고 하나는 시도 중입니다. 첫 번째 메시지를 생성합니다.
wide-dhcpv6-client가 있는 노드는 요청 메시지를 생성하고 라우터 릴레이는 메시지를 받아 서버(다른 서브넷에 있음)로 전달하며 전체 프로세스(요청, 광고, 요청 및 응답)가 발생합니다.
두 번째 노드는 DELL OUI의 MAC 주소를 사용하여 스푸핑된 요청 메시지를 생성합니다. 저는 네트워크의 새로운 노드에 대한 프로세스를 복제하려고 합니다. 서버에서 Adverstiment 메시지를 얻으려고 합니다.
지금까지 이것은 유효한 클라이언트에 의해 생성된(및 Wireshark를 사용하여 캡처된) 메시지입니다.
fe80::221:70ff:fe1c:9b79 ff02::1:2 DHCPv6 112 Solicit XID: 0xfc828 CID: 0001000119c50e640021701c9b79
그리고 이것은 스푸핑된 노드에 의한 것입니다:
fe80::26b6:fdff:fee5:d276 ff02::1:2 DHCPv6 112 Solicit XID: 0x15341f CID: 0001000119c6616e24b6fde5d276
wide-dhcpv6-client 프로그램을 사용하여 노드에 의해 생성된 메시지와 스푸핑된 메시지는 DUID, 링크 계층 주소 및 트랜잭션 ID를 제외한 거의 모든 항목에서 동일한 것처럼 보이지만 이는 정확합니다(처음 두 개는 노드를 식별하기 위한 것입니다). future와 요청 메시지의 두 번째 메시지는 100% 무작위여야 하지만 다른 3개 메시지의 기본이 됩니다.
어디서 단서를 찾을 수 있을지 아시나요?
PS 저는 이미 DHCPv6 서버를 동일한 서브넷으로 전환하고 릴레이 에이전트를 제거하려고 시도했습니다.
답변1
스푸핑된 노드가 존재하지 않습니다. 두 번째 메시지(서버 광고)는 유니캐스트입니다. 즉, 메시지를 보내기 전에 응답을 받지 못한 NDP 이웃 요청이 있으며 같은 이유로 릴레이 에이전트(또는 켜져 있을 때 서버)가 있음을 의미합니다. 동일한 서브넷) 절대 두 번째 메시지를 보내지 마세요.
즉, IPv6 호스트를 스푸핑하려면 NDP 메시지에도 응답할 준비가 되어 있어야 합니다(또는 응답하지 마십시오).