Открыть список
Как стать автором
Обновить
8
Карма
0
Рейтинг
Луконин Кирилл @Klukonin

Злой Беспроводник (EvilWirelessMan)

В черную металлургию за реальными делами: опыт Datana

Кому сегодня нужно это старьё?

SpaceX запретила сотрудникам использовать программу Zoom

А ещё нужно учитывать, что когда участники конференции не активны, им достаточно передавать пониженное разрешение для демонстрации thumbnail. И что, как правило, активный участник в конференции только один.
В таком случае P2P связность уже не кажется такой громоздкой.

SpaceX запретила сотрудникам использовать программу Zoom

Это не совсем верно. В данном случае вы описали схему которая первой приходит в голову и так действительно НЕ нужно делать.
В реальности существуют разные схемы. Ну, например вот тут можно почитать.
www.akamai.com/uk/en/multimedia/documents/technical-publication/multi-rate-peer-to-peer-video-conferencing-a-distributed-approach-using-scalable-coding-technical-publication.pdf

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

Четвертушка Ethernet-а: старая скорость, новые возможности

Зашёл написать этот комментарий.

Все полезные материалы по Wi-Fi в одном месте

Добавь пожалуйста зеркало от WiCat

wikidevi.wi-cat.ru/Main_Page

Оптимизация беспроводного подключения или iwconfig может всё

Я буду смотреть дату статьи перед комментарием!
Я буду смотреть дату статьи перед комментарием!

Оптимизация беспроводного подключения или iwconfig может всё

Зачем в 2019 году использовать iwconfig когда есть iw?
Что дальше? Статьи о том как правильно пользоваться ifconfig?

tinc-boot — full-mesh сеть без боли

Проблема WireGuard в том что это исключительно TUN (L3). В то время как TINC умеет и TUN (L3) и TAP (L2).
Работает в пространстве ядра (модуль).


Проблема Tinc в том что он прибит гвоздями к OpenSSL.
Работает в пространстве пользователя (демон).


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

tinc-boot — full-mesh сеть без боли

Я считаю что есть смысл добавить это в стаью. Собствено, ради этого и я вступил в дискуссию, пытаясь хоть как-то указать на неконструктивность подхода "because I can" и недостаточно глубокое изучение вопроса.


Три момента заслуживающих внимания читателей:
1) В серсии 1.1 данная вункциональность уже реализована из коробки.
2) Методы аутентификации в версии 1.1 более безопасны, но обратно не совместимы с 1.0 и бэкпортированы не будут никогда.
3) Исходя из официальной документации 1.0 версия считается legacy, хотя для нее и выходят корректирующие релизы (прямо как gnupg, правда?) и тем кто заботится о безопасности следовало бы присмотреться к механизму инвайтов и новой версии Tinc.

tinc-boot — full-mesh сеть без боли

А почему вы считаете что можно забить на PFS и пользоваться legacy схемой когда перехват/кража ключа позволяет расшифровать ВЕСЬ собранный до этого трафик?
Это приемлемо во славу стабильного релиза?

tinc-boot — full-mesh сеть без боли

  1. Одно из. Тут напрашивается картинка про конкурирующие стандарты. Вы просто сделали "свое". И при этом не решили никакой проблемы. Потому ваш результат заслуживает порицания.
  2. В статье описывается метод, прибитый гвоздями к устаревшей версии. С тем же успехом вы могли бы написать библиотеку, прибитую гвоздями к python 2.7 и при этом имеющуюся в версии 3.
    Вы бы тоже утверждали что писали осознанно под 2.7 и явно ограничили это в статье, а критика подобного это "вне контекста"?
    Нет, милейший, вы решили выложить свои наработки в открытый доступ и даже написали статью. "Выйти и поговорить" это другой формат, будьте готовы пояснить за свое решение публично
  3. Вы ничего не обосновали. Все ваши доводы из разряда "потому что могу". Сравнения версий не проводилось, объективных аргументов в пользу выбора версии не приводилось. Только ваши фантазии и страхи.

Вы пытаетесь опровергнуть то чего я не говорил.
Вы ПОДТАЛКИВАЕТЕ пользователей к использованию менее безопасного протокола. И это даже еще хуже чем если бы вы что-то утверждали. Потому что в таком случае можно было бы оспорить или опровергнуть утверждения. А тут вы просто даете инструмент, который заведомо deprecated и еще вдобавок РЕАЛЬНО снижает безопасность решения вцелом. Но при этом он позиционируется как "то что избавит вас от боли".


Осознанно или по незнанию, но вы сделали ужасную вещь.

tinc-boot — full-mesh сеть без боли

Бэкпорт о котором речь попал туда пол года надаз, а до этого, соответствено присутствовал в версии 1.1.


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


Пройдите сюда и посмотрите что это за релиз
https://github.com/gsliepen/tinc/commits/master


Хватит мыслить как школьник и фапать на циферки.
Посмотрите к чему это привело. Я уже высказывался выше.
1) Дублирование функциональности
2) Навязывание пользователем устаревшего и менее безопасного протокола.

tinc-boot — full-mesh сеть без боли

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


И все это сознательно, исключительно на поводу у собственных предрассудков, раз вы в курсе про существование версии 1.1.


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

tinc-boot — full-mesh сеть без боли

Это очень однобокое оправдание.
Не напомните сколько раз за этот год выходили патчи стабильной openssl?
Как же так, ведь это проверенное решение?


Tinc 1.0 по части механизмов аутентификации именно фундаментально уступает 1.1.
Потому мое сравнение с пыльной полкой и кактусом как раз кстати, я не просто так это написал.


В использовании RC нет ничего плохого. OpenWrt (как пример) последние стабильные релизы выпускали на основе ветки wireless-testing или backports в статусе RC.
Ubuntu уже много лет тащит пакеты из debian testing и experimental. Так что про риски и прочие это не более чем притянутые за уши аргументы.
Завтра случится очередной heartbleed и что, это повод не использовать новые "непроверенные" версии opensssl и сидеть на 1.0 ?


LibreOffice регулярно релизятся, а потом дают отмашку о том с какой минорной версии по их мнению "можно в продакшен".
Так что я вам рекомендую перестать фиксироваться на цифрах и смотреть больше на стабильность API. В этом плане Tinc 1.1 давно созрел.
А вот чтобы говорить об ограничениях, нестабильности или недостаточной готовности той или иной версии, требуется как минимум изучить примеры использования других людей, а ещё лучше приложиться самому и тоже протестировать. В таком случае это будет предметный разговор.
А сидеть на стуле и рассуждать "ну, они что-то не релизят и я опасаюсь" — это, пардон, балобольство.
Изменение циферки в версии это не причина того на сколько ПО стабильно, а следствие.

tinc-boot — full-mesh сеть без боли

К слову, версия 1.1 на данный момент есть даже в debian experimental. Не говоря о ppa и с сторонних репозиториях.

tinc-boot — full-mesh сеть без боли

Грубо говоря, вы сосредоточились на версии 1.0 в которой применяется устаревший тип аутентификации и отсутствует поддержка
эллиптики.
А так же отказались от механизма инвайтов который делает ровно то же самое что и ваш сервис.
То есть, фактически, вы взяли с пыльной полки кактус и героически его съели.


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


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


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

Беспроводная эволюция, или Почему Wi-Fi 5 скоро отправится в музей технологий

Я понимаю, что вендоры любят кормить всех вкусными сладкими прогнозами, рассказывать о том как космические корабли бороздят Большой театр, а так же называть маркетинговые максимумы технологий, умалчивая об их применимости в реальной жизни. Дак вот, реальная жизнь горькая и это нужно учитывать.
802.11n зашёл на рынок десять лет назад, 802.11ac пять лет назад. И при этом 802.11n пока более чем актуален Плюс, пользователи стали реже менять свои мобильные устройства, об этом говорит статистика последних лет.
Значит ближайшие 5 лет точно никаких улучшений от Wi-Fi 6 можно не ждать. Все будет упираться в обратную совместимость. И только ближе к 2030 году мы повсеместно (а не в отдельно взятых сетях) увидим реальный профит от OFDMA.


Вся надежда на 60Ггц который не был освоен и там нет бремени обратной совместимости.
То есть, 802.11ad и 802.11ay


Такие дела.

Информация

В рейтинге
6,017-й
Откуда
Екатеринбург, Свердловская обл., Россия
Дата рождения
Зарегистрирован
Активность