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

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

Ну а что вы сделали? Системный подход к проблеме отсутствует, зато куча непонятных телодвижений. То у вас вместо релея обнаруживается сервер, то вы на внешнем интерфейсе слушаете, то еще какая нибудь дичь всплывает.

Вам уже локализовали проблему и толку? Дамп с клиента сняли? Убедились что клиент и релей в одном широковещательном домене? Сами в дампы заглянули? Подумали? Нет, зато снова нытье про плохой Debian и не работающий пакет, опять что-то про VPN и прочие не относящиеся к делу вещи.

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

Еще раз, по буквам, алгоритм: включаем запись дампа на клиенте и релее, делаем запрос адреса. Изучаем дамп с обоих сторон. Думаем.

Введи ту команду, введи эту, в итоге что?

И что в итоге? А ничего в итоге. Поймите, это нужно в первую очередь вам и вы должны сами пытаться понять что вы делаете, а не набирать там и выкладывать здесь. Мы здесь поясним, если что непонятно, направим и подскажем. Но заниматься диагностикой вместо вас тут никто не будет. Уважайте чужое время.

Также вам уже не раз говорили, изучите работу DHCP, хотя бы на уровне Википедии, там в целом неплохая статья. Лучше всего с анализатором трафика наперевес, там очень все просто. Чтобы вы сами понимали как общаются клиент и сервер. Заодно приобретете опыт и знания.

Ну хорошо, выставили меня ослом опять, я ничего не знаю и не умею. Да, вы тру профессионалы, а я никто.

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

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

Если есть у кого спросить - я спрошу, и я спрашиваю. Это не страшно, другой раз спросят у меня. Как говорила моя учительница по русскому языку: "спросить - стыд минуты, не знать - стыд всей жизни".

[Призрак]

Хорошо, я прочитал вот эту статью, в общих чертах понял, что сей протокол означает.

https://greendail.ru/node/chto-takoe-dhcp-i-kak-rabotaet-obyasnenie-osnovnyh-principov

В частности, меня интересовали шаги Я выяснил, что на втором шаге клиент сливается в унитаз.

Мои шаги следующие:

1. Запускаю wireshark на клиенте, включаю захват udp. При этом в командной строке ввожу ipconfig /renew

2. На релее запускаю запись дампа. В командной строке запускаю tcpdump с параметрами.

3. Как только появляется сообщение, что не удалось связаться с DHCP а клиенте, запись дампа прекращаю.

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

Вы говорите смотрите, изучайте внимательно. Если по дампам понятно, что всё нормально, то это означает найти то, не знаю что. Жесть полная. Что я тут должен изучать? Клиент запрос отправляет, адрес ему готовится релеем, в ответ тишина?

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

Вы говорите смотрите, изучайте внимательно. Если по дампам понятно, что всё нормально, то это означает найти то, не знаю что. Жесть полная. Что я тут должен изучать? Клиент запрос отправляет, адрес ему готовится релеем, в ответ тишина?

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

[Призрак]

Брандмауэры отключил все, проверил ещё раз. Сменил даже платформу, на VirtualBox. Всё таки вот что я хочу узнать - DHCP сервер у меня на полигоне, прямо на шлюзе сервера OpenVpn, без DNS и контроллера домена. Мне нужно обязательно завести DNS и Active Directory в тестовой среде? Просто служба маршрутизации меня предупреждала, при установке, что есть два режима работы её - что она сама будет всё раздавать или нужно самому настроить dhcp и dns. Просто реально непонятно уже, псих берёт.

[Призрак]

Ну а что на это скажете? Тут написано, что на tun релей не работает, а в дампе запросы идут по tun.

https://forum.netgate.com/topic/130092/dhcp-relay-over-tun-openvpn/2

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

Ну а что на это скажете? Тут написано, что на tun релей не работает, а в дампе запросы идут по tun.

https://forum.netgate.com/topic/130092/dhcp-relay-over-tun-openvpn/2

Я уже хочу ругаться, долго и непечатно. Вы читаете и понимаете что я вам неоднократно писал?! Какой к собачьей матери tun, кому вы там собрались адреса выдавать? Релей должен работать на интерфейсе локальной сети, посылать запросы к серверу он может через что угодно. Идите учите матчасть. Тема закрыта.

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

Все таки нашел немного свободного времени и прочитал ссылку топикстартера, а также немного изучил материал. Действительно, DHCP релей на основе isc-dhcp-relay не работает, если в сторону сервера смотрит tun-интерфейс. В данном случае это и есть причина проблемы, которая обсуждалась три страницы.

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

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

И когда после двух дней отсутствия, возвратившись из командировки, видишь что автор снова предлагает кому-то подумать за него, выкинув ссылку на англоязычный форум, при том с некорректным описанием сути текста по ссылке, но с "традиционным" негативным эмоциональным окрасом...

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

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

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

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

[ival]

Я так понимаю не правильно отдаются mac-и, туннел подменяет мак?
Я правильно понял, что используя tap мы теряем все плюшки от l3, а именно маршрутизацию?

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

Я так понимаю не правильно отдаются mac-и, туннел подменяет мак?

У tun в linux вообще отсутствует mac.

Я правильно понял, что используя tap мы теряем все плюшки от l3, а именно маршрутизацию?

Да.

[ival]

Ну тогда в рамках site-to-site бессмысленно делать tap

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

В данном сценарии OpenVPN вообще далеко не самый лучший выбор, потому как минусы перевешивают все плюсы.

[ival]

В данном сценарии OpenVPN вообще далеко не самый лучший выбор, потому как минусы перевешивают все плюсы.

На самом деле мне всегда было не понятно использование ssl для связи site-to-site. Обычно этим любят промышлять микротоводы, при этом внятно я так и не смог добиться почему ssl, почему не используется GRE+IPSEC. Опять же если в качестве маршлутизаторов измользуются linux-системы, тоже все используют ssl, я лично не знаю никого кто использовал GRE+IPSEC, хотя насколько я знаю в linux это можно реализовать. Все-таки ssl хорош для client-to-site. Хотя может я и не прав.

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

при этом внятно я так и не смог добиться почему ssl, почему не используется GRE+IPSEC

Так в том и дело, что внятно никто объяснить не может, хотя GRE или IP-IP поднимаются в Linux в пару строк и не нужно никакого стороннего ПО (OpenVPN), также GRE поддерживается в Windows Server, насчет 2008 не уверен, в 2016 точно есть и работает.

А еще больше я не понимаю тех, кто использует OpenVPN на Микротиках, учитывая ущербность его реализации там и наличие большого количества альтернатив.

[Призрак]

Все таки нашел немного свободного времени и прочитал ссылку топикстартера, а также немного изучил материал. Действительно, DHCP релей на основе isc-dhcp-relay не работает, если в сторону сервера смотрит tun-интерфейс. В данном случае это и есть причина проблемы, которая обсуждалась три страницы.

Решил проблему, поставил Windows Server 2008 R2. Всё сразу заработало. Как я понимаю, там в сторону сервера тоже смотрит tun интерфейс, но такой проблемы нет.

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

Не поленился, перечитал своё сообщение 10 раз. Нигде там в упор не нашёл, что "по характеру вы большая скотина". Насчёт корректного обращения с людьми я что сказал не так? Я не допускал нигде грязных ругательств ни в чью сторону, потому - что я уважаю участников форума, особенно ival, вы же, администратор форума его допустили. Текст моего сообщения полностью вежливый, что в нём не понравилось опять, я не знаю. Хорошо, если это вас так задевает, то беру слова обратно, вас это устроит? Просто очень прошу больше не допускать впредь с вашей стороны такое. можно было просто сказать "проблема в tun интерфейсе" и закрыть тему, дальше бы я рыл сам. Хотя и тут у меня непонимание, нужно просто настроить маршрутизацию в iptables, чтобы всё было корректно?

И уж тем более недопустим негатив в общении, негатива и так в нашей жизни хватает.

Если я вывалю на форум свой негатив, то не хватит сообщения. В 35 лет у меня уже целый букет болячек. Я озлоблен, раздражён, ищу, где бы сорвать злость. Я срываю её, обычно, на себе, иногда на окружающих. Я знаю, что это неправильно, что подтверждает вам моё сообщение. Но оно, тем не менее, корректно. Я был бы последней скотиной, если бы покрыл вас матом, только потому, что мне плохо. Вы строгий, но, тем не менее, справедливый человек, пусть будет так. Если вы считаете, что я недостаточно компетентный человек, я тоже это признаю. Тогда просто забаньте и удалите мою запись с форума, я же, в свою очередь, больше не буду писать на interface31.ru, там тоже заблокируйте.

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

Как я понимаю, там в сторону сервера тоже смотрит tun интерфейс, но такой проблемы нет.

Проблема в реализации tun-интерфейса в Linux, у которого отсутствует MAC-адрес и теряется связность сети на Ethernet-уровне, так как ответить узлу без присвоенного IP можно только на канальном уровне, чего tun-интерфейс сделать не может, так как работает исключительно на L3.

Причем это исключительно проблема OpenVPN в Linux, на других системах или иных типах туннелей таких проблем нет.

[Призрак]

Проблема в реализации tun-интерфейса в Linux, у которого отсутствует MAC-адрес и теряется связность сети на Ethernet-уровне, так как ответить узлу без присвоенного IP можно только на канальном уровне, чего tun-интерфейс сделать не может, так как работает исключительно на L3.

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

Теперь я понял, что мне надо хорошенько изучить модель OSI, чтобы решать подобного рода задачи. Я ещё раз прошу прощения, я так не должен был себя вести, а должен был чётко предоставить то, что было нужно.

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

[Oleg_Sviridov]

К сожалению я дамп не видел последний, да наверное и нет смысла смотреть, т.к. Уваров дал направление Вам. Меня больше заинтересовало сообщение Ваше о неизвестных 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 можно и выше подняться. Наверное поэтому меня бы больше стало беспокоить устройства которые я не знаю и Настройки коммутаторов, чем нерабочий релей.

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

полезная информация.
Нашел все пункты в статье https://habr.com/ru/post/231491/

Хотелось бы узнать профессиональное мнение о методах решения хотя бы первых двух проблем в сети с несколькими управляемыми коммутаторами:

• Rogue DHCP Server
• DHCP starvation

Как минимум с первым встречался пару раз и по собственной же вине 

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

Методы защиты неплохо описаны в той же статье. Ничего нового тут не придумали.

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

[ival]

Вообще если обстрагироваться от моего обобщенного описания и статьи хабра, которая достаточно хорошо описывает принципы атак и методы борьбы, можно обратится к руководству Cisco CCNP security, а в частности к главе Switched Data plane security. Там более развёрнуто и методологически описаны атаки и как с ними бороться на уровне L2. Также для зашиты используют identity-base network service который базируется на 802.1x, но к сожалению я ни где не сталкивался с ibns в реальной сети, хотя есть сети в которых он настроен и успешно эксплуатируется. Хотя даже стати хабра в принципе достаточно, чтобы защитится от l2 атак, спроецировав просто на своё оборудование (если оно отлично от Cisco) . А самое первое с чего надо начать и с чего меня учили: «все порты которые не используются должны быть со статусом administratively down, это спасёт от половины проблем в коммутации»

[Призрак]

Уважаемые, вы меня конечно извините, за некропостинг. Но я в полной растерянности, правда. Тут я всё понимаю, я недавно открыл для себя чудеснейший инструмент, который является сетевым шлюзом. Это PfSense. Я не собираюсь спрашивать, как его настраивать, я его уже настроил, в том числе на OpenVPN. Работает это чудо уже в двух корпусах, никаких сбоев, задержек в связи, настраивается на раз, два, три. При этом можно использовать сертификаты, сгенерированные Windows OpenVPN. Если нужно, я даже могу выложить руководство, как там устанавливается OpenVPN.

Но меня интересует другое. Там параметры интерфейса tun, а не tap. Пробовал я переключать на tap, это можно, пропадает пинг. Ну и что, я не собираюсь переходить на tap, останусь на tun, это стабильное подключение. Вопрос не в том.

Я пробовал сделать так же релей, помните, мы мучились (вернее. я), выясняя это, пришли к мнению, что у tun нет аппаратного адреса, на Debian. PfSense основан на FreeBSD, там такая же проблема. Собственно, из-за этого у меня опять ничего не получилось.

Вот у Windows есть TAP адаптер, у него есть аппаратный адрес. Соответственно, релей там работает замечательно, так же, как и идёт подключение, к OpenVPN серверу, на чём бы он не был настроен. Но вот в чём тут соль? Подключение то всё равно по tun идёт, а адаптер tap, с аппаратным адресом. В linux/unix аппаратного адреса нет, интерфейс tun. Собственно, это мне и непонятно. Совершенно.

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

В Windows tun/tap адаптер имеет MAC-адрес, в Linux нет. Выход прост - не использовать OpenVPN, если у вас соединяются между собой сервера, то есть гораздо более простые и производительные варианты: GRE, IP-IP.