DHCP през VPN: да пренасяме ли широкомовното предаване или да го препращаме?

Нов лаптоп от другата страна на тунела не получава адрес, докато същият лаптоп работи в централата. Обичайното първо предположение е, че тунелът блокира DHCP. По-често широкомовното предаване никога не е имало път: неконфигуриран клиент изпраща до 255.255.255.255, а обикновен IP рутер не препраща този пакет. Тунелът прави точно това, което прави маршрутизиран тунел.

Два дизайна могат да променят това и те не са еквивалентни. Единият пренася широкомовното предаване; другият препраща заявката.

Широкомовното предаване никога не пресича рутера

DHCPv4 клиент без адрес изпраща от 0.0.0.0 до адреса за ограничено широкомовно предаване на UDP портове 67 и 68. Този пакет по дизайн остава в своя канал. Рутер, който го препраща, би наводнил всеки сегмент, който обслужва.

Затова маршрутизиран тунел сайт-към-сайт свързва релейния агент със сървър. Той не разширява широкомовния домейн на клиента и никое правило на защитната стена няма да го направи.

Какво всъщност разширява мостов тунел

Умишлено мостов VPN може да пренася Ethernet широкомовно предаване в рамките на поддържаната си топология и тогава DHCP може да преминава като локален трафик. Това е реален вариант, но е дизайнерски избор на слой 2. Разширявате домейна на отказите и границата за достъп заедно с широкомовното предаване.

Мостът променя също какво могат да достигнат широкомовна буря, ARP сканиране или злонамерен DHCP сървър. Ако не бихте включили отдалечения офис в същия комутатор, не правете мост на тунела само за да раздавате адреси. Тествайте този радиус на поражение, преди да го включите.

Това е по-голямо решение от това да осигурите адрес и трябва да се вземе съзнателно.

Вместо това препратете заявката

Обичайният отговор е релеен агент в локалната мрежа на клиента. Той получава широкомовното предаване, превръща го в unicast заявка и поставя своя адрес в полето за адрес на шлюза. Сървърът отговаря на този адрес на релейния агент.

За илюстративен отдалечен офис релейният агент стои в LAN на офиса, а сървърът се достига през VPN на обекта. Конфигурирайте обхвата за този офис, идентичностите на релейния агент и сървъра и пълния обратен път. Разрешаването на UDP 67 през тунела не казва на сървъра кой пул да използва.

Релеен агент, който препраща, но никога не получава отговор, обикновено е проблем с обратния път. Проверете маршрута обратно към адреса на релейния агент, преди да промените обхвата.

Отделете DHCP от ARP и от адресирането в тунела

DHCP работи върху UDP/IP. В Ethernet хост може също да използва ARP, за да провери дали кандидат адресът вече се използва. Тази проверка за конфликт е отделна локална за канала операция, а не транспортът на DHCP съобщенията. Да се каже, че DHCP е по същество ARP, е грешно; да се каже, че двете никога не са свързани, е твърде широко.

VPN клиент може също да получи адреса си за тунела от VPN протокола или от собствения пул на сървъра, а не от DHCP широкомовно предаване. Опция, чието име съдържа DHCP, може да описва изтласкани клиентски настройки, а не препратения DHCP пакет. Проверете пула на сървъра, преди да предполагате, че DHCP изобщо участва.

Запишете мрежата на получателя, собственика на разпределението, обхвата, дали има релеен агент и очакваното поведение при прекъсване. След това тествайте нов лизинг и подновяване през този модел. Ако два обекта могат да обслужват един и същ неконтролиран пул, имате конфликт, който чака първия роуминг лаптоп.