• OpenBSD 7.8 вышел, и участники обсуждают его достоинства: минимализм, безопасность и отсутствие лишнего кода.
• Пользователи делятся опытом: кто-то использует OpenBSD как основную систему, кто-то как фаервол, кто-то как маршрутизатор.
• Обсуждается поддержка различного оборудования, включая Raspberry Pi 5 и ThinkPad.
• Участники обсуждают, что OpenBSD не поддерживает некоторые современные технологии, такие как Bluetooth и Wi-Fi 6.
• Некоторые пользователи отмечают, что OpenBSD не поддерживает некоторые современные технологии, такие как Bluetooth и Wi-Fi 6.

Утечка 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 — подключение к удалённой сети, а конфиденциальность и безопасность являются вторичными и зависят от доверия к провайдеру.

20 августа 2025 г. с 00:34 до 01:48 по Пекину GFW безусловно сбрасывал все TCP-соединения на 443-порт, разрывая трафик между Китаем и остальным миром.

Ключевые факты

• Цель: только 443/tcp; 22, 80, 8443 не трогались.
• Механизм:
  • из Китая: SYN или SYN+ACK вызывали три поддельных RST+ACK;
  • в Китай: RST посылались только на SYN+ACK сервера.
• Оборудование: отпечатки не совпадают с известными GFW-узлами ⇒ либо новое устройство, либо сбой.

Примеры трафика

Из Китая наружу

CN_IP → NON_CN_IP:443 [SYN]
NON_CN_IP:443 → CN_IP [RST+ACK] (seq 0, ack 1, win 1980-1982)
NON_CN_IP:443 → CN_IP [SYN+ACK]
NON_CN_IP:443 → CN_IP [RST+ACK] (seq 1, ack 1, win 3293-3295)

Снаружи в Китай

192.168.0.162 → baidu.com:443 [SYN]
baidu.com:443 → 192.168.0.162 [SYN+ACK]
baidu.com:443 → 192.168.0.162 [RST+ACK] (seq 1, ack 1, win 2072-2074)

Инцидент длился 74 минуты; приглашаем сообщить дополнительные наблюдения.

• Пользователи обсуждают масштабные сбои/блокировки в китайском интернете, многие называют это «комендантским часом» и опасаются повторения на Западе.
• Возникли вопросы о топологии «Великого фаервола»: централизован ли он, действует ли между всеми узлами или только между домашними и коммерческими сетями.
• Некоторые считают инцидентом ошибку конфигурации, другие — «сухую тренировку» перед будущими ограничениями, особенно в военное время.
• Упоминаются последствия для удалённых работников и иностранцев: падение VPN, пропущенные созвоны, поиск запасных каналов (Starlink, LoRa, V2Ray).
• Подчёркивается, что внутри Китая даже запуск личного блога требует лицензии ICP, а HTTPS-сертификаты часто отсутствуют.