все лгут

московский электробус

#электробус #троллейбус #мзт #троллейбус_с_автономным_ходом #википедия

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

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

какие основные претензии предьявлались электробусу

  • дорогой

  • не надежный

  • зависит от погоды/сезонов

  • он просто плохой и новый, а старый добрый троллейбус намного лучше.


ну чтоже давайте разбиратся.

дорогой -  примерно в 2 раза дороже сравнимого автобуса, а современный троллейбус - разница около 4 миллионов это около 10%, но я не думаю что это так критично - троллейбусу нужна контактная сеть и её обслуживание, тяговые подстанции. трамвай (витязь) стоит в 3 раза дороже, а еще замороочки с путями и контактной сетью. контактную сеть ремонтируют в "темное време суток" - мало кто видит, еще меньше кто знает, однако она от этого не перстает стачиватся, а вставки в токоприенике по прежнему надо менять.

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

ктому же у электробуса меньшее потребление энергии т.к. заряжается на зарядной станции,  а не постоянно работает через плохонький скользящий контакт в сравнительно никовольтной (600 вольт) контактной сети. но в реальности это будет сильно зависеть от применяемых аккумуляторов. будет у них большой КПД - будет и электробус потреблять меньше энергии чем троллейбус. забегая вперед скажу, что у литий-титаната КПД может быть за 95%.

а давайте теперь предположим, что экономим расходы на электроэнергию на 15% (цифра из открых источников заявляют 18 я округлил в меньшую сторону) в сравнении с троллейбусом. как любят делать чудики масштабируем до масштабов страны и вычисляем стоимость. если честно, цифра получается ни о чем. такое сравнение уместно для конкретной модели электробуса в конкретных условиях. т.е. в ряд ли можно выйти за масштабы города.

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

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

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

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

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

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

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

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



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

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

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

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

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

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

если говрить о цифрах ресурса, то в вашем мобилнике ресурс акумулятора сотсвляет где-то 300 - 500 циклов разряд-заряда, литий железо-фосфаат  где-то 2 000 - 7 000,  литий-титанат (toshiba scib) больше 25 000. т.е. видно что у аккумуляторов предназначеных для использования в электротранспорте в разы больше ресурс. достигается это ценой плотности хранения энергии.

что до фото обгоревших проводов - ну будут провода по-толше, что еще могу сказать.

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

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

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

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

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

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

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

вобще ионисторы логичней применять в гибридных системах, где можно  запускать ГлавнуюЭнергетическуюУстановку переодически. а её энергию сохранять на небольшое время. после чего ГЭУ либо глушть либо ставить в дежурный режим. в качестве ГЭУ можно использовать ДВС. ДВС обычно загоняется в самый лучший режим и расчитывается из средних характеристик, а не максимальных. применение ионисторов связано прежде всего с тем, что у него довольно большой саморазряд - он быстро теряет накопленную энергию.

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

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

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

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

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

в камаз'ах второго поколения (это московский электробус) насколько мне известно вообще комбинированая система т.е. до ~0 используют электричество после нуля печку. т.е. автобус тратит на 100 км 30литров солярки, а элетробус в минус 1 литр. наверное круто было бы сделать каталитическую печь на газе - но надо рассматривать еще вопросы обеспечения, безопасности и стоимости владения.

вообще схема с ГПУ на газе > генератор > ионистор > ТяговыйЭлектроДвигатель - это довольно неплохое решение. такую природу использовал почивший в лете "ё-мобиль". нечто похожее используется на большегрузном транспорте - например тепловозах и карьерных самосвалах. называют такое решение электротрансмиссия. но время движется в перед и схема становится не самой выиграшной. появляются и дешевеют новые накопители энергии, схема довольно громоздкая, газ на ТЭЦ можно сжечь с большим КПД, хорошие аккумулятры безопасней, требуется сложноая настройка/управление и т.п.

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

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

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

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

надежды принято связывать с нанонопроводниковыми аккумуляторами. их ресурс уже больше 200 000 циклов. при значительном - в разы увеличеной плотности хранения энергии. еще есть направление графеновый аккумуляторы. в сущности нанопроводник - нанотрубка это графен (одномерная - просто плоскость структура) свернутый в трубочку. есть даже попытки заменить в таких аккумуляторах  литий более дешовым магнием. как я уже отмечал - спрос на источники энергии двигает технологии систем её хранения вперёд.

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

надо еще отметить, что основнаня модель московского электробуса КамАЗ-6282 - это уже второе поколение машин. основное отличие от первого использование аккумуляторов литий-титанатного типа, а не литий-железо-фосфата это позволяет использовать батарею в режиме "ультра быстрой" зарядки без сильной деградции батареи. хоть LFP аккумуляторы пригодны на транспорте, но слишком частые "быстрые" зарядки довольно быстро снижают емкость батареии - вспониманием ночную зарядку малыми токами питерского электробуса.

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

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

P.S.
большинство прочитаных мной заметок про электробус попадают под статью 128 УК РФ. я постарался написать, что мне известно. в целом похоже подсуетились разные люди, которые просто зарабатывают на блогах. истово негодуют: "ах какие в мерии придурки - меняют троллейбусы электробусами" и напяливают маску борца с системой, но на всамом деле даже не имеют технического образования, а электробус сравнивают с мобильником.

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

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

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

по теме вторичных источников очень рекомендую данное видео, я сделал ссылку на интересующий нас момент, но если вы интересуетесь темой - видео очень интересное.

все лгут

Физика вечного двигателя - часть 2

в предЪыдущей статье я несколько обнадежил народ, но не сказал ничего конкретного. тут попробуем расжевать, но и попутно посмеёмся на Н.Теслой и его последователями. в чем смех? обычно эти крендели ярые (что не от большого ума) противники ТО. хоть ничего неодназначного ТО и не постулирует - просто Н.Тесла был сторонником теории эфира, а значит и одыкватный теслодрочер должен тоже верить в теорию эфира.


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


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

в чем же конкретно смех? ТО объединяет электрическое и магнитное взаимодействия. даже скажем  больше - говорит об относительности магнитного взаимодействия. т.е. если в одной ИСО взаимодействие электрическое - в другой оно может быть магнитным. например поле перемешает заряд один единственный заряд в одном направлении - это ток? ну значит существует ИСО в которой этот ток прикидывается магнитным полем.

пример: лежит на столе провод. по нему бегут носители заряда - ну ЭДС есть вот они и бегут. внимание вопрос. если в системе носителя заряда поле электрическое, какое оно будет в системе провода? неужели магнитным?

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

с этой задачей неплохо справляется униполярный генератор. т.е. мы берем постоянные магниты, собираем на них генератор и все?

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

т.е. в теории - да. такую машину построитиь можно, только надо применить ТО. в чем собственно и ЛОЛ.

что до практики. не получится изготовить абсолютно равномерные магниты, не получится полностью скомпенсировать полезные токи и тд и тп - т.е. на работу генератора придеться затрачивать мощность. т.е. КПД генератора не будет 1.

в приципе у теслодрочеров есть такое направление называется это "генератор де пальмы"

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

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

стоит только отметить это не совсем вечный двигатель это устройство типа вечного двигателя. а примерную ЭДС такого устройства легко прикинуть по формуле
ЭДС= nФ
Ф - поток магнитной индукции через пластину
n - обороты в секунду.

как нетрудно догадаться если возмем магнит диаметром 10 см= 0.1 метра с индукцией 1.3 Теслы.
Ф= 3.14*0.05*0.05*1.3= 0.01 Вб - совсем немного. ну n... пусть 10 оборотов в секунду. с одной пластины мы получим 0.1 Вольт. ну у нас две - 0.2 вольта.

в этом тоже свой ЛОЛ.

наверно гений теслодрочер скажет: "как можно таким напряжением запитать двигатель?"

ну на то они и теслодрочеры, чтобы задавать тупые вопросы.
все лгут

FreeBSD - жизнь малина (RP 4)

#arm #raspberrypi #freebsd #raspberry_pi_4

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

однако возник вопрос, а можно ли подцепить микроконтроллер? стандарное решение "умного" дома это arduino. но честно говоря стоит эта штука неоправданно дорого. оригинальная стоит около 3 000 руб. должно стоить раза в 3 дешевле. если еще немного раскошелится, лучше купить полноценный компьютер: смотрите что есть. обратите внимание - память разделяется видеокартой и CPU. т.е. я бы не рекомендовал жадничать с памятью. в реальной эксплуатаци вы же наверняка захотите ещё сделать /tmp в памяти. так что 8 гигов - самое оно.

как вы навеное уже догадались первая мысль которая пришла в голову - это "можно ли поставить туда FreeBSD ?"

порт ARM во фре - не самая сильная её сторона, однако в последние годы мы видим значительный прогресс в этом направлении. как в целом arm так и  Raspberry Pi. в принципе есть готовые образы, которые нужно просто закатать на SD карту.

не забывайте только, что Raspberry Pi 4 это улучшеный RP3 - uses the BCM2711 SoC (a re-implementation of BCM283X on 28nm) т.е. немного улучшенный RP3. вам будет нужна версия FreeBSD не ниже 13. можно конечно поискать счастья с FREEBSD-12-STABLE, но лучше использовать что-то по-новее. кстати 13.0 выходит через пару недель.


в заключени хочется отметить только, что RP не хватает ATA - хватит даже одного канала sata. ATA кстати весит как задача проекта FreeSD arm. как поддержка появится - это будет полноценная замена десктопу. из пожеланий останется только  экзотика типа RP в форм-факторе планшта - сразу плата, корпус, экран, GSM модуль, а если еще и ATA так это  бомба.
все лгут

бизнес идея?

самое смешное буду писать по сути. не о том как построить бузинос, а об идеи.

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

но я вот о чём задумался, а какой мощности можно подключать котел? c тепловым аккумулятором чем больше тем лучше, но мощность ввода. при вводе 15 Квт обычно используют котел на 12 Квт оставляя 3 Квт на "бытовуху".

как я показывал недавно типичные потери правильно постороеного дома ~8Квт. если только вы не отгрохали барскую усадьбу под 200 квадратов или больше. ~100 квардратов потери будут пиримерно 7-8 Квт. хотя конечно можно и 100 со стенкой в 1,5 кипича неутепленную - тоже не сахер. но не будем о грустном.

на зарядку теплового аккумулятора остается всего 4 Квт если котел мощностью 12Квт. совсем немного больше - 6 Квт было бы намного веселей. т.е котел на 14 кВт  - решает. а если мы заряжаем тепловой аккумулятор мощностью 7 Квт - то это вообще праздник какокой-то.

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

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

в схему остаётся только добавить еще запрет включения тиристора при появлении дополнительной нагрузке на соотвествующей фазе.

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

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

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

т.е. да на какой-то малый момент времени мощность будет превышатся. но это время очень мало. я оцениваю как ~1/100 секунды. обычно вводной автомат может держать незначительное превышение тока около часа. значительное превышение раза 1,5 - это секунды. даже при кратном привышении цепь не будет разорвана мгновенно - вообще говоря ток и время не расцепления зависит от типа автомата. т.е. если не привышать ток в разы - все должно пройти бесследно.

намылить что ли дядя Вове - я придумал как можно котел запустить на 15 Квт с 15 Квт-ым вводом. хотя он не инженер. инженер делает то, что лучше подходит, а "практик" делает то, что у него лучше получается и учится чему-то новому не хочет - придется выкладывать  в открытый доступ.
все лгут

электрокотел

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

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

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

  1. с симисторным управлением

  2. с магнитным пускателем (реле).

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

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

  1. реле надо скрестить с защиным термодатчиком - чтобы  всегда можно было бы обесточить систему. при работе шуметь не будет - раз включаются и  все. лучше использовать с управлением на 24 вольта.

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

  3. надо еще наколхозить платку которая будет всем рулить - это однин(!) таймер - кондер с резистором, чтобы обеспечить выбег насоса, управлять которым нужно тоже симистором.

  4. нужен рабочий термостат.  т.е. нужно сделать NTC датчик и транзистром подавать "+" на каналы ТЭНов.

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

можно конечно полностью положится на тиристоры и разрывать цепь сигнала на оптоизоляторы. если тиристоры достаточно надежны - может так будет даже лучше.

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

проще всего сделать выбег на симисторе - т.к. ток удержания у драйвера симистора крайне мал - можно легко сделать таймер на резисторе и конденсаторе. выбег насоса нужен 1-3 минуты.

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

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

на микроконтроллере можно наворотить вообще все. но я ограничусь кондером и резистором на которых соберу таймер для обеспечения выбега насоса - т.е. нужно будет собрать 4 канала - 3 для ТЭНов и один для насоса по схеме выше. возможно сделаю отдельный вход для боллера. тогда нужен будет еще один канал - для переклюения клапана.

всю управляющую схему котла сделать низковольтной -  5/24 вольт. в этом случае вы получате очень безопасную схему - пока трансформатор не пробит (и такое бывает) - отоварить она сможет только 24 вольтами, что абсолютно безболезненно. т.е. схема будут безопасней чем многие промышленные котлы - у них термодатчики под напряжением сети - "фаза". пробьет термодатчик то схема отоварит уже 220 вольтами.

конечно для ТЭНов можно использовать все в одном - это что-то типа такого, но цена выше в ~7 раз. ктому же не все тевердотельные реле одинакого полезны. у некоторых всего два симистора, а в место третьего - перемычка. т.е. неполучится собрать ТЭНы звездой.

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

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

FreeBSD: границы ключ

#FreeBSD #mpd5 #strongswan #unbound #isc_dhcp

здесь я рассмотрел создание l2tp сервера с IPsec. однако пример конечно же демонстрационный - запускать радиус SQL и сам l2pt сервер на одной машине - идея не самая лучшая. обычно делают отдельно SQL, на нем можно запустить радиус, а он уже говорит кого пускать, а кого нет.

т.е. сервер(роутер) - это граница сети. он может попутно раздавать интернет и обеспечивать шифрованный канал с удаленными филиалами, подключать к основной сети мобильных клиентов. т.е. типовая схема выглядит как-то так
l2tpClientDesign.png
т.е роутер конечно может быть аппартным - есть деньги покупайте подходящий джунипер, циску, хуавей может даже д-линк. однако совремнные процессоры имеют достаточное быстродействие и неочень большое энергопотребление. если поствить хорошие сетевки - раньше я предпочитал использовать intel 82575, а сейчас с удивлнием обнаружил что  драйвера igb в 12.2 нет (man em внушает некоторый оптимизм) - уж сотни мегобит вы сможите перелопатить практически с любым размером пакета. интел - хорошая сетевка - по дифолту она может эффективно загрузить 4 ядра, осталось накрутить в драйвере максимальое число прерываний - мы получаем зверь роутер за смешные деньги.

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

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

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

когда мы строим роутер надо понимать спицифику его работы - тогда можно конкурировать с аппаратным роутером. в качестве бонуса программного роутера - получаем универсальность - можно поставить тот - софт, который нужен нам. на роуторе неплохо бы поднять DNS(рекурсор) и DHCP-сервер. кстати при большой нагрузке рекурсор на роутере тоже запускать не желательно, юзерспейс должен быть максимально легкий или не быть совсем, но мы накрутим mpd5, strongswan, unbound, isc-dhcp. можно поставить еще какую-нибуть реализацию BGP - и проанонсить непосредственно подкюченные сети, ну или использовать статические маршруты, что не универсально.

начнем с настройки vpn в смысле стационарных тунеллей, которые потом надо будет зашифровать. впринципе в руководстве неплохо описана данная ситуация у нас ослажняется тем, что нужно использовать strongswan и принимать входящие l2tp подключения. для роутеров лучше выбрать стационарные IP. конечно можно использовать стационарный IP только для центрального оффиса и подключать филиалы как мобильных клиентов. но я использолвал стационарные IP адреса.

по-традиции хендбук я не пересказываю - придется писать настройку в rc.conf. как сделать руками - читайте в хендбуке. т.е. в rc.conf нужно что-то типа такого:

cloned_interfaces="gif0 gif1"
ifconfig_gif0="inet 10.10.0.2 10.10.16.2 netmask 255.255.255.255 tunnel 192.168.1.53 192.168.1.54"


показано на примере соединения центрального офиса с филиалом 1. тут вот на что надо обратить внимание. здесь маска /32 некоторые предпочитают делать маску /30 - тогда узлы могут оказатся в разных подсетях - см. их IP-адреса. на роутере филиала нужно тоже самое, только наобород.

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

# cat /usr/local/etc/bgpd.conf
AS 64512
listen on 10.10.0.2
network 10.10.0.0/20

neighbor 10.10.16.2 {
remote-as 64513
descr "office_1"
}

для филиала все тоже самое, только нужно указать соответсвующую AS и подсеть. демоны запущены. конфиги на примере центрального оффиса:

# bgpctl show
Neighbor AS MsgRcvd MsgSent OutQ Up/Down State/PrfRcvd
office_2 64514 0 0 0 Never Active
office_1 64513 66 66 0 00:31:17 1

# netstat -rn
Routing tables

Internet:
Destination Gateway Flags Netif Expire
default 192.168.1.1 UGS wlan0
10.10.0.1 link#4 UH lo1
10.10.0.2 link#3 UHS lo0
10.10.16.0/24 10.10.16.2 UG1 gif0
10.10.16.2 link#3 UH gif0
127.0.0.1 link#2 UH lo0
192.168.1.0/24 link#5 U wlan0
192.168.1.53 link#5 UHS lo0

Internet6:
Destination Gateway Flags Netif Expire
. . .


как видно есть подключение с одним из филиалов, его подсеть добавлена в FIB - значит мы все собрали в кучу. если предположить, что сетевка роутера филиала смотрит в свою непосредственно подключенную сеть интерфейсом 192.168.16.1 то неплохо бы проверить:

# ping -s1500 10.10.16.1
PING 10.10.16.1 (10.10.16.1): 1500 data bytes
1508 bytes from 10.10.16.1: icmp_seq=0 ttl=64 time=4.458 ms
...
--- 10.10.16.1 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.711/5.520/9.122/2.154 ms


конечно же MTU там меньше 1500 - ну так для проверки боеготовности. осталось сказать роутерам перекладывать пакетеки с интерфейса на интерфейс и все зашифровать. покажу настройку strongSwan для центрального офиса - настройки удаленных офисов - это фактически зеркальная секция dpr1 конфига ниже только не auto=add а auto=start:

# cat /usr/local/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file

conn dpr1
leftsubnet=10.10.0.0/20
right=192.168.1.54
rightsubnet=10.10.16.0/24
type=tunnel
keyexchange=ikev2
esp=aes128-sha1!
authby=secret
auto=add

conn win
left=192.168.1.53
leftprotoport=udp/1701
right=%any
type=transport
authby=secret
ike=aes256-sha1-modp2048!
auto=add

# cat /usr/local/etc/ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
192.168.1.53 192.168.1.54 : PSK "1234567890_dp1"
192.168.1.53 192.168.1.55 : PSK "1234567890_dp2"
192.168.1.53 %any : PSK "1234567890"


в прошлом я рассматривал настройку mpd и radius - настройка аналогична, не забудте только что mpd5 и radius запущены на разных машинах - надо подправить файлик clients.conf.

настройка unbound очень проста - в комплекте идет файл с примером конфигурации - фактически нам нужно только указать к каким интерфейсам цеплятся, и кому разрешено пользоватся.

dhcpd - тоже довольно просто - нужно описать все интерфейсы или сразу сказать к какому интефейсу цеплятся в rc.conf, что рекомендуется. после чего описать сеть в файле конфигурации - тоже есть примеры в комплекте.

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

FreeBSD: MySQL каждому

#FastCGI #Nginx

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

хотя и несовсем по-смылу - я использовал процедуры в MySQL. кострукции типа:
DELIMITER //
CREATE PROCEDURE del_login(lid int)
BEGIN
start transaction;
DELETE FROM l2tp, lnk_l2tp USING l2tp, lnk_l2tp
WHERE l2tp.id = lnk_l2tp.l2tp_id AND l2tp.id = lid ;
commit;
END //

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

внимание вопрос: чем принципиально отличается php от JavaScript? вобще говоря практически ничем. принципиальное отличие, которое делвет php популярным - можно работать с БД.

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

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

т.е ей пришла команда del_login с аргументом 10 она выполнила сall del_login(10) и результат выполнения команды запоковала бы в JSon и оправлен клиенту. формат может быт какой-нибуть стандартезиованный.

т.е. между MySQL и JavaScript приложение пользователя есть маленкий посредник. я планировал использовать для этой прокладки FastCGI и Nginx.

для разработки приложения на JavaScript нужна еще вспомогательная библиотека для разработки самого приложения, в которой сделать стандартные окна, элементы управления и прочую дрибедень для работы с сервером, чтобы просто не писать это каждый раз заного. для обмена данными с сервером вполне подойдет XMLHttpRequest. т.е. это немного пропаченный Ajax, даже я бы сказал облегченный.

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

хотя конечно можно сделать специализированый сервер на базе того же nginx который будет тупо дергать процедурки. можно добится довольно высокой скоросто, обеспечив обычнону JavaScript-приложению практически полноценный доступ к SQL - такой вот rpc.

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

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

FreeBSD, напористый гусь и все все все

#FreeBSD #mpd5 #StrongSwan #Mysql #FreeRADIUS

применем технологии PR - не толькоже ТомуКогоНельзяНазвать  пиарится. впринципе настройка StronSwan довольно простая - если не загдядывать в директорий(ю) /usr/local/etc/strongswan.d/. осталось прикрутить все остальное. в предыдущей заметке я расказывал про racoon который больше не поддерживатся разработчиками. попробуем немного все привести в более потребное состояние.

в IPsec прежде всего вам надо понимать разницу между тунельным и транспортным режимом. некоторые (и я наступал на эти грабли) думают что например l2tp - туннель значит и IPsec должен работать в туннельном режиме.

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

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

тут можно наступить вот на какие грабли. NAT редактирует заголовки т.е. был 192.168.1.128 стал 80.80.200.221

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

вот такие сложности. но сдругой стороны IPSec в транспортном режиме по барабану, что шифровать. вы можете использовать например GRE в чистом виде, да вообще любой тип туннеля какой вам придет в голову - можите зашифровать соджержимое ping. можно, не знаю, майкрософтовский pptp для верности завенуть в IPSec.

StronSwan довольно наворочиный набор - нас интересует реализация IKE до недавнего времени за реализацию IKE отвечали разные демоны. сейчас charon реализует версии IKE v1 и v2. те. вобщем-то нужен только он. его настройка довольно проста

# cat /usr/local/etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file
conn win
 left=192.168.1.54
 leftprotoport=udp/1701
 right=%any
 ike=aes256-sha1-modp2048!
 type=transport
 authby=secret
 auto=add

# cat /usr/local/etc/ipsec.secrets
# ipsec.secrets - strongSwan IPsec secrets file
192.168.1.54 %any : PSK "1234567890"


здесь left и right это селекторы трафика. т.е. обозвать секцию вы можите как угодно, важно какой трафик выбирается. хорошая мнемоника - первые буквы l - локал.

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

left=192.168.1.54
 leftprotoport=udp/1701
 right=%any


т.е. 192.168.1.54 - это адрес который слушает l2tp сервер. подключатся можно с любого адреса, выбираем выбираем l2tp.

можно конечно добавить что-то типа keyexchange=ikev2, но всетаки его далеко не все умеют. по этой самой причине написано ike=aes256-sha1-modp2048! эта такая попытка защитить ike1 в случае клинта windows10. хотя конечно соблазн исползовать только IKE v2 должен быть. вощем-то никто не мешает вам навешать целую кучу alias и применить политики по нужным вам принципам.

отлаживать удобно при помощи swanctl

# swanctl -L
win: IKEv1/2, reauthentication every 10260s, no rekeying
local: 192.168.1.54
remote: %any
local pre-shared key authentication:
id: 192.168.1.54
remote pre-shared key authentication:
win: TRANSPORT, rekeying every 3060s
local: dynamic[udp/l2f]
remote: dynamic


наблюдать ход подключени можно при помощи swanctl -T настраиваем L2TP. во FreeBSD лучший наверное MPD5

# cat /usr/local/etc/mpd5/mpd.conf
startup:
set user foo bar admin
set user foo1 bar1
set console self 127.0.0.1 5005
set console open
set web self 0.0.0.0 5006
set web open

default:
load l2tp_server

l2tp_server:
set ippool add pool1 10.0.0.1 10.0.0.255

create bundle template B
set ipcp ranges 10.10.10.1/32 ippool pool1

create link template L l2tp
set link action bundle B
set link enable multilink
set link no pap chap eap
set link enable chap
set l2tp self 192.168.1.54
set link enable incoming

# cat /usr/local/etc/mpd5/mpd.secret
test "ttt"


я собираюсь прикрутить радиус, но начните с файлика mpd.secret - так проще. отладили - прикуручивыаем MySQL и radius. кстати у меня винда фигово реагирует на надписи типа set iface route 10.10.0.0/16 или это только на стороне сервера? впрочем неприятность эту легко обойти, если поставить галочку  в винде "добавление маршрута на основе класса", тогда она всю 10/8 зароутит через подключение. т.е на клиенте можно сохранить маршрут по умолчанию - т.е. на клиенте не отвалится интернет или его не надо будет гонять через приватную сеть. вряд ли такая уж прям необходимость сидеть еще в каком-то куске 10/8

с вводной часть вроде бы все. попродуем не утонуть в логинах и пысвордах. у нас будут старые, которые будут выдыхаться через 30 дней - значит некуда без SQL - я буду использовать MySQL. и я не буду все сваливать в одну таблицу. сделаем что-то по-приличнее:

CREATE DATABASE personnel CHARACTER SET= utf8;
USE personnel;

CREATE TABLE `persons` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`name` CHAR(50) NOT NULL,
`post` CHAR(50) NOT NULL,
PRIMARY KEY(`id`));

CREATE TABLE `lnk_l2tp` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`prs_id` INT UNSIGNED NOT NULL,
`l2tp_id` INT UNSIGNED NOT NULL,
PRIMARY KEY(`id`));

CREATE TABLE `l2tp` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`created` DATETIME DEFAULT CURRENT_TIMESTAMP,
`username` CHAR(15) NOT NULL,
`psswd` CHAR(15) NOT NULL,
`groupname` CHAR(8) DEFAULT 'l2tp',
PRIMARY KEY(`id`));

CREATE TABLE `atrs` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`atr` varchar(64) NOT NULL,
`op` char(2) DEFAULT ':=',
PRIMARY KEY(`id`));

DELIMITER //
CREATE PROCEDURE add_login(uid int, lgn CHAR(15), psswd CHAR(15))
BEGIN
start transaction;
INSERT INTO l2tp (username, psswd) VALUES (lgn, psswd);
INSERT INTO lnk_l2tp (prs_id, l2tp_id) VALUES (uid, LAST_INSERT_ID());
commit;
END //
CREATE PROCEDURE show_login(uid int)
BEGIN
SELECT persons.name, l2tp.username, l2tp.created FROM persons, lnk_l2tp, l2tp
WHERE persons.id = lnk_l2tp.prs_id AND l2tp.id = lnk_l2tp.id AND persons.id = uid;
END //
CREATE PROCEDURE del_login(lid int)
BEGIN
start transaction;
DELETE FROM l2tp, lnk_l2tp USING l2tp, lnk_l2tp
WHERE l2tp.id = lnk_l2tp.l2tp_id AND l2tp.id = lid ;
commit;
END //
DELIMITER ;

GRANT SELECT on personnel.l2tp TO radius@localhost IDENTIFIED BY 'megapass' ;
GRANT SELECT on personnel.atrs TO radius@localhost IDENTIFIED BY 'megapass';
INSERT INTO atrs (atr) VALUES ('Cleartext-Password');

INSERT INTO persons (name, post) VALUES ('ТотКогоНельзяНазвать', 'PR-менеджер');
call add_login (1, 'test_login', 'test_password');



как не трудно догадатся, объявлена процедура add_login которая принимает значениие ID в persons, логин и пысворд. например так call add_login(1, 'login', 'password'); также есть и процедура show_login(uint) которая показывает логины у данного пользователя. del_login(uint) трет логин с данным id, без попыток повлиять на таблицу persons. приличноcть кстати заключается не в навороченности и использовании хранимых процедур, а в том что, базу легко расширить и прикручен инткрфейс пользователя - не надо вбивать километровые запросы.

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

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

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

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

гастройка freeradius c sql

# cd /usr/local/etc/raddb/mods-enabled/
#ln -s ../mods-available/sql sql


далее говорим, что хотим авторизацию черзsql - в файле /usr/local/etc/raddb/sites-available/default в секции авторизации должно быть sql

дальше я обычно делаю так: добавляем добавляем сервер в файли clients

# cat /usr/local/etc/raddb/clients.conf
client localhost {
ipaddr = 127.0.0.1
proto = *
secret = topsecret
require_message_authenticator = no
nas_type = other
}


дальше нужно прикинутся сервером и проверить, что все хорошо - для этого есть замечательная утилитка radtest. в одном терминале radiusd -X в другом

# -t chap login password localhost 0 topsecret
Sent Access-Request Id 249 from 0.0.0.0:47213 to 127.0.0.1:1812 length 76
User-Name = "login"
CHAP-Password = 0x62427b1c1ea7250a6e99425ef299e6d5b1
NAS-IP-Address = 5.9.62.207
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "password"
Received Access-Reject Id 249 from 127.0.0.1:1812 to 127.0.0.1:47213 length 20
(0) -: Expected Access-Accept got Access-Reject


т.е. нет такого пользователя, что логично - ломаем sql.

# cat /usr/local/etc/raddb/mods-enabled/sql

sql {
dialect = "mysql"
driver = "rlm_sql_mysql"
server = "localhost"
port = 3306
login = "radius"
password = "megapass"
radius_db = "personnel"
$INCLUDE ${modconfdir}/${.:name}/main/${dialect}/queries.conf
}


я не использвал TLS соединие  c MySQL, что плохо т.к. пысворды хранятся в чистом виде. их легко спереть если отслеживать соединние.

конечно если поджечь радиус, он матюкнется на переменные типа authcheck_table которые были - ну уберите их из /usr/local/etc/raddb/mods-config/sql/main/mysql/queries.conf лучше всего заменить их на -- . востановите работоспособность как в выводе radtest выше. заработало? ну OK - пишем свои запросы -  использование переменных как правило избыточно.в простейшем случае досточно этого:

# cat /usr/local/etc/raddb/mods-config/sql/main/mysql/queries.conf
sql_user_name = "%{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}}"

authorize_check_query = "SELECT l2tp.id, l2tp.username, atrs.atr AS attribute, l2tp.psswd AS value, atrs.op \
FROM l2tp, atrs \
WHERE l2tp.username= '%{SQL-User-Name}' AND \
atrs.atr= 'Cleartext-Password' AND \
NOW() - l2tp.created < 2592000"

group_membership_query = "SELECT groupname \
FROM l2tp \
WHERE username = BINARY '%{SQL-User-Name}'"


конечно если у вас в файлике default не накручено. можно все упростить и убрать все ненужное:

# cat /usr/local/etc/raddb/sites-enabled/default
server default {
listen {
type = auth
ipaddr = 127.0.0.1
port = 0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}

authorize {
filter_username
preprocess
sql
chap
}

authenticate {
Auth-Type CHAP {
chap
}
}

}



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

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

# radtest -t chap test_login test_password localhost 0 topsecret
Sent Access-Request Id 89 from 0.0.0.0:62867 to 127.0.0.1:1812 length 81
User-Name = "test_login"
CHAP-Password = 0x0a14203d11b1bd23e716b15372a747342d
NAS-IP-Address = 5.9.62.207
NAS-Port = 0
Message-Authenticator = 0x00
Cleartext-Password = "test_password"
Received Access-Accept Id 89 from 127.0.0.1:1812 to 127.0.0.1:62867 length 20


достут разрешен? ну все ок. можно еще специально испортить логин или пысворд и убедится, что пускать радиус отказываетя. прикрутить mpd5 тоже просто:

# cat /usr/local/etc/mpd5/mpd.conf
startup:
set user foo bar admin
set user foo1 bar1
set console self 127.0.0.1 5005n

default:
load l2tp_server

l2tp_server:
set ippool add pool1 10.0.0.1 10.0.0.255

create bundle template B
set ipcp ranges 10.10.10.1/32 ippool pool1

create link template L l2tp
set link action bundle B
set link enable multilink
set link no pap chap eap
set link enable chap-md5
set l2tp self 192.168.1.54
set link enable incoming

set auth max-logins 1
set auth enable radius-auth
set auth disable internal
set radius server 127.0.0.1 topsecret


запускаем в разных терминалах радиус и мпд. коннектимся с винды. все должно быть ок. можно прорепитировать ситуацию двойного логина и радоватся надписи в выводе mpd5 AUTH: Name: "test_login" max. number of logins exceeded

если все нормально - чистим радиус от лишних модулей добавляем в автозапуск MySQL SrongSWan FreeRadius mpd5.

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

FreeBSD l2tp IPsec сервер + windows

#l2tp #IPsec #FreeBSD #windows

ну вот добрался я до IPsec. вообще конечно существует много разных инструкций, которые можно просто переписать - большинство из них рабочие. но я призываю все же начать откуда-нибудь отсюда. нужно хотябы понимать что такое IKЕ впринципе. не поленитесь - прочитайте хотя бы это, то пишут альтернативно одаренные - "почему люблю IKE v2 больше других vpn" - хочется ответить - а я вот вот всегда предпочитаю использовать езернет, а не ms-chap.

некоторые думают, что настроил IPsec + туннель - у вас непробиваемая система. чтобы хотя бы подойти к этому, нужно минимум правильно настроить фильтрацию пакетов,  однако статья в "хакере" описывает вполне реализуемый метод атаки даже в этом случае.

т.е. сам по сибе IPsec не гарантирует "непробиваемость". конечно можно сказать - нуда мы все поняли - нужно просто использовать IKE v2.

вобщем-то вывод-то вполне сибе, IKE v2 есть в StrongSwan, а старый добрый racoon - это IKE v1 хотя конечно там применены некоторые улучшения. хотя конечно использование напористого гуся рекомендутся.

# racoon -V
@(#)ipsec-tools 0.8.2 (http://ipsec-tools.sourceforge.net)

Compiled with:
- OpenSSL 1.1.1h-freebsd  22 Sep 2020 (http://www.openssl.org/)
- IPv6 support
- Dead Peer Detection
- IKE fragmentation
- Hybrid authentication
- NAT Traversal
- Admin port
- Monotonic clock


ну что же поговоим о второй части - MPD5 - очень шустрая штука. я помню в юности разгонял BRASS PPPoE до полугигабита, а при этом PPPoE довольно мелко нарезались по скорости и дополнительно собирал цепочки netgraph c натом и нетфлоу, причем трафик анализировал в две стороны. и упирался не столько в производительность сколько в ширину канала.

для начало установим наши основные компоненты

ipsec-tools и mpd5
# uname -a
FreeBSD ********** 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC amd64


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

cat /usr/local/etc/mpd5/mpd.conf

startup:
       set user foo bar admin
       set user foo1 bar1
       set console self 127.0.0.1 5005
       set console open
       set web self 0.0.0.0 5006
       set web open

default:
       load l2tp_server

l2tp_server:
       set ippool add pool1 192.168.1.50 192.168.1.99

       create bundle template B
       set iface idle 1800
#       set iface enable tcpmssfix
       set ipcp yes vjcomp
       set ipcp ranges 192.168.1.1/32 ippool pool1
       set ipcp dns 192.168.1.3

       create link template L l2tp
       set link action bundle B
       set link enable multilink
       set link yes acfcomp protocomp
       set link no pap chap eap
       set link enable chap
       set link keep-alive 10 60
       set l2tp self 192.168.1.54
       set link enable incoming


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


# cat /usr/local/etc/mpd5/mpd.secret
test            "ttt"


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

ладно сейчас racoon.

# cat /usr/local/etc/racoon/psk.txt
192.168.1.36 1234567890
192.168.1.41 1234567890
192.168.1.55 1234567890

# cat /usr/local/etc/racoon/setkey.conf
flush;
spdflush;
spdadd 0.0.0.0/0[0] 0.0.0.0/0[1701] udp -P in ipsec esp/transport//require;
spdadd 0.0.0.0/0[1701] 0.0.0.0/0[0] udp -P out ipsec esp/transport//require;

# cat /usr/local/etc/racoon/racoon.conf
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

listen {
 isakmp 192.168.1.54 [500];
 isakmp_natt 192.168.1.54 [4500];
}

remote anonymous {
 exchange_mode main;
 proposal_check obey;
 support_proxy on;
 nat_traversal on;
 ike_frag on;
 dpd_delay 20;

 proposal {
  encryption_algorithm aes;
  hash_algorithm sha1;
  authentication_method pre_shared_key;
  dh_group modp1024;
  }

 proposal {
  encryption_algorithm aes;
  hash_algorithm sha1;
  authentication_method pre_shared_key;
  dh_group modp2048;
  }

}

sainfo anonymous {
 encryption_algorithm aes;
 authentication_algorithm hmac_sha1;
 compression_algorithm deflate;
 pfs_group modp1024;
}


как вы наверно уже поняли я просто скоммуниздил конфиг racoon из ссылки выше - я быстро поробывал поигратся с параметрами, но ничего путного не придумал. вобще конечно я усилить шифрование на фазе согласования ключей но фиг там. хотя я особо не настаивал - пробывал authentication_algorithm hmac_sha256 и pfs_group 2048 - путного ничего не вышло.

не забывайте про права доступа - т.к. все запущено с привязкой к терминалу - мы увидим как racoon матюкнется на "неправильные" права - как это побороть - как-нибуть догадаетесь.

запускаем все в разных теминалах

# mpd5
Multi-link PPP daemon for FreeBSD
process 1742 started, version 5.9
CONSOLE: listening on 127.0.0.1 5005
web: listening on 0.0.0.0 5006
L2TP: waiting for connection on 192.168.1.54 1701
[L]


в другом

# racoon -F
Foreground mode.
2021-01-29 11:46:40: INFO: @(#)ipsec-tools 0.8.2 (http://ipsec-tools.sourceforge.net)
2021-01-29 11:46:40: INFO: @(#)This product linked OpenSSL 1.1.1h-freebsd  22 Sep 2020 (http://www.openssl.org/)
2021-01-29 11:46:40: INFO: Reading configuration from "/usr/local/etc/racoon/racoon.conf"
2021-01-29 11:46:40: INFO: 192.168.1.54[4500] used for NAT-T
2021-01-29 11:46:40: INFO: 192.168.1.54[4500] used as isakmp port (fd=6)
2021-01-29 11:46:40: INFO: 192.168.1.54[500] used as isakmp port (fd=7)


ну чтоже бежим к винде. настраиваем там VPN - ставим L2TP с PSK  не забываем набить ключ. ключ кстати должен быть сложный 1234567890 - исключительно в демонстрационных целях. полезно ктати убрать маршрут по умолчанию, т.е. разрулить маршрутами интернет и приватную сеть.

кроме того, в настроках MPD5 я убрал proxyarp - тоже надо разрулить роутингом ну или давать клиентам адреса которые впринципе можно проксировать.

ну что же винда настроена - коннектимся

racoon говорит что-то типа такого

2021-01-29 11:57:01: INFO: respond new phase 1 negotiation: 192.168.1.54[500]<=>192.168.1.41[500]
2021-01-29 11:57:01: INFO: begin Identity Protection mode.
2021-01-29 11:57:01: INFO: received broken Microsoft ID: MS NT5 ISAKMPOAKLEY
2021-01-29 11:57:01: INFO: received Vendor ID: RFC 3947
2021-01-29 11:57:01: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2021-01-29 11:57:01: INFO: received Vendor ID: FRAGMENTATION
2021-01-29 11:57:01: [192.168.1.41] INFO: Selected NAT-T version: RFC 3947
2021-01-29 11:57:01: ERROR: invalid DH group 20.
2021-01-29 11:57:01: ERROR: invalid DH group 19.
2021-01-29 11:57:01: [192.168.1.54] INFO: Hashing 192.168.1.54[500] with algo #2
2021-01-29 11:57:01: INFO: NAT-D payload #0 verified
2021-01-29 11:57:01: [192.168.1.41] INFO: Hashing 192.168.1.41[500] with algo #2
2021-01-29 11:57:01: INFO: NAT-D payload #1 verified
2021-01-29 11:57:01: INFO: NAT not detected
2021-01-29 11:57:01: [192.168.1.41] INFO: Hashing 192.168.1.41[500] with algo #2
2021-01-29 11:57:01: [192.168.1.54] INFO: Hashing 192.168.1.54[500] with algo #2
2021-01-29 11:57:01: INFO: Adding remote and local NAT-D payloads.
2021-01-29 11:57:01: INFO: ISAKMP-SA established 192.168.1.54[500]-192.168.1.41[500] spi:107eb4b98c266371:16c713b1881b36dd
2021-01-29 11:57:01: INFO: respond new phase 2 negotiation: 192.168.1.54[500]<=>192.168.1.41[500]
2021-01-29 11:57:01: INFO: IPsec-SA established: ESP/Transport 192.168.1.54[500]->192.168.1.41[500] spi=85461756(0x5180afc)
2021-01-29 11:57:01: INFO: IPsec-SA established: ESP/Transport 192.168.1.54[500]->192.168.1.41[500] spi=3102607180(0xb8ee074c)

выглядит неплохо. вывод MPD5 писать не буду - там обычно проблем не возникает. главное читайте что программы пишут. ну и конечно после того как мы все отладили надо сказать в rc.conf волшебные слова. кстаи  IPsec работает в ядре, а racoon это реализация IKE, так что для отладки тоже нужны волшебные слова.
все лгут

FreeBSD DE и не только

навсамом деле если вы прочитаили и смогли настроить KMS и подключение к интернету писать здесь особо неочем.

так что поставлю пока картинку - че придумаю напишу

вооще мне хочется написать о более сложной задачи - mpd5 l2tp server + IPSec клиенты windows - актуальная задача была до недавнего времени. вцелом если её упростить - не использовать radius и mysql  она достаточно простая.
так что держите обещанный скиншот, а я  наверное буду думать, что писать про l2tp.

Scr1.png