Як клієнти DHCP знають, кого з декількох DHCPOFFERS прийняти?

Уявіть, у нас є мережа, як на малюнку. Шість хостів на одній шарі 2 мережі, без VLAN. Мережа повинна бути сегментована на дві підмережі, з одним сервером DHCP. Сервери DHCP мають фіксовану IP-адресу, тому вони, очевидно, знають, до якої підмережі вони належать.

Потім підключаються нові клієнти. Вони нічого не знають про те, в якій підмережі вони повинні знаходитися, і надсилають DHCPDISCOVER на Ethernet- трансляцію 255.255.255.255, тож вона переходить на обидва сервери DHCP. Обидва сервери відповідають на пропозицію. Тепер ось моє запитання: як клієнт знає, якого DHCPOFFER він повинен прийняти?

networking dhcp

— Майкл Німанд
джерело

Порівняйте це питання та відповіді там.

— Каміль Маціоровський

Ось ще одне пов'язане питання .

— kasperd

"ефірна мережа 255.255.255.255" - Це IP широкомовна адреса для локальної мережі, а не адреса Ethernet. Початкові повідомлення DHCP DISCOVER також мають велику ймовірність використовувати адресу ефірної трансляції ff: ff: ff: ff: ff: ff, але це насправді не те саме.

— ilkkachu

Відповіді:

Найпростіша відповідь - перший прийшов першим.

Якщо у вас було декілька VLAN, а 10.10.10.0/24 був інший VLAN до 10.10.20.0/24 - трансляція не переходитиме через VLAN.

Якщо сервер DHCP знаходився на окремій VLAN для клієнтів, iphelper на інтерфейсі маршрутизації між vlans спрямовував би мовлення на правильне місце.

У вашому сценарії, коли у вас є одна окрема мережа в межах однієї VLAN (або її відсутність), яка обслуговує різні підмережі - це гонка.

DHCP Обслуговується за допомогою наступних транзакцій:

Відкриття DHCP (DHCPDISCOVER) - клієнтська трансляція - "Чи є там сервер DHCP?"
Пропозиція DHCP (DHCPOFFER) - Сервер для клієнта - "Так, я тут і доступний!"
Запит DHCP (DHCPREQUEST) - Клієнт на сервер "Чудово, чи можу я отримати адресу?"
Підтвердження DHCP (DHCPACK) - сервер до клієнта "Звичайно, ось IP-адреса, маска, шлюз, деякі сервери DNS / WINS, сервер часу та всі інші речі, налаштовані для вашої сфери"

Все це відбувається на портах UDP 67 для сервера та 68 для клієнта.

Як тільки буде досягнуто крок 2 - клієнт перестане "слухати" відповіді інших серверів DHCP - його задовольняє робота з першим сервером, щоб приділити йому деяку увагу.

Як зауваження - насправді є добре відома серія атак DoS (Denial of Service), які зловживають цим правом. Зловмисник підключає пристрій, який відповідає і відправляє пакети DHCPOFFER, а потім не надсилає DHCPACK, коли його запитують ... знову і знову і знову. Існує також інша DoS-атака, коли "фальшиві" сервери DHCP пропонують адреси, які неможливо перенаправити, або конфліктують з іншими IP-адресами, які нюхають, щоб возитися з мережами.

— Fazer87
джерело

І тому коротка відповідь на "Але тоді як я запускаю кілька підмереж на одному сегменті" Шару-2 "?" це " Ви не робите ". (Так, є способи, але це не те, що вам слід робити. Один шар-2 домен = одна підмережа.)

— user1686

Дякую, хлопці, що справді натиснули на мене. Я завжди цікавився, як це можливо, але це просто не так. Тож відбираємо: перемикач маршрутизатора / шару 3 між підмережами або сегментом з VLAN, я прав?

— Майкл Німанд

Загалом, так, вам потрібні або VLAN, або фізична сегментація. Спільний доступ до домену L2 можливий лише в тому випадку, якщо обидва ваших DHCP-сервери обмежують обробку "відомих" клієнтів (наприклад, за списком "статичної оренди" з дозволеними MAC-адресами).

— користувач1686

Я думаю, ви могли б дати кожному серверу DHCP білий список MAC-адрес і контролювати, який клієнт отримує адресу, з якого сервера таким чином.

— Даррен

@grawity, ви можете легко запустити кілька підмереж IP на одному сегменті шару-2, якщо підмережі рівні, і вам не байдуже, який клієнт отримує адресу, з якої підмережі. У вас просто один сервер DHCP, який дає адреси обох блоків, і один маршрутизатор, який виступає шлюзом для обох блоків (з адресою в кожному). Зроблено. Сказати просто "ти не робиш" - це неправильно.

— ilkkachu

Існуючий відповідь від @ Fazer87 в загальних рисах правильно на практиці , і я рекомендую upvoting і прийняти його. Ця відповідь вивчає незначну деталь трохи точніше.

Обидва сервери DHCP можуть відповісти повідомленням DHCPOffer.

Клієнт DHCP може приймати їх на основі "першого приходу, першої подачі". Однак застосовувати такий підхід не потрібно.

RFC2131 вказує:

Клієнт отримує одне або більше повідомлень DHCPOFFER від одного або декількох серверів. Клієнт може вирішити почекати декількох відповідей. Клієнт вибирає один сервер, з якого запитувати параметри конфігурації, виходячи з параметрів конфігурації, запропонованих у повідомленнях DHCPOFFER.

Отже, якщо другий сервер DHCP запропонував довше бронювати IP-адресу або запропонував сервер часу, коли інший цього не зробив, або, можливо, було користувальницьке поле, яке клієнт запрограмував на вибір, він може прийняти другу пропозицію.

Як правило, підхід "перший прийшов, перший сервіс" збирається отримати вам пропозицію, яка не проходила через кілька перестрибувань на різних пристроях (ретрансляція BOOTP), тому це хороший протокол, який слід дотримуватися, якщо у вас немає підстав для турботи.

Я був в одному проекті, де користувацький пристрій віддав перевагу DHCPOffer, який включав TFTP-сервер, де можна було знайти оновлену прошивку.

— Відмінність
джерело

... або якщо один сервер запропонував адресу, яку клієнт раніше використовував і хотів зберегти

— ilkkachu

@ilkkachu: Так, теоретично, але існують кращі механізми для цього (як поновлення бронювання до закінчення терміну дії зі старим сервером DHCP, так і надсилання DHCPDiscovery із запитом старої IP-адреси), тому навряд чи це стане в нагоді на практиці.

— Відмінне мислення