두 대의 컴퓨터 가 이더넷을 통해 직접 연결되어 있습니다. 하나는 DHCP 서버 역할을 하고 다른 하나는 클라이언트 역할을 합니다.
interface eth0
lease_file /var/lib/udhcpd/udhcpd.leases
remaining no
start 192.168.1.2
end 192.168.1.16
option dns 9.9.9.9
option dns 192.168.1.1
option subnet 255.255.255.255
option router 192.168.1.1
option domain local
option lease 864000
옵션을 혼합하고 일치시키고 옵션 없이도 시도했지만 결과는 거의 동일했습니다. 여전히 두 컴퓨터 모두에서 수동으로 경로를 추가해야 했습니다.
내가 예상하는 동작은 udhcpd가 PC_0에서 실행되고, udhcpc가 PC_1에서 실행되고, PC_1이 dhcp를 통해 PC_0에서 주소와 경로를 가져오고 서로 ping할 수 있으며 그 반대로도 가능하다는 것입니다. 하지만 ip route add remote_ip/subnet_mask via local_ip dev eth0연결할 때마다 이 작업을 수행해야 하므로 그렇지 않습니다 . 또한 udhcpd를 실행하는 PC_0에 IP 주소를 수동으로 할당해야 했습니다. 어떻게 해결할 수 있나요?
답변1
다음을 지정합니다.
option subnet 255.255.255.255
즉, 클라이언트가 주소를 생성하면 /255.255.255.255 넷마스크(CIDR 표기법으로는 /32)를 갖게 됩니다. 예를 들어, 192.168.1.10/32를 임대하는 LAN에 호스트가 몇 개 있습니까? 가지다단 하나. 호스트의 경우 이러한 LAN에 도달하기 위해 경로를 추가할 필요가 없습니다. 이것이 Linux 커널이 자동 LAN 경로를 추가하지 않는 이유입니다(일반적으로 ip route다음과 같은 명령을 사용하여 표시됨 proto kernel scope link).
192.168.1.1(라우터의 가장 낮은 주소가 있음)부터 192.168.1.16(범위 끝: 가장 높은 주소)까지 모든 범위가 포함될 수 있도록 더 넓은 넷마스크를 게시하여 이 문제를 해결하십시오. /28은 192.168.1.0에서 192.168.1.15 사이이므로 충분하지 않습니다. 따라서 /27 <=> 255.255.255.224로 충분하거나 일반적인 /24(255.255.255.0)를 선택할 수 있습니다. 이 정보가 여기에 노출되지 않더라도 DHCP 서버가 인터넷의 라우터 역할을 할 수도 있다는 점(예: 9.9.9.9에 도달하는 DNS 서버)을 고려하면 더 넓은 범위는 다른 것과 충돌할 위험이 있습니다. 상대방. 이는 DHCP 클라이언트의 구성 문제를 해결합니다.
서버 측에서는 일치하는 넷마스크를 구성해야 합니다. 따라서 192.168.1.1과 192.168.1.1/27과 192.168.1.1/24 사이에서 위에서 선택한 동일한 넷마스크를 사용하십시오. 동일한 일이 발생합니다. 커널은 proto kernel해당 주소로 구성된 LAN에 대해 LAN 유형의 경로를 자동으로 추가합니다.