Ну лет 10-15 назад была куча виндовых планшетов на Atom'ах N-серии. Но Интел просто перестала делать такие процессоры - и весь класс устройств просто вымер.
О чём вы вообще, рынок завален ноутбуками, convertable и мини-ПК на N95/N97/N100. Ренессанс.
Винда до сих пор занимает бОльшую часть рынка десктопов, при этом запускать на армах её просто негде, никаких арм-устройств нет в продаже за исключением Surface.
Еще Lenovo, Samsung. Меня несколько раз спрашивали про goodbyedpi под Windows ARM, а это софт с, может, 500 тысячами пользователей максимум. Это не гипотетическое пожелание, а люди на своих ARM-ноутбуках пытались запустить, и у них не заработало.
P.S. решил на выходных полноценно научиться работать с рейдом, начал экспериментировать, спустя 20 минут у меня уже локнулось ядро (ссылка 1). Ну, подумал, конфигурацию сделал нестандартную, опять edge case'ы не напрограммировали, с кем не бывает. Пошел читать mail list, а там у людей raid1 читает старые несинхронизированные данные с диска и разваливается посреди бела дня, а быстрое копирование файлов приводит к зависанию raid6, и всё это случается не на каких-то только из печи -rc, а результат работы одной из старейших и основополагающих подсистем ввода-вывода на стабильных версиях.
Мой основной интерес это роутеры, которые могут использовать в основном суммаризованные списки IP адресов
Блокировки осуществляются по доменам, и маршрутизировать их нужно по доменам. Однако маршрутизация так не работает. Все пытаются использовать существующие неподходящие инструменты, и не могут выбраться из этой парадигмы. Сбор IP-адресов — бесперспективное занятие, даже в сравнении с альтернативными, не менее костыльными методами.
На этом этапе (step 2 в исходниках) проверялось два основных критерия -
Доступность сайта по одному из способов - ping, http, https
Увы, не всегда сработает с доменами, заблокированными по *.зоне — на корневом домене может не быть записей, но домен при этом может активно использоваться. Либо же домен может не отвечать на ICMP и стандартные порты.
3-ий этап [...] был самым ресурсозатратным, по сути похож на первый, но на этом этапе нужно отфильтровать в том числе припаркованные домены и сайты с нормальными доменами, но бесполезным содержимым
Если совместить однократное/редкое сканирование по ключевым словам внутри страницы, а из результатов сделать список NS/IP, то процесс значительно ускорится.
В этом случае также разумно применить уплощение до зоны, это уменьшит количество доменов.
По итогам этого этапа осталось 41598 доменов
Ваш вариант со сканированием ключевых слов выглядит эффективным. Анализировали ли вы ложноположительные срабатывания? Список получился подозрительно маленьким.
В Flappy Bird Foundation сообщили, что выкупили все права на игру.
Нет, они подали заявление в патентное бюро, что торговая марка не используется, бюро это подтвердило без ответчика (оригинального автора Flappy Bird, Dong Nguyen), а после Gametech Holdings LLC заново зарегистрировали торговую марку за собой.
Профиль ИБ настолько широкий, что я затрудняюсь представить, о поиске специалистов какого конкретно направления он говорит. Может быть SOC, может аудиторов, может ещё кого.
Можно поднять 6to4-туннель, если у вас пингуется IPv4-адрес 192.88.99.1. Алгоритм примерно такой же, только в качестве IP-адреса remote указываем 192.88.99.1, а в качестве IPv6-адресов используем рассчитанный из вашего IPv4-адреса.
6to4 давно deprecated, поэтому работать может не везде. Кроме того, клиентам локальной сети необходимо раздавать какой-либо публичный диапазон (можно 2001:0DB8::/32, зарезервированный для документации и примеров), иначе он почти никогда не будет использоваться из-за низкого приоритета 6to4-адресов (ниже, чем у IPv4). Для раздачи придётся использовать one-to-one NAT (без состояния и трансляции портов).
Вторая причина — .deb-пакеты в Debian сжаты lzma (xz), и распаковываются не только долго, но еще и в один поток. Современные версии Ubuntu используют zstd с многопотоковым распаковщиком, но не Debian. Исправить можно кастомным dpkg, запускающим pixz отдельным процессом, но решение не идеальное.
Можно поднять 6to4-туннель, если у вас пингуется IPv4-адрес 192.88.99.1. Алгоритм примерно такой же, только в качестве IP-адреса remote указываем 192.88.99.1, а в качестве IPv6-адресов используем рассчитанный из вашего IPv4-адреса.
В прошлом месяце потратил некоторое время на отладку загадочных проблем с протоколами автоматического обнаружения через Wi-Fi: проблема была в старом маршрутизаторе, или, точнее, несовместимости (предположительно глючной) прошивки/чипа Wi-Fi маршрутизатора и чипа Wi-Fi устройства.
Если ваш принтер постоянно подключен к сети (и вы это видите в веб-интерфейсе роутера), но его обнаружение в сети работает только ровно 1 час, 1 день или другое круглое время, попробуйте:
Проверить маршрутизатор на наличие опции мультикаста и IGMP Snooping
Сменить режим безопасности Wi-Fi на "WPA-PSK/WPA2-PSK Mixed"
Отключить смену ключа GTK (группового ключа)
Создать отдельную (но не изолированную) сеть только для принтера
Протоколы автоматического обнаружения (mDNS/DNS-SD) используют мультикаст, который работает не так тривиально через Wi-Fi по сравнению с проводной сетью.
Wi-Fi использует разные алгоритмы шифрования и разные ключи шифрования для юникаст и широковещательного/мультикаст-трафика: индивидуальные ключи шифрования для каждого клиента для обычного юникаст-трафика (pairwise key) и отдельный общий ключ шифрования для группового трафика (group key) для броадкаст и мультикаст-трафика.
Оказывается, при некоторых условиях могут возникнуть проблемы с многоадресной рассылкой. Драйверы Intel Wi-Fi в Windows неправильно обрабатывают мультикаст-трафик после отправления компьютера в сон, а точки доступа Ubiquiti известны неправильной обработкой GTK.
Что касается IGMP Snooping: некоторые точки доступа требуют, чтобы устройство присоединилось к группе многоадресной рассылки mDNS для получения запросов mDNS. Большинство точек доступа пересылают запросы mDNS независимо от того, был ли запрос на присоединение к multicast-группе, или нет, но некоторые этого не делают или обрабатывают multicast неправильно.
Простите, я не знаю, что такое "wifi router первого звена". Все устройства (в т.ч. и роутеры, и клиенты) в моей LAN равноправны, они все в одном L2-сегменте. Все Wi-Fi-сети, аналогично, в одном (общим с ethernet) L2-сегменте. Можно подключаться в любой ethernet-порт любого роутера, либо же по Wi-Fi, и получать ровно ту же конфигурацию. Это обычная домашняя сеть.
Я не использую ByeDPI. ByeDPI работает как прокси и не предназначен для обработки маршрутизируемого трафика — его разумно применять исключительно при невозможности использования nfqws (или любого другого инструмента, работающего по пакетам и интегрирующегося в маршрутизируемый трафик) вследствие технических ограничений прошивок роутеров. На Orange Pi таких ограничений нет.
Orange PI -> Orange PI WAN
Orange Pi подключается одним проводом. У него один сетевой интерфейс. Если вы WAN'ом называете вышестоящий шлюз, на который маршрутизируется трафик, то да.
Orange Pi выступает простым маршрутизатором. Он просто маршрутизирует пакеты, полученные от других клиентов, на вышестоящий шлюз. Ну, чуть их обрабатывая с помощью nfqws, но если на минуту забыть о нём, то это самый обычный простой маршрутизатор. Без NAT, без разных сетевых сегментов, без проверки отправителя. На нём нет DHCP, нет DNS. Всё, что делает маршрутизатор при получении пакета от клиента — заменяет MAC-адрес отправителя на свой MAC, MAC-адрес назначения на MAC вышестоящего роутера, и пересылает пакет. Всё. nfqws дополнительно делает свою магию, но на непосредственно маршрутизацию это не влияет.
Но это не соответствует картинке!
Картинка нарисована для описания бага nftables, связанного с маршрутизацией внутри логического бриджа (который может состоять хоть из одного физического интерфейса, но в моём случае объединяет несколько физических портов и Wi-Fi-точку).
Стрелочки на картинке показывают путь одного исходящего пакета, отправленного с компьютера в интернет. Это не схема сети!
но не понятно его назначение (почему бы сразу не передать в WAN провайдеру с Orange PI)
Статья рассказывает об обходе блокировки дополнительным устройством в локальной сети, а не об установке обхода на роутер. Я привёл пример похожей конфигурации, более простой в настройке.
Такая конфигурация не требует ни изменения настроек на роутере (изменение dhcp option 3 не обязательно, с ним просто не придётся перенастраивать клиентов), ни перестройки физической топологии, ни замены роутера на более продвинутый. Она совместима даже с самыми базовыми моделями домашних роутеров, где нет никаких дополнительных возможностей.
Я всё настраивал удалённо и исходил из особенностей и ограничений существующей сети — невозможности установки nfqws на main router, из-за чего счёл перемаршрутизацию всего трафика через дополнительный маршрутизатор самой простой конфигурацией и меньшим из зол, хоть и не оптимальным по топологии, зато гарантированно надёжной в плане разблокировки. Если у вас есть возможность настроить обход блокировок на основном/единственном роутере — делайте на нём, конечно!
О чём вы вообще, рынок завален ноутбуками, convertable и мини-ПК на N95/N97/N100. Ренессанс.
Еще Lenovo, Samsung. Меня несколько раз спрашивали про goodbyedpi под Windows ARM, а это софт с, может, 500 тысячами пользователей максимум. Это не гипотетическое пожелание, а люди на своих ARM-ноутбуках пытались запустить, и у них не заработало.
А сколько в России теперь пользователей IPv6-то, уух!
Мейнтейнер подсистемы RAID в Linux — Huawei.
Ну, технически, ревьюер, но вы понимаете.
https://lore.kernel.org/linux-raid/CAPhsuW72021iJDQp1HnJycpkp2GQOFvL9MGWGQ1LvMbr9-bWoQ@mail.gmail.com/
https://github.com/gregkh/linux/blob/42f7652d3eb527d03665b09edac47f85fb600924/MAINTAINERS#L21306
Hidden text
P.S. решил на выходных полноценно научиться работать с рейдом, начал экспериментировать, спустя 20 минут у меня уже локнулось ядро (ссылка 1). Ну, подумал, конфигурацию сделал нестандартную, опять edge case'ы не напрограммировали, с кем не бывает. Пошел читать mail list, а там у людей raid1 читает старые несинхронизированные данные с диска и разваливается посреди бела дня, а быстрое копирование файлов приводит к зависанию raid6, и всё это случается не на каких-то только из печи -rc, а результат работы одной из старейших и основополагающих подсистем ввода-вывода на стабильных версиях.
Блокировки осуществляются по доменам, и маршрутизировать их нужно по доменам. Однако маршрутизация так не работает. Все пытаются использовать существующие неподходящие инструменты, и не могут выбраться из этой парадигмы. Сбор IP-адресов — бесперспективное занятие, даже в сравнении с альтернативными, не менее костыльными методами.
Возможные решения описал здесь: https://ntc.party/t/варианты-маршрутизации-отдельных-доменовпрограмм-в-vpn/11408
См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/master/config/exclude-regexp-dist.awk, здесь ключевые слова, которые отсеят зеркала, присутствующие в вашем списке.
Увы, не всегда сработает с доменами, заблокированными по
*.зоне— на корневом домене может не быть записей, но домен при этом может активно использоваться. Либо же домен может не отвечать на ICMP и стандартные порты.Один из вариантов оптимизации фильтра припаркованных доменов — по именам из NS-записей или по IP-адресам ответов. См. https://bitbucket.org/anticensority/antizapret-pac-generator-light/src/1cef07bd0d6c17e9668e244925c32af100aa97be/scripts/resolve-dns-nxdomain.py#lines-28
Это быстрее, но необходимо вручную собрать адреса парковочных страниц/NS.
Если совместить однократное/редкое сканирование по ключевым словам внутри страницы, а из результатов сделать список NS/IP, то процесс значительно ускорится.
В этом случае также разумно применить уплощение до зоны, это уменьшит количество доменов.
Ваш вариант со сканированием ключевых слов выглядит эффективным. Анализировали ли вы ложноположительные срабатывания? Список получился подозрительно маленьким.
https://flibusta.is/comment/3561973#comment-3561973
В zlibrary книги хранятся в IPFS (это такой bittorrent для web). Сам же сайт не распределён.
https://github.com/ValdikSS/GoodbyeDPI/issues/378
Да откуда вы это берёте, и нахрена? То
-e 9.5посоветуют, то-11.Осторожно, это значение включает свежие Новости Шеремета с Владом Некрасовым!
Нет, они подали заявление в патентное бюро, что торговая марка не используется, бюро это подтвердило без ответчика (оригинального автора Flappy Bird, Dong Nguyen), а после Gametech Holdings LLC заново зарегистрировали торговую марку за собой.
https://ttabvue.uspto.gov/ttabvue/v?pnam=Dong Nguyen Ha
https://x.com/SamNChiet/status/1834246569857634352
Профиль ИБ настолько широкий, что я затрудняюсь представить, о поиске специалистов какого конкретно направления он говорит. Может быть SOC, может аудиторов, может ещё кого.
Можно поднять 6to4-туннель, если у вас пингуется IPv4-адрес
192.88.99.1. Алгоритм примерно такой же, только в качестве IP-адреса remote указываем 192.88.99.1, а в качестве IPv6-адресов используем рассчитанный из вашего IPv4-адреса.6to4 давно deprecated, поэтому работать может не везде. Кроме того, клиентам локальной сети необходимо раздавать какой-либо публичный диапазон (можно
2001:0DB8::/32, зарезервированный для документации и примеров), иначе он почти никогда не будет использоваться из-за низкого приоритета 6to4-адресов (ниже, чем у IPv4). Для раздачи придётся использовать one-to-one NAT (без состояния и трансляции портов).Основная причина медленной установки Debian/Ubuntu в медленной распаковке пакетов, вызванной чрезмерно частыми вызовами fsync().
Это можно отключить с помощью eatmydata.
https://www.linux.org.ru/news/debian/16195513
https://bitbucket.org/ValdikSS/debian-iso-fastinstall/src/master/
Вторая причина — .deb-пакеты в Debian сжаты lzma (xz), и распаковываются не только долго, но еще и в один поток. Современные версии Ubuntu используют zstd с многопотоковым распаковщиком, но не Debian. Исправить можно кастомным dpkg, запускающим pixz отдельным процессом, но решение не идеальное.
Можно поднять 6to4-туннель, если у вас пингуется IPv4-адрес
192.88.99.1. Алгоритм примерно такой же, только в качестве IP-адреса remote указываем192.88.99.1, а в качестве IPv6-адресов используем рассчитанный из вашего IPv4-адреса.В нюансы добавить можно следующее:
В прошлом месяце потратил некоторое время на отладку загадочных проблем с протоколами автоматического обнаружения через Wi-Fi: проблема была в старом маршрутизаторе, или, точнее, несовместимости (предположительно глючной) прошивки/чипа Wi-Fi маршрутизатора и чипа Wi-Fi устройства.
Если ваш принтер постоянно подключен к сети (и вы это видите в веб-интерфейсе роутера), но его обнаружение в сети работает только ровно 1 час, 1 день или другое круглое время, попробуйте:
Проверить маршрутизатор на наличие опции мультикаста и IGMP Snooping
Сменить режим безопасности Wi-Fi на "WPA-PSK/WPA2-PSK Mixed"
Отключить смену ключа GTK (группового ключа)
Создать отдельную (но не изолированную) сеть только для принтера
Протоколы автоматического обнаружения (mDNS/DNS-SD) используют мультикаст, который работает не так тривиально через Wi-Fi по сравнению с проводной сетью.
Wi-Fi использует разные алгоритмы шифрования и разные ключи шифрования для юникаст и широковещательного/мультикаст-трафика: индивидуальные ключи шифрования для каждого клиента для обычного юникаст-трафика (pairwise key) и отдельный общий ключ шифрования для группового трафика (group key) для броадкаст и мультикаст-трафика.
Оказывается, при некоторых условиях могут возникнуть проблемы с многоадресной рассылкой. Драйверы Intel Wi-Fi в Windows неправильно обрабатывают мультикаст-трафик после отправления компьютера в сон, а точки доступа Ubiquiti известны неправильной обработкой GTK.
Что касается IGMP Snooping: некоторые точки доступа требуют, чтобы устройство присоединилось к группе многоадресной рассылки mDNS для получения запросов mDNS. Большинство точек доступа пересылают запросы mDNS независимо от того, был ли запрос на присоединение к multicast-группе, или нет, но некоторые этого не делают или обрабатывают multicast неправильно.
https://qna.habr.com/answer?answer_id=2447978#answers_list_answer
Это какие? Назовите два популярных, пожалуйста. И я не про лишнее слово "лишь".
Чем выше версия, тем младше (по количеству дней с момента релиза) прошивка. Старее, действительно, решает двусмысленность.
Простите, я не знаю, что такое "wifi router первого звена". Все устройства (в т.ч. и роутеры, и клиенты) в моей LAN равноправны, они все в одном L2-сегменте. Все Wi-Fi-сети, аналогично, в одном (общим с ethernet) L2-сегменте. Можно подключаться в любой ethernet-порт любого роутера, либо же по Wi-Fi, и получать ровно ту же конфигурацию. Это обычная домашняя сеть.
Я не использую ByeDPI. ByeDPI работает как прокси и не предназначен для обработки маршрутизируемого трафика — его разумно применять исключительно при невозможности использования nfqws (или любого другого инструмента, работающего по пакетам и интегрирующегося в маршрутизируемый трафик) вследствие технических ограничений прошивок роутеров. На Orange Pi таких ограничений нет.
Orange Pi подключается одним проводом. У него один сетевой интерфейс. Если вы WAN'ом называете вышестоящий шлюз, на который маршрутизируется трафик, то да.
Orange Pi выступает простым маршрутизатором. Он просто маршрутизирует пакеты, полученные от других клиентов, на вышестоящий шлюз. Ну, чуть их обрабатывая с помощью nfqws, но если на минуту забыть о нём, то это самый обычный простой маршрутизатор. Без NAT, без разных сетевых сегментов, без проверки отправителя. На нём нет DHCP, нет DNS. Всё, что делает маршрутизатор при получении пакета от клиента — заменяет MAC-адрес отправителя на свой MAC, MAC-адрес назначения на MAC вышестоящего роутера, и пересылает пакет. Всё. nfqws дополнительно делает свою магию, но на непосредственно маршрутизацию это не влияет.
Картинка нарисована для описания бага nftables, связанного с маршрутизацией внутри логического бриджа (который может состоять хоть из одного физического интерфейса, но в моём случае объединяет несколько физических портов и Wi-Fi-точку).
Стрелочки на картинке показывают путь одного исходящего пакета, отправленного с компьютера в интернет. Это не схема сети!
Статья рассказывает об обходе блокировки дополнительным устройством в локальной сети, а не об установке обхода на роутер. Я привёл пример похожей конфигурации, более простой в настройке.
Такая конфигурация не требует ни изменения настроек на роутере (изменение dhcp option 3 не обязательно, с ним просто не придётся перенастраивать клиентов), ни перестройки физической топологии, ни замены роутера на более продвинутый. Она совместима даже с самыми базовыми моделями домашних роутеров, где нет никаких дополнительных возможностей.
Я всё настраивал удалённо и исходил из особенностей и ограничений существующей сети — невозможности установки nfqws на main router, из-за чего счёл перемаршрутизацию всего трафика через дополнительный маршрутизатор самой простой конфигурацией и меньшим из зол, хоть и не оптимальным по топологии, зато гарантированно надёжной в плане разблокировки. Если у вас есть возможность настроить обход блокировок на основном/единственном роутере — делайте на нём, конечно!