2台のコンピュータがイーサネット経由で直接接続されています。 1つはDHCPサーバーとして機能し、もう1つはクライアントとして機能します。
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 タイプのルートを自動的に追加します。