對來自中繼的請求的回復轉到中繼的內部 IP，而不是原始請求的源 IP
在 Linux 上執行的 dhcpd 通過執行在其他遠端機器上的 dhcrelay 獲取 dhcp 請求。
Oct 6 10:09:46 2012 dhcpd: DHCPDISCOVER from 00:1e:68:06:eb:37 (oguz-U300) via 172.16.17.81 tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 10:35:01.112500 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 192.168.0.81.67 > 192.168.0.1.67: BOOTP/DHCP, Request from 00:1e:68:06:eb:37, length: 300, hops:1, xid:0xe378fc7e, flags: [none] (0x0000) Gateway IP: 172.16.17.81 Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]它匹配子網並發送回复。但是，回復不會發送到請求的 dhcrelay 外部 IP（192.168.0.81）。相反，它轉到執行 dhcrelay 的機器的內部介面 IP。而且我認為是因為這台遠端機器執行 dhcrelay 或 dhcrealy 本身丟棄了數據包。
Oct 6 10:09:46 2012 dhcpd: DHCPOFFER on 172.16.17.11 to 00:1e:68:06:eb:37 (oguz-U300) via 172.16.17.81 10:35:02.050108 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 192.168.0.1.67 > 172.16.17.81.67: BOOTP/DHCP, Reply, length: 300, hops:1, xid:0xe378fc7e, flags: [none] (0x0000) Your IP: 172.16.17.11 Gateway IP: 172.16.17.81 Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]這是正常行為嗎？
機器執行dhcrelay：
eth1(ext) Link encap:Ethernet HWaddr 00:90:0B:21:43:F4 inet addr:192.168.0.81 Bcast:192.168.0.255 Mask:255.255.255.0 eth2(int) Link encap:Ethernet HWaddr 00:90:0B:21:43:F5 inet addr:172.16.17.81 Bcast:172.16.17.255 Mask:255.255.255.0 3582 ? Ss 0:00 /usr/sbin/dhcrelay -i eth2 192.168.0.1執行 dhcpd 的機器：
eth1 Link encap:Ethernet HWaddr 00:90:0B:23:97:D1 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 option domain-name "test.com"; option subnet-mask 255.255.255.0; authoritative; ignore client-updates; ddns-update-style ad-hoc; default-lease-time 86400; max-lease-time 86400; subnet 192.168.0.0 netmask 255.255.255.0 { range 192.168.0.135 192.168.0.169; option broadcast-address 192.168.0.255; option domain-name-servers 192.168.0.1; option domain-name "test.com"; option routers 192.168.0.1; } subnet 172.16.17.0 netmask 255.255.255.0 { local-address 192.168.0.1; server-identifier 192.168.0.1; range 172.16.17.10 172.16.17.11; option broadcast-address 172.16.17.255; option routers 172.16.17.81; }（我放了本地地址和伺服器標識符。但這無濟於事）
問候，
——奧古茲·耶爾馬茲
更新：
發現第一個問題。我只在監聽內部介面上配置了 dhcrelay。似乎（當然）也應該聽取外部介面的回复。數據包的目的地似乎並不重要。dhrelay 會將其轉發到內部網路。
但是，我已經刪除了 dhcpd 伺服器上到達 172.16.17.x 子網的路由。它再次嘗試向 172.16.17.81 發送回复。因為它不知道它從預設網關發送到網際網路的路由。
eth0: IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 328) 192.168.1.2.67 > 172.16.17.81.67: BOOTP/DHCP, Reply, length: 300, hops:1, xid:0x32830125, secs:3, flags: [none] (0x0000) eth0: Your IP: 172.16.17.11 eth0: Gateway IP: 172.16.17.81 eth0: Client Ethernet Address: 00:1e:68:06:eb:37 [|bootp]如何強制 dhcpd 強制向請求 IP 發送回复？因為，將路由添加到我們為其分配 IP 的子網並沒有多大意義。
網際網路 - dhcpd - 192.168.0.1 - SOMENET - 192.168.0.81 - dhcrelay - 172.16.17.0/24
192.168.0.1 沒有通往 172.16.17.0 的路由，也沒有直接連接到該網路的介面。
這很正常。DHCP 伺服器將使用網關 IP (giaddr) 中的 IP 地址來發送響應，如規範中所述。通常，DHCP 更喜歡使用 DHCP/BOOTP 有效負載中的地址，而不是 IP 和 MAC 標頭中的地址。
網關IP地址必須是連接客戶端的介面地址；這樣，如果中繼有多個介面連接到客戶端，那麼它可以簡單地發送接收請求的介面的 IP 地址，伺服器將響應該 IP，因此中繼可以知道答案必須在哪個介面上轉達了。這允許 DHCP 中繼是無狀態的。
如果您中繼拒絕它，那麼您的中繼有問題。可能是路由問題？
更新：
但是，我已經刪除了 dhcpd 伺服器上到達 172.16.17.x 子網的路由。
這在很多方面都是錯誤的。一旦客戶端通過 DHCP 進行配置，它們就可以通過單播直接聯繫 DHCP 伺服器，而無需使用中繼。如果 DHCP 伺服器無法回答這些查詢，則可能會發生不好的事情，例如客戶端無法延長或刪除他們的租約。
因為，將路由添加到我們為其分配 IP 的子網並沒有多大意義。
除了這就是 DHCP 的工作方式……