Dhcpd, работающий в Linux, получает dhcp-запрос через dhcrelay, запущенный на другом удаленном компьютере.
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]
Он соответствует подсети и отправляет ответ. Однако ответ не поступает на запрашивающий внешний IP-адрес dhcrelay (192.168.0.81). Вместо этого он переходит на IP-адрес внутреннего интерфейса машины, на которой запущен dhcrelay. И я думаю, из-за того, что на этой удаленной машине запущен 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-адрес, присутствующий в IP-адресе шлюза (giaddr), для отправки ответов, как указано в спецификациях. Как правило, DHCP предпочитает использовать адреса, представленные в полезных данных DHCP / BOOTP, чем адреса в заголовках IP и MAC.
IP-адрес шлюза должен быть адресом интерфейса, подключенного к клиенту; так что, если у реле есть несколько интерфейсов, подключенных к клиентам, он может просто отправить IP-адрес интерфейса, на котором был получен запрос, и сервер ответит на этот IP, чтобы реле могло знать, на каком интерфейсе должен быть ответ. передано. Это позволяет DHCP-ретранслятору не иметь состояния.
Если вы отклоняете его, значит, проблема с вашим реле. Может быть, проблема с маршрутизацией?
Обновить:
ОДНАКО, я удалил маршрут на сервере dhcpd, чтобы добраться до подсети 172.16.17.x.
Во многих отношениях это неверно. После настройки клиентов через DHCP они могут связываться с DHCP-сервером напрямую с помощью одноадресной рассылки, без использования реле. Если DHCP-сервер не может ответить на эти запросы, могут произойти неприятные вещи, например, клиент не может продлить или удалить свою аренду.
Потому что нет смысла добавлять маршруты в подсеть, для которой мы распределяем IP.
Вот только вот как работает DHCP ...