Ретрансляция DHCP адресов в Debian, на шлюзе.

[Уваров А.С.]

Вот честно, у вас в голове какой-то хаос, вы делаете что-то непонятное, зачем эти все скриншоты, о чем они должны сказать? Напрашивается вывод, что вы не представляете как работает протокол DHCP и не понимаете что вам надо делать.

DHCP-запрос от клиента является широковещательным, поэтому сервер, а в вашем случае релей, должен находится в одном широковещательном домене с клиентом, проще говоря в одной физической сети. Если между ними есть маршрутизатор, VPN и т.д. - работать не будет.

Далее релей отправляет запрос на сервер юникастом, так как сервер ему известен, сервер обрабатывает ответ и отправляет его релею, также юникастом.

Поэтому ваша задача - это убедиться, что широковещательные пакеты от клиента попадают на релей, если нет - разобраться почему. Для этого нужно снять дампы с сетевых интерфейсов клиента и сервера и проанализировать их. Как снять дамп на Linux - уже написали, на Windows поставьте Wiresark, в него же загрузите дамп из Linux.

[Призрак]

Вы невнимательно читаете, 32 пост. Там я высказывал предположение о том, что работать не будет, так как OpenVPN.

Если между ними есть маршрутизатор, VPN и т.д. - работать не будет.

Вы сами же и ответили на мой вопрос. Тот что я в 32 посте озвучивал. Так что работать не будет, так как между двумя этими серверами и vpn и маршрутизатор. Значит надо искать другой путь.

[Уваров А.С.]

Так что работать не будет, так как между двумя этими серверами и vpn и маршрутизатор. Значит надо искать другой путь.

Вы хоть немного пытаетесь понять написанное? У меня складывается впечатление, что нет, и что вам нужно готовое решение, желательно пошаговое.

Между релеем и DHCP-сервером может быть что угодно, главное чтобы у них были маршруты друг к другу.

А между клиентом и релеем ничего быть не должно, они должны быть в одном широковещательном домене. Понятно? Клиент и релей.

Если у вас клиент и тот интерфейс маршрутизатора, который слушает релей в одной сети, то снимаете дампы и смотрите трафик. Во время записи дампов можете запросить на клиенте адрес. Так как протокол широковещательный то пакеты на интерфейсе должны появиться обязательно (брандмауэр отключите или поставьте для интерфейса разрешить всё).

Потом собираете трафик с внешнего интерфейса и ловите там DHCP-пакеты, смотрите их заголовки. Ну и т.д. до DHCP-сервера и обратно.

А не работает у вас скорее всего из-за каши в маршрутах (от них еще туннели рвет), так как отправляет пакет один узел, а возвращают его другому.

[Призрак]

Вы хоть немного пытаетесь понять написанное? У меня складывается впечатление, что нет, и что вам нужно готовое решение, желательно пошаговое.

Прошу меня простить, но ладно, скажу, в чём проблема. Дело в том, что у меня есть, я бы сказал, небольшой дефект, недостаток, который мешает мне несколько нормально мыслить, в том числе логически, быстро принимать решения. Поэтому я иногда, топчусь на месте. Если интересно, могу написать, только в личные сообщения.

Между релеем и DHCP-сервером может быть что угодно, главное чтобы у них были маршруты друг к другу.

Маршруты есть, я предоставил схему. Ещё раз перепроверю, но не факт, что что-то упустил.

А между клиентом и релеем ничего быть не должно, они должны быть в одном широковещательном домене. Понятно? Клиент и релей.

Вот теперь понятно. Нет, клиент и релей находятся именно в одной сети! То есть с клиентом есть связь релея, они находятся и в полигоне в одной сети, 192.168.1.0, и в рабочей, боевой сети 192.168.60.0.

Если у вас клиент и тот интерфейс маршрутизатора, который слушает релей в одной сети, то снимаете дампы и смотрите трафик. Во время записи дампов можете запросить на клиенте адрес. Так как протокол широковещательный то пакеты на интерфейсе должны появиться обязательно (брандмауэр отключите или поставьте для интерфейса разрешить всё).

Хорошо, то есть мне на клиента нужно поставить акулу, а на релей tcpdump и ловить там. Брандмауэр отключен, всё разрешено.

Потом собираете трафик с внешнего интерфейса и ловите там DHCP-пакеты, смотрите их заголовки. Ну и т.д. до DHCP-сервера и обратно.

Ну тут так же, акула на сервере, где DHCP, tcpdump на сервере, где релей. И гонять по внешке (сети 192.168.12.0 на полигоне).

А не работает у вас скорее всего из-за каши в маршрутах (от них еще туннели рвет), так как отправляет пакет один узел, а возвращают его другому.

Ну хорошо, может быть и так. Но во-первых у нас есть стороннее ПО на боевом сервере, это Traffic Inspector. Во-вторых я пробовал на "чистом" полигоне ваше решение, с другим типом маршрутизации. И объяснял ещё про самодеятельность, в соседней теме, а также про то, что я вынужден был прописать маршруты в службе маршрутизации, так как меня бесило, что пропадает связь и сливаются в унитаз маршруты. Там же в соседней теме есть все те конфигурационные файлы, которые были у меня по OpenVPN, сделано так и никак иначе, по вашим советам. Только с маршрутами, прописанными в службе, всё работает.

[Призрак]

Ну вот, собственно, с клиента. Куда - то он ломится, хрен знает куда, на 0.0.0.0. При команде ipconfig /renew.

Вот, нашёл видео, но пока из него ничего непонятно. Проклятый буржуйский язык.

https://www.youtube.com/watch?v=I5lsQBBXCW8

[Уваров А.С.]

Куда - то он ломится, хрен знает куда, на 0.0.0.0. При команде ipconfig /renew.

И не куда, а откуда, своего адреса у него пока нет, поэтому 0.0.0.0, а куда - это 255.255.255.255 - широковещательный адрес. И тут Wireshark даже подсказывает вам, что это такое - DHCPDISCOVER. Так что на клиенте все абсолютно понятно.

[Призрак]

Да, понятно, что он пытается найти адрес, но по какой - то причине не может связаться с сервером. А по какой причине он не работает, пока непонятно. Дело в том, что я пытаюсь выполнить команду, которую мне подсказал ival, в это время он ничего не ловит, ноль. А по какой причине это происходит пока неизвестно. Как можно проверить широковещание в OpenVPN?

[ival]

Дело в том, что я пытаюсь выполнить команду, которую мне подсказал ival, в это время он ничего не ловит, ноль.

ival ввиду усталости написал бред. Прошу простить. Нужно убрать параметр host из строки. Попробуйте так:

Code Select Expand

tcpdump -i enp2s0 portrange 67-68 >> /tmp/dhcpDMP

[Призрак]

ival ввиду усталости написал бред. Прошу простить. Нужно убрать параметр host из строки. Попробуйте так:

Ничего страшного, я тоже, бывает, ошибаюсь :=)


Я попробовал, но опять пакетов ноль. Тогда я попробовал ввести такую команду

Code Select Expand

tcpdump portrange 67-68 >> /tmp/dhcpDMP
Тогда он мне что-то выдал! Но для интерфейса enp1s0. Я открыл порт в Traffic Inspector, может быть, это способствовало некоторому успеху. Завтра протестирую уже на месте. Уже один клиент появился, посмотрим, будет ли раздаваться остальным клиентам.

А всё же в DNS будут обновляться записи?

А насчёт виртуального полигона дома, я прочитал про микротик, дело в том, что, как говорят, у него бывают с broadcast проблемы. Буду смотреть. 

[ival]

Но для интерфейса enp1s0.

В первом посту у Вас enp1s0 это WAN порт.

Сделайте tcpdump portrange 67-68 -w /tmp/dhcp.cap а то я чето совсем понять не могу что у Вас там в сети

[Уваров А.С.]

Дело в том, что я пытаюсь выполнить команду, которую мне подсказал ival

ival ввиду усталости написал бред. Прошу простить

Поэтому надо не "пытаться", а "понимать", хотя бы на уровне используемых в конкретном случае ключей, что делает команда и как ее использовать именно в вашем случае.

Как можно проверить широковещание в OpenVPN?

Какое широковещание в VPN?! Что вы вообще там пытаетесь соорудить? Еще раз, по буквам, клиент и релей должны быть в одной физической сети. Т.е. патч-корд клиента (того компьютера который получает адрес) и патч-корд релея должны быть воткнуты в один свитч.

Больше нигде широковещание вам не нужно. Не трогайте ни VPN, ни микротики. У вас с одной стороны клиент, с другой дебиан. Вот и выясняйте что между ними летает.

[Призрак]

В первом посту у Вас enp1s0 это WAN порт.

Да, так оно и есть. Я прошу прощения, надо было мне подольше подержать для enp2s1. В архиве вложение с dhcpDMP именно с enp2s1.

Сделайте tcpdump portrange 67-68 -w /tmp/dhcp.cap а то я чето совсем понять не могу что у Вас там в сети

По Вашей просьбе, файл в архиве.

[Призрак]

А если удалить аренду через сколько примерно она появляется, при работающем релее?

[Уваров А.С.]

В дампе запросы на обнаружение сервера, других DHCP пакетов нет. Снимайте дамп с того интерфейса, куда они должны отправиться дальше, по идее это OpenVPN.

[ival]

Делайте со всех интерфейсов сразу лучше.

[Призрак]

Вот, коллеги. Два дампа - с tun0 и все. Видно ведь, что какой - то хост всё же адрес получает, но теперь он не появляется почему - то в арендованных. Я хотел посмотреть появится ли, пока нету. На всякий случай BG81-DC-01 это 192.168.30.2 а BG81-DC-02 это 192.168.30.3. Что это за мак я не знаю, вроде какой - то роутер. Появится я его заблокирую через фильтр.

[ival]

Вот, коллеги. Два дампа - с tun0 и все. Видно ведь, что какой - то хост всё же адрес получает, но теперь он не появляется почему - то в арендованных. Я хотел посмотреть появится ли, пока нету. На всякий случай BG81-DC-01 это 192.168.30.2 а BG81-DC-02 это 192.168.30.3. Что это за мак я не знаю, вроде какой - то роутер. Появится я его заблокирую через фильтр.

]

Сделайте вывод через -w, чтоб анализатором можно открыть. Ответы есть, но что вних и я не вижу чтобы 192.168.60.1 отправлял клиенту ничего

[Призрак]

Сделайте вывод через -w, чтоб анализатором можно открыть. Ответы есть, но что в них и я не вижу чтобы 192.168.60.1 отправлял клиенту ничего

Вот, ещё информация. Кроме того я ещё поигрался с опциями, чтобы уж совсем не выглядеть ослом, вывел подробную информацию (ключ -vv). Кажется, я запалил два посторонних роутера (там, кажется, tplink и zyxel), не студенты ли это подключились? Хочу попробовать выяснить до конца, по мак адресам, что за птицы, после чего их в чёрный список, отделив от сотрудников. Всё равно побегут ко мне. У одного адрес показывается, 192.168.60.26, у другого адреса не увидел. В арендованных по прежнему ничего пока не меняется. Кстати, и вирусы наверное тогда на шлюз залезли, через эти самые роутеры. Насколько я знаю, у сотрудников общежития их нет, а самими студентами занимается провайдер. Надо отсечь их, напрочь, чтобы больше в сеть не ходили.

[Уваров А.С.]

Кажется, я запалил два посторонних роутера (там, кажется, tplink и zyxel), не студенты ли это подключились?

А у вас студенты имеют физический доступ к сети? Тогда делите сеть на VLANы, сразу часть вопросов отпадет.

По дампу, что я вижу. Релей у вас работает, он получает из локальной сети Discover, перенаправляет его серверам 30.2 и 30.3, от 30.2 приходит Offer с предложением взять адрес 60.26, но в ответ тишина.

Складывается впечатление что у вас пакеты идут только в одну сторону. Потому как 60.1 Offer получил, но дальше никуда его не отправил.

[ival]

К сожалению я дамп не видел последний, да наверное и нет смысла смотреть, т.к. Уваров дал направление Вам. Меня больше заинтересовало сообщение Ваше о неизвестных tplink wr720n и ещё о zyxel ещё каком-то, которые могли подключить студенты. Это вообще жесть. Я вам начну от простого к сложному, но в принципе 20 минут хватит чтобы либо положить всю сеть либо сегмент на этом коммутаторе. И так я студент, немного умнее чем все остальные студенты и я хочу побаловаться и у меня в комнате розетка под utp, мои действия от простого к сложному:


1. Я сразу попробую проверить знает ли владелец розетки про понятие коммутационной петли. Если нет или не дай бог розетка скоммутированна в тупой l2 (не управляемы) то в принципе весь домен ляжет чере минуту максимум.
2. Потом проверю знает ли админ про rouge dhcp и начну раздавать ip со своего того самого tplink или zyxel
3. Потом побалуюсь с dhcp starvation и заберу все ip пула, если не настроен доверенный dhcp (что в 80% сетей не сделано на коммутаторах) и даже ttl аrp стоит по умолчанию (что тоже обычно никто не меняет) то ip у Вас закончатся очень быстро и вы долго будете искать куда они делись
4. Потом можно поиграть с переполнением CAM таблицы
5. И самое интересное, даже если админ от все этого защитился, и у него vlan и все по умному, то есть вероятность, что он не знает про статус порта по умолчанию в режими автосогласования. И при определенных условиях access порт (untag) может стать резко trunk ( tag) и разрешить через себя все vlan'ы


 Это я описал только обычные атака на l2 которые реализуются максимум за день при посредственных знаниях и гугле, если уровень чуть выше посредственного, то 5-10 минут ( на каждую) + время на скачку софта ( для некоторых типов атак). А с помощью l2 можно и выше подняться. Наверное поэтому меня бы больше стало беспокоить устройства которые я не знаю и Настройки коммутаторов, чем нерабочий релей.

В своё время из-за похожих ошибок я интернетом пользовался бесплатно месяц, заворачивая трафик через роутер кого-то из соседей. Раньше заявки на подключение долго обрабатывались, а интернет нужен был. И косяк был именно в том, что провайдер не смог правильно обезопасить своих клиентов настройкой своего оборудования.

[Призрак]

Складывается впечатление что у вас пакеты идут только в одну сторону. Потому как 60.1 Offer получил, но дальше никуда его не отправил.

Я в полном недоумении, опять. Не понимаю, почему это происходит? Где копать, где рыть? Во вложении список маршрутов с шлюза, плюс адреса. Может быть это прольёт свет на проблему? Я уже даже теряюсь предположить, что это... Вот какую картину, судя по вашей информации, я вижу:

1. От клиента приходит запрос "где мой адрес, хочу мой адрес!"
2. Релей посылает на DHCP сервер запрос "дружище, есть ещё из пула?"
3. DHCP ему отвечает "конечно есть, какой вопрос? Держи!"
4. Релей обращается к клиенту "вот, держи свой адрес! Эй, ты где?"
5. В ответ тишина.....

Если честно, товарищи, я в лёгком отупении. Как такое может вообще происходить и где ещё копать. Кстати, на самом клиенте команда

Code Select Expand

ipconfig /renew
Выводит в итоге сообщение "не удалось связаться с DHCP сервером, превышено время ожидания".

А всё - таки на шлюзе есть такая фишка, называется она агент DHCP ретрансляции. Вы уверены, что её не следует использовать?

У меня на полигоне дома такая же проблема, точно такая же. Ладно, коллеги, тогда я сделаю вот что - нарисую схему, от сервера, до релея, до клиента, потом буду дальше писать в этой теме. Я уверен, что без чёткого понимания, что, где, когда, почему и зачем дискутировать дальше бессмысленно. Нужна схема.

Но скажу вот что. OpenVPN сервер у нас расположен в сети 192.168.10.0, на шлюзе, который находится на VMWare vSphere (виртуальная машина), DHCP с подсетью для релея у меня находится на виртуальной машине на Hyper-V, в сети 192.168.30.0, шлюз в общежитии в 192.168.60.0, находится на физической машине, без виртуализации.

К сожалению я дамп не видел последний, да наверное и нет смысла смотреть, т.к. Уваров дал направление Вам. Меня больше заинтересовало сообщение Ваше о неизвестных tplink wr720n и ещё о zyxel ещё каком-то, которые могли подключить студенты. Это вообще жесть. Я вам начну от простого к сложному, но в принципе 20 минут хватит чтобы либо положить всю сеть либо сегмент на этом коммутаторе. И так я студент, немного умнее чем все остальные студенты и я хочу побаловаться и у меня в комнате розетка под utp, мои действия от простого к сложному:

Восхищаюсь знаниями грамотного человека, не то, что мои. Я буду трахать мозги провайдеру. У них железный ящик с коммутатором, с их коммутатором, он закрыт на ключ, имеет к нему доступ только провайдер. Вот они то за виланы и отвечают, они чётко должны отделить нашу сеть. Кроме того, за ними косяк, из-за чего мне и пришлось ставить шлюз. Они настраивали WiFi для студентов, что-то наворотили, так и не смогли исправить, спешно выделили нам белый адрес и мы сделали шлюз. Может, они в спешке что-то напутали. Будем разбираться.

[Призрак]

У меня, кстати, уже сильнейшее подозрение, что дело в Debian. Один в один ситуация и на работе и на полигоне. Один в один. Точно так же, как сказали, обращается к серверу, получает адрес, обращается к клиенту, в ответ тишина. Может какие настройки сети нужно сделать по нормальному? Такое у меня сильнейшее подозрение, что Broadcast не работает. Именно он.

Ещё я в более сильнейшей растерянности потому - что там превосходно работает isc-dhcp-server! То есть, он безо всяких проблем раздаёт адреса! Причём сразу же, после запуска! Вот конфиг:

Code Select Expand

ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
log-facility local7;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.60.255;
option routers 192.168.60.1;
option domain-name-servers 192.168.30.2, 192.168.30.3;
subnet 192.168.60.0 netmask 255.255.255.0
{
range 192.168.60.21 192.168.60.30;
}
Только вот загадка, если isc-dhc--server работает, причём раздаёт адреса корректно, то почему не работает тогда relay?

[Призрак]

И, может быть, в релей стоит все три интерфейса добавить, а не один? Вот тут, в вопросе, вроде советуют так сделать.

https://unix.stackexchange.com/questions/290442/how-to-setup-dhcp-relay-in-debian-8

Кидаю ещё настройку сети со шлюза.

[ival]

Такое у меня сильнейшее подозрение, что Broadcast не работает.

Широковешательный где не работает? Еслиб броадкаст не работал сеть бы не работала. Если уж очень хочется проверить то пропингуйте его.

всё - таки на шлюзе есть такая фишка, называется она агент DHCP ретрансляции.

Это тоже самое. Хотя может есть конфликт между двумя пакетами, но это не точно, я не силен в линуксе.

И, может быть, в релей стоит все три интерфейса добавить, а не один?

Агент запускается на интерфейсе с которого надо делать релей

[Призрак]

Ну я, увы, больше не знаю, что делать. Главное, что dhcp сервер работает, релей не хочет ни в какую работать. Я читал про какой - то option 82, может быть, стоит мне интерфейс перегнать в vlan в debian и попробовать опять?

[Уваров А.С.]

Главное, что dhcp сервер работает, релей не хочет ни в какую работать.

Стоп, вы что, на одном узле пытаетесь поднять и сервер и релей?

А всё - таки на шлюзе есть такая фишка, называется она агент DHCP ретрансляции

Это тот же самый релей.

Ладно, коллеги, тогда я сделаю вот что - нарисую схему, от сервера, до релея, до клиента, потом буду дальше писать в этой теме. Я уверен, что без чёткого понимания, что, где, когда, почему и зачем дискутировать дальше бессмысленно.

Да не трогайте вы схему. Релей работает, он получает, передает, принимает ответ. Только не отдает назад в локалку. Вот там и ищите. Инструменты вам показали - tcpdump + wireshark. Протокол простой. Все лишнее для начала отключите (в т.ч. брандмауэр).

[Призрак]

Стоп, вы что, на одном узле пытаетесь поднять и сервер и релей?

Мне пришлось пока убрать релей, я вместо него снова поднял DHCP сенвер. Не вместе, а вместо. Я продолжу на боевом после того, как получится всё на полигоне, а так пока бессмысленно.

Да не трогайте вы схему. Релей работает, он получает, передает, принимает ответ. Только не отдает назад в локалку. Вот там и ищите. Инструменты вам показали - tcpdump + wireshark. Протокол простой. Все лишнее для начала отключите (в т.ч. брандмауэр).

Брандмауэр отключён, я сюда в тему сколько дампов уже скинул, с той, с другой стороны, что это дало? Пока ничего. Я вижу судорожные попытки клиента получить адрес, высылал на скрине в посту, команда пишет мне что сервер dhcp недоступен, как вот ещё смотреть и что? Почему пакеты могут идти в одну сторону, вот бы мне это узнать. А так пока топчусь на месте. Досадно очень, что документации по этому релею нету, хорошей информации. Вот пишут, что настроить легко. Казалось бы, ан нет! Вот файл брандмауэра, может что не так сделал?

Сразу говорю, дропы все я убирал, тоже бесполезно!

[ival]

Я в очередной раз ничего не понял. enp1s0 это интерфейс смотрящий на провайдера, зачем на нем разрешать 67 порт? Я так и не могу понять как у Вас построена сеть, но у Вас должен быть до сервера, на всех интерфейсах через которые идет пакет с клиента и на которых есть ACL разрешен 67 udp. А от сервера до клиента 67-68 порт UDP.

[Уваров А.С.]

Брандмауэр отключён, я сюда в тему сколько дампов уже скинул, с той, с другой стороны, что это дало? Пока ничего.

В том то и дело, что дампы вы только скидываете, проанализировать их вы даже не пытаетесь. Хотя там нет ничего сложного, хватит даже статьи на Вики для понимания. Весь процесс укладывается в четыре пакета: DISCOVER - OFFER - REQUEST - ACK.

Я вижу судорожные попытки клиента получить адрес, высылал на скрине в посту, команда пишет мне что сервер dhcp недоступен, как вот ещё смотреть и что? Почему пакеты могут идти в одну сторону, вот бы мне это узнать.

Дампы, логи и т.д. Включаете расширенные логи где только можно, создаете в iptables цепочки:

Code Select Expand

iptables -t filter -A INPUT  -p udp -m udp --sport 67 -j LOG --log-prefix "DHCP_SRV_IN"
iptables -t filter -A INPUT  -p udp -m udp --sport 68 -j LOG --log-prefix "DHCP_CLNT_IN"
iptables -t filter -A OUTPUT -p udp -m udp --dport 67 -j LOG --log-prefix "DHCP_SRV_OUT"
iptables -t filter -A OUTPUT -p udp -m udp --dport 68 -j LOG --log-prefix "DHCP_CLNT_OUT"
Входящий с портом источником 67 - пакет от сервера к релею, входящий с портом источником 68 - от клиента к релею, исходящий на порт 68 - от релея к клиенту, на 67 - от релея к серверу. Интерфейсы никак не фильтруем, потом смотрим кто куда ходит.

На клиенте еще дамп снимите или просто пакеты посмотрите.

[Уваров А.С.]

Посмотрел я дампы еще раз и не совсем понял, точнее совсем ничего не понял. Все запросы летят от роутеров: DLINK, TP_LINK, Zyxel. Что это за роутеры и откуда они взялись в локальной сети. Если там проходной двор, то неудивительно что ничего не работает.

Ну и присоединюсь к вопросу, зачем на внешнем интерфейсе порт 67 открыли?

[Призрак]

Вчера уже ночью проверил на полигоне, добавил фильтры, в логах пусто. Вчера не было возможности экспериментировать как следует, я прилёг, меня не разбудили, как назло.

Порт я открыл, потому - что мне сказали открыть порт, а на каком интерфейсе не сказали. Ну я и открыл. В очередной раз выловили меня на некомпетентности, радуйтесь.

Если учесть то, что DHCP на шлюзе работает, вместо релея, как мною уже было неоднократно сказано, раздаёт отлично адреса, конфигурацию указал я выше, значит что всё же проблема именно в релее. Больше я ничего не могу предположить. Вы говорите, что клиент его не хватает этот адрес, с релея, на релей он приходит, что подтверждают дампы. Тогда почему же он хватает адрес с DHCP сервера, который установлен на шлюзе и работает прекрасно, в отличие от релея? Есть над чем подумать. Debian прекрасная операционная система для сервера, но есть у неё один серьёзный недостаток всё же - пихают устаревшее программное обеспечение туда. Отсюда и бывают проблемы, увы. Идеального дистрибутива Linux нет.

[Уваров А.С.]

Во первых, запроса от клиента на релее в дампах нет, все запросы идут от роутеров. Это раз. Релей работает, т.е. получает, передает и принимает. Почему не отправляет - это уже вам думать надо и хоть немного пытаться анализировать ситуацию самостоятельно, а не прыгать между технологиями и вариантами настройки.

Debian прекрасная операционная система для сервера, но есть у неё один серьёзный недостаток всё же - пихают устаревшее программное обеспечение туда. Отсюда и бывают проблемы, увы. Идеального дистрибутива Linux нет.

В Debian в DHCP-релеем проблем нет, как их нет и в Windows, и в Mikrotik. Потому что это предельно простое, я бы даже сказал, примитивное ПО, которое просто работает. Если не работает - то тому есть объективные причины, как правило в виде внешних факторов.

Порт я открыл, потому - что мне сказали открыть порт, а на каком интерфейсе не сказали. Ну я и открыл.

Другой раз вам скажут выполнить в консоли rm -rf /*, тоже сделаете не задумываясь?

[Призрак]

о первых, запроса от клиента на релее в дампах нет, все запросы идут от роутеров. Это раз. Релей работает, т.е. получает, передает и принимает. Почему не отправляет - это уже вам думать надо и хоть немного пытаться анализировать ситуацию самостоятельно, а не прыгать между технологиями и вариантами настройки.

Я не знаю, в который раз уже вам повторяю. Надо, наверное, создать шаблон, чтобы не печатать долго. Я уже говорил, не раз, что DHCP сервер работает и раздаёт адреса. Если вы говорите, что адреса приходят, релей их пытается раздать и не может, в чём же тогда дело? Если сам DHCP работает, то и релей должен отдавать то, что обязан. Я понимаю, если бы адреса не приходили или релей не обращался бы к серверу, то ещё да. А если всё уже пришло и релей не отдаёт, это, извините, идиотизм. Вы купили буханку хлеба в магазине, вам её не отдают, а деньги взяли. Странно?

По OpenVPN - конфигурационные файлы все ваши, правленые под вашим руководством.

В Debian в DHCP-релеем проблем нет, как их нет и в Windows, и в Mikrotik. Потому что это предельно простое, я бы даже сказал, примитивное ПО, которое просто работает. Если не работает - то тому есть объективные причины, как правило в виде внешних факторов.

А вы докажите, что оно работает. Соберите стенд, такой же как у меня на VMware, когда у вас будет время и попробуйте. Примитивные настройки это не значит ещё, что всё просто работает.

Кстати, вот ещё странная ссылочка https://superuser.com/questions/335263/problem-playing-games-using-openvpn-that-use-broadcast-packets-other-games-work

Другой раз вам скажут выполнить в консоли rm -rf /*, тоже сделаете не задумываясь?

Как горько, что надо мной пытаются посмеяться. Я знаю, что это за команда, я не задумываясь бы послал этого человека в далёкое пешее.

[Уваров А.С.]

Если сам DHCP работает, то и релей должен отдавать то, что обязан.

Кому он и что обязан?

Если вы говорите, что адреса приходят, релей их пытается раздать и не может, в чём же тогда дело?

Я говорю вам то, что увидел в дампах. Дамп - это то, что прилетело на интерфейс, если там не было пакетов от клиента - значит их не было. Было бы очень неплохо, если бы вы посмотрели туда самостоятельно.

По OpenVPN - конфигурационные файлы все ваши, правленые под вашим руководством.

Причем здесь OpenVPN? К этой части сети вопросов пока нет.

А вы докажите, что оно работает.

Я не собираюсь никому ничего доказывать, я знаю что пакет isc-dhcp-relay работает, при этом он прост как табуретка. Ищите проблемы у себя, но вы не хотите этого делать. Вместо этого занимаетесь какой-то хаотической деятельностью, которая не приближает вас ни на шаг к решению. За вас это тоже делать никто не будет.

Мы здесь исписали уже две страницы, вам указали и показали инструменты анализа, обрисовали область которую надо изучить. Вы хотя бы в свои дампы заглянули? Что-то понять попытались? С клиента дамп сняли? Зато уже на две страницы сетования о том, какой плохой теперь уже Debian, ну извините, другого Debian для вас не завезли...

При этом я не вижу с вашей стороны элементарного понимания как работает DHCP. Хотя это очень простой протокол. Слушать что вам говорят вы не хотите, думать и анализировать тоже. Зато уже неделю "трете фары и пинаете колеса" в надежде что оно само заработает или кто-то сделает все за вас.

[Призрак]

Я ничего не делаю?! Я уже тонну информации выкинул, сколько дампов снял, а вы говорите, что я тру фары и пинаю колеса?! Введи ту команду, введи эту, в итоге что? Ну хорошо, выставили меня ослом опять, я ничего не знаю и не умею. Да, вы тру профессионалы, а я никто. Потешили себя, развели дурака и довольны.