Фильтрация или блокировка DHCP через EOIP

Я полностью согласен с Pe1chl — мост через VPN поверх публичного Интернета должен быть маршрутизируемым решением, а не мостовым. Есть ли причины использовать мосты? Конечно. Но в общем случае мосты через WAN создают гораздо больше проблем. Лично я отвечал на десятки обсуждений, где пользователи пытались обойти какую-то проблему, которая возникала именно из-за плохой архитектуры сети. Дело не в том, что что-то НЕЛЬЗЯ делать, а в том, что "это не самая лучшая идея". (Если бы смотритель зоопарка спросил на форуме зоопарка, как не дать аллигаторам съесть кроликов, ответ был бы: не сажайте кроликов с аллигаторами.)

Разделение DHCP по WAN, который при этом надо мостить — решение шаткое. Проблема, которую пытаются решить, звучит так: "Я хочу, чтобы пользователи на площадке А всегда получали DHCP, даже если связь с площадкой Б пропадет." А как не дать пользователям на площадке А присвоить статические IP из диапазона площадки Б? Простой ответ — сделать их независимыми сетями и маршрутизировать между ними, чтобы при наличии канала они могли общаться, а при отсутствии — нет. Так обе сети живут самостоятельно, даже если связь упала.

Хорошо, для лабораторных экспериментов можно и так. Как уже написали выше, достаточно прописать простое правило на мосту в обеих точках — заблокировать в цепочке forward любой UDP-трафик с портами назначения 67 или 68 — можно даже заблокировать исходные порты 67 или 68, чтобы DHCP-ответы, если они вдруг будут в широковещательном виде, тоже не проходили.

Если я всё же делаю мост поверх WAN, то лично я не позволяю маршрутизаторам, создающим мост, участвовать в самой сети (то есть DHCP на каждой площадке на разных устройствах). Это с точки зрения провайдера, чтобы порт выглядел и работал как неуправляемый коммутатор.