Ubiquiti запустила акцию "День освобождения от SFP" с новым инструментом и скидками. Появился SFP Wizard — компактное устройство за $49 для диагностики и программирования модулей SFP/QSFP. Приложение UniFi позволяет за секунды проверить мощность сигнала (Rx/Tx), скопировать профиль любого модуля или обновить его прошивку. Устройство поддерживает OTA-обновления и крепится на ключи. Одновременно Ubiquiti снизила цены на модули нацелившись на сокращение зависимости от вендора. Например, 10G SM модуль (20 шт.) подешевел с $750 до $499, а 100G SR4 модуль обойдется в $39 (вместо $69). Акция охватывает модули от 1 Гбит/с до 100 Гбит/с, включая многомодовые, одномодовые, BiDi и CWDM-варианты.

Ключевой тренд — универсальность. SFP Wizard гарантирует совместимость модулей любых производителей с любыми коммутаторами Ubiquiti. Достаточно вставить модуль, скопировать его профиль, а затем применить на новом оборудовании. Это ликвидирует «вендорный ярлык». Скидки достигают 1000% от рыночных цен, что делает высокоскоростные оптические модули доступными даже для небольших сетей. Акция действует ограниченное время, а инструмент и модули позиционируются как решение для ускорения и упрощения развертывания сетей.

• Пользователи обсуждают блокировку вендор-лока SFP-модулей, история которой уходит в 2001 год, и то, что UniFi вроде как «сделал это первым» – хотя на практике это не так.
• Обсуждается, что FS.com и другие поставщики предлагают дешёвые, вендор-нейтральные модули, которые можно перепрошивать под нужный вендор.
• Участники делятся опытом, что модули Cisco и других вендоров не работают в оборудовании UniFi, и что «SFP-мастер» от Ubiquiti не работает с модулями других вендоров.
• Также обсуждается, что UniFi не поддерживает IPv6, что вызывает проблемы у пользователей.
• Участники жалуются на отсутствие стока и отсутствие перспективы удешевить SFP-модули в будущем.
• Также обсуждается, что MikroTik и другие вендоры тоже блокируют сторонние модули.
• Наконец, обсуждается, что UniFi не предоставляет никаких инструментов для диагностики SFP-модулей, в то время как другие вендоры это делают.

Вместо закрытия сайта test-ipv6.com, его поддержку взял на себя региональный интернет-регистратор, что позволит продолжить его работу в общественных интересах. Ранее планировалось, что ресурс закроется в декабре 2025 года, так как его основатель Джейсон Феслер решил перераспределить ресурсы на личные нужды. Проект, запущенный в 2010 году, предоставлял бесплатные услуги по проверке IPv6, но требовал значительных затрат. Благодаря общественной поддержке, сайт продолжит работу под новым руководством. Феслер также опубликовал исходный код проекта, чтобы сообщество могло его использовать.

• Проект переходит под крыло RIR (Regional Internet Registry), который продолжит его работать в интересах общественности.
• Угроза закрыть сайт на Рождество вызвала бурную реакцию, и многие предложили помощь.
• Сайт был полезен для проверки IPv6 и общего подключения к интернету.
• Некоторые ISP до сих пор не предлагают IPv6.
• Сайт был полезен для проверки IPv6 и общего подключения к интернету.

Создатель популярного сервиса test-ipv6.com, работающего с 2010 года, объявил о его закрытии в декабре 2025 года. Проект, предоставлявший бесплатные инструменты для тестирования IPv6-соединений, долгое время поддерживался за счёт личных ресурсов автора — без какого-либо дохода. Решение связано с желанием перераспределить усилия в пользу семьи.

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

• Благодарность создателю сайта test-ipv6.com за многолетнюю полезную службу в отладке IPv6
• Обсуждение технических проблем с IPv6: плохая маршрутизация, потеря пакетов, сложность настройки и неполная поддержка провайдерами
• Предложения по сохранению сайта: передача другому лицу (например, ben из IPinfo) или организации, поиск спонсорства
• Замечание, что развертывание IPv6 в новых проектах стало необходимостью, несмотря на сохраняющиеся проблемы
• Освещение практических и финансовых трудностей поддержки публичного сервиса, включая атаки и стоимость запросов геолокации

Cloudflare превращается в опасную интернет-монополию, подрывая безопасность и приватность пользователей. Их система капч притупляет бдительность, облегчая фишинг-атаки, а инфраструктура сама становится инструментом для злоумышленников — от туннелирования до обхода DDoS-защиты. Уязвимости Cloudflare привлекают государственные хакерские группы, а инцидент Cloudbleed 2017 года показал утечки конфиденциальных данных, включая пароли и личные сообщения.

Основание компании связано с контрактами на данные для Министерства внутренней безопасности США, что вызывает вопросы о её изначальных целях. Внутренняя культура Cloudflare также критикуется за жёсткие методы управления и высокую текучесть кадров. Рекомендация — избегать использования Cloudflare, чтобы не усиливать централизацию и риски для интернета.

• Критика Cloudflare за пособничество фишингу и недостаточное реагирование на жалобы, а также за соблюдение сомнительных местных законов.
• Защита Cloudflare: сервис предоставляет уникальные и бесплатные решения (CDN, Workers), которые трудно заменить, а упомянутые уязвимости успешно устраняются.
• Обвинения в монополизации рынка и намеренном создании зависимости от экосистемы Cloudflare через постоянное расширение услуг.
• Сомнения в объективности автора исходной статьи из-за устаревших данных, псевдонима и подбора доказательств под заранее заданный тезис.
• Обсуждение технических аспектов: проблемы с Unicode/IDN в домене, необходимость перехода на IPv6 и сложности самостоятельного хостинга.

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

Сервис bgp.tools отслеживает такие проблемы, собирая широковещательный и multicast-трафик с портов IX. Среди частых находок — протоколы идентификации устройств, такие как LLDP, CDP и MNDP, которые раскрывают детали конфигурации, имена устройств, IP-адреса и версии ПО, что может быть использовано злоумышленниками. Например, пакеты Mikrotik MNDP показывают точные данные о железе и софте, включая IPv4/IPv6-адреса.

• Обсуждаются примеры грубых ошибок в настройке сетей, включая замену управляемого коммутатора на неуправляемый для подавления STP BPDU.
• Участники объясняют концепцию точки обмена интернет-трафиком (IX) как специализированной LAN-сети для прямого соединения маршрутизаторов крупных провайдеров и обмена маршрутами через BGP.
• Поднимается вопрос о целесообразности использования протоколов вроде LLDP и STP на публичных сегментах сети IX, так как они могут представлять дополнительный риск.
• Отмечается распространенная проблема излишнего усложнения сетевых конфигураций и копирования непроверенных решений.
• Обсуждаются инциденты утечки служебного трафика или данных из-за ошибок конфигурации, приведших к мосту не предназначенных для этого сетей.

За последние 15 лет интернет стал значительно безопаснее: доля зашифрованного трафика выросла с менее чем 10% до более 95%, во многом благодаря усилиям Cloudflare. Однако некоторые области, например внедрение IPv6, прогрессируют медленно, что увеличивает стоимость сетевой инфраструктуры и ограничивает новых участников.

Основная бизнес-модель интернета остаётся неизменной: создание контента, привлечение трафика и монетизация через рекламу, подписки или продажи. Эта система вознаграждения стимулировала наполнение сети ценными материалами, но также породила проблемы вроде кликбейта и низкокачественного контента, ориентированного на максимизацию вовлечения. Cloudflare сознательно избегала роли арбитра контента, считая, что ключ к улучшению — не цензура, а изменение incentives.

• Обсуждается предложение Cloudflare о создании новой бизнес-модели, где AI-компании платят за скрейпинг контента, а часть средств получают создатели.
• Высказываются опасения, что это приведет к появлению нового посредника (Cloudflare) и монополизации, что может убить открытый интернет и затруднить вход на рынок новым игрокам.
• Участники сомневаются в эффективности модели и справедливом распределении доходов, проводя параллели с проблемами существующих систем (например, App Store, AdSense).
• Поднимается вопрос о том, что считать контентом, достойным оплаты, и как быть с синтетическими данными, созданными AI на основе первоисточников.
• Обсуждается ностальгия по старой, более децентрализованной модели интернета и скептицизм по поводу возможности вернуться к ней или создать справедливую новую.

Утечка IPv6 в PureVPN

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

Проблемы затрагивают как GUI (v2.10.0), так и CLI (v2.0.1) клиенты на Linux (тестировалось на Ubuntu 24.04.3 LTS). Вот что обнаружено.

1. Утечка IPv6

После переподключения Wi-Fi или возобновления работы из спящего режима клиент PureVPN не восстанавливает защиту IPv6:

• CLI: Клиент автоматически переподключается и сообщает о статусе "подключено", но система получает маршрут IPv6 через Router Advertisements. Egress-трафик идёт вне туннеля.
• GUI: При обнаружении отключения GUI блокирует IPv4, но IPv6 остаётся рабочим до явного переподключения.

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

2. Сброс файрвола

При подключении PureVPN сбрасывает конфигурацию iptables пользователя:

• INPUT устанавливается в ACCEPT
• Все правила -A сбрасываются (включая UFW, Docker)
• После отключения изменения не восстанавливаются

Результат: система остаётся более уязвимой после использования VPN, чем до него. Это противоречит ожиданиям пользователя.

Пример:

# Базовая защита
$ sudo iptables -P INPUT DROP
$ sudo iptables -I INPUT -p icmp -j DROP

# После подключения VPN
$ sudo iptables -S | head -3
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
# Правила удалены

Итог

PureVPN:

• Неправильно реализует kill-switch для IPv6
• Оставляет IPv6 открытым после переподключений
• Сбрасывает состояние файрвола и не восстанавливает его
• Применяет политики ACCEPT для работоспособности

Обе проблемы имеют практическое влияние. Заявления о конфиденциальности подрываются, когда реальный IPv6 утекает, а состояние файрвола теряется.

Полные технические отчёты отправлены на security@purevpn.com. Ответа нет. Используйте с осторожностью.

• Автор поста благодарит за обсуждение и согласен с рисками использования проприетарных VPN-клиентов, отмечая полезность сетевых пространств (network namespaces) для изоляции трафика.
• Многие участники критикуют VPN-провайдеров за плохую реализацию поддержки IPv6, выделяя Mullvad как исключение, но и ему предъявляют претензии.
• Несколько комментаторов настоятельно не рекомендуют использовать PureVPN из-за доказанных в суде случаев логирования трафика, вопреки их заявлениям.
• Высказываются серьёзные сомнения в надёжности закрытого исходного кода клиентов и серверов VPN, предлагается использовать решения с открытым кодом и изоляцией трафика (например, через Vopono или Gluetun).
• Участники обсуждают ненадёжность популярных провайдеров (NordVPN, ExpressVPN) из-за агрессивного маркетинга, моделей ценообразования и возможных связей с определёнными юрисдикциями.
• Предлагаются технические решения для предотвращения утечек: отключение IPv6, использование kill-switch и настройка сетевых пространств через systemd-nspawn или другие инструменты.
• Отмечается, что основная функция VPN — подключение к удалённой сети, а конфиденциальность и безопасность являются вторичными и зависят от доверия к провайдеру.

Не выбирайте странные подсети для встраиваемых сетей, используйте VRF

Встраиваемая сеть — это, например, переносная стойка с видео- и сетевым оборудованием, которую подключают к сети площадки. Устройства внутри стойки должны общаться между собой, но перенастраивать их IP при каждой смене локации неудобно. Обычно добавляют маршрутизатор с NAT и используют простую подсеть вроде 10.0.0.0/24. Проблема возникает, если внешняя сеть площадки использует ту же подсеть — возникают конфликты. Люди начинают выбирать «редкие» диапазоны (172.16.42.0/24, 10.11.12.0/24), но конфликты всё равно случаются.

IPv6-решение
Использовать link-local адреса fe80::/64 и протоколы обнаружения (avahi). Маршрутизатор раздаёт маршруты, и внутренние устройства получают доступ в интернет. Недостаток: большинство встраиваемых устройств (аудио- и видеомикшеры) не поддерживают IPv6. Аналогичный IPv4-механизм APIPA (169.254.0.0/16) не даёт шлюза и интернета.

Универсальное решение
Вместо экзотических подсетей ограничьте «странность» настройками маршрутизатора. Используйте VRF (Virtual Routing and Forwarding), чтобы изолировать внутреннюю сеть и избежать конфликтов, не меняя адресацию устройств.

• Docker случайно выбирает подсеть RFC1918, которая может конфликтовать с корпоративной сетью; это частая проблема в AWS и вызывает головную боль при отладке.
• IPv6-поддержка всё ещё редка, поэтому обсуждают альтернативы: IPv4 link-local, CGNAT 100.64.0.0/10, «benchmark» 198.18.0.0/15 и даже выделение «мертвой» подсети.
• Некоторые просто используют VRF или VLAN, чтобы изолировать трафик и избежать конфликтов, хотя это требует понимания маршрутизации.
• Участники сомневаются, что IPv4 исчезнет скоро: у провайдеров его много, а стимул перехода на IPv6 минимален без внешнего давления.

• Используйте клавиши ↑ (Вверх) и ↓ (Вниз), чтобы переместить указатель к нужному загрузочному устройству.
• Нажмите Enter для попытки загрузки или Esc для отмены.

Параметры загрузки:

• Обычная загрузка Windows
• Установить Windows
• Встроенный NIC (IPv4)
• Встроенный NIC (IPv6)

Другие параметры:

• Настройка BIOS
• Конфигурация устройств
• Обновление прошивки BIOS
• Изменить режим загрузки

• Пользователи делятся ссылками на JS-клон Windows XP (win32.run) и настоящие эмуляторы (VirtualXP, v86).
• Все восторгаются ностальгией: звук загрузки, старый ключ продукта, кастомизация TweakXP.
• Замечены неточности клона: шрифты, тени, отсутствие Pinball, «быстрая» загрузка, Python 3 вместо 2.x.
• Кто-то шутит, что запустит сайт на полный экран в офисе, чтобы напугать IT.
• Общий вывод: XP — пик дизайна и функциональности, но перед нами всё-таки симулятор, а не настоящая система.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.

• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.

• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.

• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.

• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.

• Прочие выигрыши:

  • 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
  • Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
  • Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
  • Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
  • Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
  • 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.

IPv4 is never going away barring massive adoption of p2p protocols to drive the switch. Sadly NAT and SNI solve most of the problems well enough for things to limp along indefinitely. The only orgs with the power to fix this from the top down are incentivized to maintain the cent