Уродливые формы борьбы РКН с VPN — 2: окончание истории

Posted on by Alex

История с заблокированным хостером сервером закончилась буквально на следующий день. Я честно написал в техподдержку, что оставил Wireguard включенным, но разрешил доступ к VPS только с определённых IP адресов (2 штуки), хотя и оставил возможность временно приоткрыть доступ с других IP адресов с помощью knockd. На это техподдержка ответила мне, что Wireguard нужно выключить полностью.

Что ж, хозяин сервера — барин. Раз уж IP сервера «спалился», решил, что можно арендовать VPS у другого хостера. Поблагодарил техподдержку за помощь, выразил сожаление, что РКН своей «борьбой» портит бизнес компаниям и жизнь людям, и через полчаса уже заехал на другой VPS. 🙂

Быстренько всё развернул, от Wireguard’а решил отказаться в пользу другого решения. Посмотрим, сколько времени протянет и будут ли какие-то проблемы.

Уродливые формы борьбы РКН с VPN

Posted on by Alex

Три года назад я писал про способ соединения двух локальных сетей, находящихся за NAT’ом провайдеров, через промежуточный VPS. Всё это прекрасно работало до вчерашнего дня. Хостер, где я покупал VPS, прислал письмо от Роскомнадзора. Процитирую его целиком, лишь «замазав» данные хостера:

Центр мониторинга и управления сетью связи общего пользования в составе радиочастотной службы, действующий в соответствии с пунктом 9 статьи 65.1 Федерального закона от 07.07.2003 № 126-ФЗ (далее – Закон о связи), в связи с выявлением угрозы противодействия (затруднения) ограничению доступа к информации или информационным ресурсам в сети «Интернет», доступ к которым подлежит ограничению в соответствии с законодательством Российской Федерации (подпункт «в» пункта 4 Правил централизованного управления сетью связи общего пользования, утвержденных постановлением Правительства Российской Федерации от 27.10.2025 № 1667), в рамках осуществления централизованного управления сетью связи общего пользования передаёт следующее обязательное к выполнению указание.

На сетевых адресах автономной системы № NNNNN, принадлежащих XXXXX (ИНН NNNNNNNNNN; внесен в реестр провайдеров хостинга приказом Роскомнадзора от NN.NN.NNNN № YYY), размещены информационные ресурсы, посредством которых обеспечивается доступ к информации или информационным ресурсам в сети «Интернет», доступ к которым ограничен на территории Российской Федерации, с использованием VPN-сервиса.

XXXXX на указанных сетевых адресах следует прекратить использование вычислительных мощностей для противодействия (затруднения) ограничению доступа к информации или информационным ресурсам в сети «Интернет», доступ к которым подлежит ограничению в соответствии с законодательством Российской Федерации.

Список ваших услуг, на которые указал ЦМУ ССОП:
(aa.bb.cc.dd)

Отмечу, что больше никаких деталей нет. К этому VPN сервису были подключены постоянно два роутера и периодически подключались два мобильника для удалённых манипуляций с Home Assistant. Так же на этом сервере когда-то давно болтался mtproxy, но в последнее время он был в нерабочем состоянии. Что именно не понравилось РКН — данных не приводится, увы. Запросил в техподдержке дополнительную информацию, но попытка не увенчалась успехом. Только ответили:

Нам неизвестно по каким критериям происходит проверка ЦМУ ССОП, по вашему вопросу не подскажем.

Спасибо техподдержке, пошли на встречу, включили сервер для устранения проблем. А именно: удалил mtproxy, ограничил подключение к VPN только для конкретных IP адресов. Насколько это поможет? Пока не знаю. Но тенденция неприятная.

P.S. Сначала я хотел тут написать список вопросов, которые есть лично у меня к Роскомнадзору и его деятельности. Например, «Как долго вы ещё будете кошмарить наших граждан и бизнес такими вот блокировками без суда и следствия объяснений? Ладно, когда действительно есть нарушения правил и законов, пусть и сомнительных. Но без указания точных нарушений, только наличие на сервере VPN, рестрикции за это выглядят как беспредел.» и ещё несколько. Но потом решил, что этим делу не поможешь и это будут лишь негативные эмоции, а практического толку от этого не будет никакого.

Шпион, выйди вон!

Posted on by Alex

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

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

Список программ, которые я удалил со своего телефона и теперь пользуюсь только веб-версиями:

  • Альфа-банк
  • Сбербанк онлайн
  • Озон
  • АЗС ГПН
  • Яндекс.Карты
  • Яндекс.Навигатор

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

OrangePI: храним логи на диске, а не в zram

Posted on by Alex

В Ubuntu, которую я установил на OrangePi, логи по-умолчанию пишутся в память. При штатном завершении работы они сбрасываются на диск, но если что-то пошло не так, логов потом не найдёшь. При первоначальной установке это выглядит так:

root@orangepi5pro:~ # df -h        
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.6G  9.9M  1.6G   1% /run
/dev/nvme0n1p2  226G   32G  192G  15% /
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           5.0M   16K  5.0M   1% /run/lock
tmpfs           7.8G  4.0K  7.8G   1% /tmp
/dev/nvme0n1p1 1022M  123M  900M  13% /boot
/dev/zram1      188M  4.6M  169M   3% /var/log  <-- вот!

Это выглядит оправданым, если операционная система установлена на SD карту, например. В случае же, когда ОС установлена на NVME диск, острой необходимости хранить логи в памяти нет. Особенно если логи нужны. Поэтому я отключил эту опцию и теперь логи пишутся сразу на диск. Делается это очень просто. Находим файл /etc/default/orangepi-ramlog, в нём строчки

# configuration values for the orangepi-ram-logging service
#
# enable the orangepi-ram-logging service?
ENABLED=true

и меняем true на false:

ENABLED=false

Перезагружаем систему и видим, что /var/log больше не примонтирован на /dev/zram1.

Установка прошивки на Orange Pi 5 Pro

Posted on by Alex

Купил некоторое время назад прекрасный девайс — Orange Pi 5 Pro. Работа с SD карты в мои планы не входила, так что сразу взял к нему NVME SSD. Получил посылку с заказом, быстро всё собрал и на радостях не обратил внимание на маленький, но важный нюанс: этот мини-пк идёт по умолчанию без SPI Flash и eMMC модуля. 🙂

В инструкции достаточно подробно всё расписано, как прошивать образ операционной системы на SD карту, на SPI Flash, на eMMC и на SD карту с дальнейшей записью операционки на NVME диск. Но, как водится, есть подводные камни.

1. Balena Etcher.

Заставить работать свежую версию (1.19.25) у меня сходу не удалось. При записи открывается сообщение с ошибкой «Error spawning child process». Но вот версия 1.18.4 работает без проблем.

2. Образы операционных систем

Я пробовал заливать на SD карту образы Debian, OpenWRT, OpenHarmony. Все они не загружаются. А посмотреть ошибку по UART я не мог, не было модуля под рукой. 🙂

В итоге заработал образ Orangepi5pro_1.0.4_ubuntu_jammy_server_linux6.1.43.img, ссылка на который была в официальной документации. После заливки его на SD карту, «апельсинка» наконец-то загрузилась. Тогда уже, в соответствии с документацией, мне удалось закинуть образ Ubuntu на NVME диск, а на флэшку записать загрузчик rkspi_loader.img. К слову, обновление Ubuntu с версии 22.04 («Jammy Jellyfish») до актуальной 24.04 («Noble Numbat») прошло без проблем.

В остальном железяка показала себя очень хорошо. В данный момент использую её в качестве видеорегистратора для записи видео с IP камер и «сердца» «умного дома» с HomeAssistant, и её ресурсов для этих целей более чем хватает.