WEB Proxy для Telegram Desktop на своём VPS

В моей инфраструктуре давно крутится Telegram-трафик через SOCKS5-туннель на VPS — но у этого подхода есть минусы: SOCKS5 легко режется DPI, а клиент надо настраивать отдельно. Альтернатива от самих разработчиков Telegram Desktop — WEB Proxy: прокси, который маскируется под обычный HTTPS-сайт на 443-м порту. Такой трафик не отличить от обычного захода на сайт, а подключение настраивается в два поля в настройках клиента.

В этой статье — как я развернул tproxy-server на свежем VPS (Debian 13, Hostkey), какие проблемы встретил в установщике и как их обошёл. Полезно всем, кто решит поднять свой WEB Proxy.

Зачем WEB Proxy, а не SOCKS5

Схема работы tproxy-server:

Telegram Desktop → HTTPS:443 → Caddy → tproxy-server:8080 → MTProxy:2398 → Telegram
                                        └ admin :8081 (/readyz, /healthz)

Caddy отдаёт Let’s Encrypt сертификат и проксирует весь трафик на tproxy-server, который сам решает: обычные запросы отдаёт сайт-маскировку, а запросы WEB Proxy — гонит в MTProxy. Снаружи это просто HTTPS-сайт.

Установка: что делает install.sh

У upstream отличный установщик — deploy/install.sh делает почти всё сам:

• ставит пакеты (ca-certificates, curl, nftables);
• ставит Caddy 2.11.4 и Go 1.26.5 (если нет);
• собирает tproxy-server из исходников;
• собирает MTProxy (pinned commit f36d8af) в /opt/MTProxy;
• создаёт systemd-сервисы: tproxy-server, mtproxy, tproxy-firewall, caddy;
• настраивает таймер refresh-mtproxy-config (обновление списка серверов Telegram раз в сутки);
• поднимает nft-правило, закрывающее порты MTProxy (2398, 8888) от внешнего мира.

Запуск:

1
2
3

./deploy/install.sh --hostname vps03.nixg.ru \
  --email me@example.com --site-dir /tmp/tproxy-site \
  --secret "$(cat /tmp/tproxy-secret.txt)"

--secret — 32 hex-символа (openssl rand -hex 16), --site-dir — каталог со статическим сайтом-маскировкой.

Грабли №1: mtproxy.service падает с 203/EXEC, readyz 503

После первого прогона установщика tproxy-server был active, Caddy слушал 80/443, но прокси не работал:

1

● mtproxy.service - failed (Result: exit-code), status=203/EXEC

Порт 2398 не слушался, а /readyz административного эндпоинта отдавал 503 (readyz — это «вся цепочка готова», healthz при этом был 200).

Причина оказалась в правах на бинарь после сборки. Установщик собирает MTProxy в /opt/MTProxy/objs/bin/mtproto-proxy, но из-за umask бинарь и каталоги получают права 700 root:root. Юнит mtproxy.service запускается от пользователя mtproxy (с NoNewPrivileges=true и ProtectSystem=strict) — процесс не может прочитать бинарь и умирает с 203/EXEC.

Лечится одной серией команд:

1
2
3
4

chmod 755 /opt/MTProxy /opt/MTProxy/objs /opt/MTProxy/objs/bin
chown root:mtproxy /opt/MTProxy/objs/bin/mtproto-proxy
chmod 750 /opt/MTProxy/objs/bin/mtproto-proxy
systemctl restart mtproxy

После этого mtproxy — active (running), слушает 0.0.0.0:2398, readyz → 200.

Грабли №2: флейк go test в установщике

Первый прогон install.sh (холодный кэш Go, сборка всех пакетов параллельно) упал на тестах:

1
2

FAIL: internal/config — TestLoadAcceptsSystemdCredentialReadPermissions:
group/other-readable profiles file outside a credential directory was accepted

А повторный go test ./... (тёплый кэш) — PASS. Это классическая гонка при холодном параллельном прогоне тестов, а не баг кода. Лечение простое: перезапустить install.sh — дальше идёт нормально.

Грабли №3: «не открыты порты 80/443» — ложная тревога

Снаружи curl на 80/443 не отвечал, и я заподозрил firewall провайдера (Hostkey). Пошёл в панель — а там вообще нет настроек firewall/прокси. Полез в документацию, искал API…

На самом деле всё проще: порты у провайдера открыты по умолчанию, просто на 80/443 ничего не слушало — curl получал connection refused. Проверка: поднимаю временный python3 -m http.server 80 → TCP connect снаружи OK. После установки Caddy сам слушает 80/443.

Так что если у вас после установки снаружи не открывается сайт — сначала проверьте, что порт слушается (ss -tlnp), а не ищите firewall в панели провайдера.

Проверка после установки

1
2
3
4
5
6

systemctl status tproxy-server mtproxy tproxy-firewall caddy   # все active
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8081/readyz    # 200
curl -s -o /dev/null -w '%{http_code}' https://vps03.nixg.ru/          # 200 (сайт)
openssl s_client -connect vps03.nixg.ru:443 -servername vps03.nixg.ru  # LE-серт
ss -tlnp | grep -E ':80 |:443|:2398|:8080|:8081'
nft list ruleset | grep -E '2398|8888'   # закрыто от внешнего мира

Наружу видны только 80/443. MTProxy-бэкенд (2398, 8888) закрыт nft — iifname != "lo" ... drop, то есть бэкенд не светится и не принимает подключения напрямую.

Настройка клиента

В Telegram Desktop: Settings → Advanced → Connection Type → Use custom proxy → NEW PROXY → WEB Proxy:

• hostname: vps03.nixg.ru
• secret: (32 hex-символа, которые вы сгенерировали)

Итог

WEB Proxy — отличная замена SOCKS5-туннелю, если нужна маскировка под обычный HTTPS: настраивается в два поля, трафик неотличим от сайта, а готовый установщик upstream делает почти всю работу. Главные грабли — права на бинарь MTProxy после сборки (203/EXEC) и ложная тревога с «закрытыми портами». Оба решаются за пару минут, если знать, куда смотреть.

Полный набор файлов (заметки, сайт-маскировку, команду установки) я сложил в репозиторий tproxy-web — точнее, в свой tproxy-web на gitverse, а INSTALL_NOTES.md с деталями лежит там же.

Как я перевёл aux-задачи Hermes на локальные модели

У меня на домашнем сервере живёт агент Hermes — он ведёт блог, следит за сертификатами, ходит в мессенджеры и выполняет кучу мелких, но важных задач. Основную модель он берёт в облаке (провайдер polza.ai, 131K контекст), а для вспомогательных задач — генерации заголовков, извлечения текста из веб-страниц, описания картинок (vision) и сжатия контекста — у него есть отдельный механизм auxiliary. По умолчанию все aux-задачи тоже резолвятся в облако, а значит — тратят токены и деньги.

На сервере стоит видеокарта RTX 5060 Ti 16 GB (да, та самая, про которую я писал в статье про зависание Ubuntu при загрузке). Раз есть GPU — почему бы не увести aux-задачи на локальные модели? Приватность, скорость, ноль затрат на API. Рассказываю, как выбирал модель, как настраивал и какой грабли встретил при отключении режима размышлений (thinking) у Qwen3.

Что такое auxiliary-задачи в Hermes

Hermes — агент с модульной архитектурой. Кроме основной модели (которая думает и пишет ответы), он вызывает вспомогательные (auxiliary) задачи через отдельный клиент — auxiliary_client.py. В моей версии их несколько:

Ключевой момент: только compression требует большого контекста (64K). Это жёсткое требование самого Hermes — для сжатия истории ему нужна модель, которая видит весь диалог. Локальные GGUF-модели до 64K не дотягивают (проверил: qwen3-8b упирается в 40960 токенов контекста, qwen2.5-coder-14b — в 32768; теги «64k/65k» в названиях моделей — маркетинг, реальный контекст меньше). Поэтому compression я оставил в облаке, а вот все остальные aux-задачи — кандидаты на локализацию.

Выбор модели

Критерии были простые:

1. Модель должна уметь vision (для vision-задачи).
2. Должна влезать в 16 GB VRAM вместе с эмбеддинг-моделью bge-m3 и основной текст-моделью.
3. Должна быстро отвечать — aux-задачи вызываются часто, ждать минуту утомительно.
4. Желательно уметь закрыть и текстовые задачи (генерация заголовков, извлечение текста) — чтобы не гонять облако вообще.

Я поставил qwen3-vl:8b — мультимодальную модель Qwen 8B с поддержкой vision. Она весит ~6.1 GB, контекст 262K (но KV cache на полный контекст — ~309 GB, так что реально держу num_ctx=8192). Проверил через /api/show — у неё есть capability vision, значит Hermes её увидит как vision-модель.

Важный нюанс про qwen3-vl: она великолепно описывает картинки (проверено E2E — отвечает «red»/«blue» на цветные картинки за 1-10 секунд), но для текстовых задач она… слишком умная. На простой вопрос «какой сегодня день недели» она генерирует 3778 токенов рассуждений и отвечает через 64 секунды! Это потому, что qwen3-модели по умолчанию включён режим reasoning/thinking. Для заголовков и извлечения текста это неприемлемо.

Поэтому я взял две модели:

• qwen3-vl:8b — для vision (картинки);
• qwen3:8b — для текстовых aux (title_generation, web_extract), с принудительно отключённым thinking.

Настройка

Hermes поддерживает per-task конфигурацию auxiliary-задач в config.yaml. Формат:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

auxiliary:
  vision:
    provider: custom
    model: qwen3-vl:8b
    base_url: http://localhost:11434/v1
    api_key: ollama
  title_generation:
    provider: custom
    model: qwen3:8b
    base_url: http://localhost:11434/v1
    api_key: ollama
    extra_body:
      think: false
  web_extract:
    provider: custom
    model: qwen3:8b
    base_url: http://localhost:11434/v1
    api_key: ollama
    extra_body:
      think: false

Настройка через CLI:

1
2
3
4
5

hermes config set auxiliary.vision.provider custom
hermes config set auxiliary.vision.model qwen3-vl:8b
hermes config set auxiliary.vision.base_url http://localhost:11434/v1
hermes config set auxiliary.vision.api_key ollama
# и так для каждой задачи

Пара важных граблей:

• api_key обязан быть непустым. В коде Hermes пустой api_key означает «унаследовать ключ основного провайдера» — и тогда он попытается сходить в polza.ai с локальной моделью. Я поставил заглушку ollama (Ollama её не проверяет).
• Ollama надо форматировать через OpenAI-совместимый эндпоинт /v1/chat/completions — именно так Hermes ходит в локальные модели.
• Для qwen3-vl держать num_ctx небольшим (я использую 8192), иначе Ollama пытается зарезервировать KV cache под весь 262K контекст — это ~309 GB, runner падает с EOF.

Допиливание отключения режима размышлений (thinking)

Самая интересная часть. Qwen3-модели (и qwen3, и qwen3-vl) по умолчанию генерируют скрытый поток рассуждений (thinking/reasoning) перед ответом. Для aux-задач это означает:

• Заголовок генерируется 64 секунды вместо 3-5.
• При ограниченном max_tokens ответ вообще пустой — весь бюджет съедает thinking, до content дело не доходит.

Я перепробовал несколько способов отключить thinking, и вот что выяснилось:

Что НЕ работает (в Ollama)

Я проверил chat template модели — там есть команды /think и /no_think, но они не активируются в Ollama (флаг IsThinkSet не выставляется).

Что работает

Единственный рабочий способ — корневой параметр think: false в теле запроса:

1
2
3
4
5

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "Привет!"}],
  "think": false
}'

Ответ приходит через 0.7 секунды (вместо 64!), reasoning=false, content заполнен. Именно эту опцию я и прописал в extra_body конфига Hermes:

1
2

extra_body:
  think: false

В коде Hermes extra_body уходит в корень JSON-тела запроса — как раз туда, куда Ollama ждёт параметр think.

Проверка E2E

После настройки прогнал реальные вызовы через вспомогательный клиент Hermes (call_llm):

VRAM и память

На RTX 5060 Ti 16 GB в памяти держатся одновременно:

• qwen3-vl:8b — ~7.2 GB (vision)
• qwen3:8b — ~6.1 GB (текст)
• bge-m3 — ~1.2 GB (эмбеддинги)

Итого ~14.5 GB — влезает с запасом, и переключение vision↔текст происходит без выгрузки модели. Проверено через /api/ps: после текстового вызова в памяти остаются обе модели.

Итог

• Vision полностью локальный — картинки описываются на сервере, в облако не уходят.
• Текстовые aux (заголовки, извлечение текста) — локальные, быстрые, бесплатные.
• Compression остался в облаке — ему нужен контекст 64K, который локально не влезает.
• Облачные токены тратятся только на основную модель и сжатие контекста — экономия существенная.

Самое ценное знание, которым делюсь: если вы используете Qwen3 в Ollama для вспомогательных задач — не забудьте think: false. Это превращает задумчивую модель, которая час думает над заголовком, в мгновенного исполнителя. И помните: /no_think, enable_thinking и thinking: disabled — в Ollama не работают, работает только корневой think: false.

Полезные ссылки: Hermes Agent · Ollama qwen3-vl · Ollama qwen3

Проблема: зависание загрузки Ubuntu после обновления с сообщением EFI stub

Симптомы

После выполнения apt upgrade (об этом я вспомнил уже после того как разобарлся с пробелмой) и перезагрузки система перестала загружаться. На экране последнее сообщение:

EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path

После этого — полное зависание. GRUB работает, выбор ядра доступен. Ошибок ядра (kernel panic, Oops) нет.

Окружение

• ОС: Ubuntu (ядро 6.8.0-111-generic)
• Видеокарта: NVIDIA RTX 5060 Ti (архитектура Blackwell)
• Дисковая подсистема: программный RAID1 (mdadm)

Диагностика

1. Аппаратная часть исправна: диски определяются в BIOS, SMART — PASSED, RAID-суперблоки на месте (mdadm --examine показал корректные UUID).
2. RAID собирается: mdadm --assemble --scan активен, /proc/mdstat — массив в состоянии [UU]. Проверял на соседней машине.
3. LiveUSB с Ubuntu/Debian не загружается — аналогичное зависание на той же строчке.
4. UEFI Shell работает, загрузчик GRUB физически присутствует на EFI-разделе.

Решение

Загрузка с параметром ядра:

nomodeset

После добавления этого параметра в строку загрузки GRUB система стартует штатно. Механизм nomodeset отключает Kernel Mode Setting (KMS), предотвращая инициализацию DRM/драйвера видеокарты на раннем этапе загрузки.

Причина

Ядро 6.8.0 не имеет полной поддержки видеокарт на базе архитектуры Blackwell (RTX 5060 Ti вышла позже релиза ядра). При попытке инициализации видеорежима через nouveau (или фолбэк-механизмы) происходит зависание на этапе настройки дисплейного контроллера.

nomodeset исключает этот этап, оставляя управление видеорежимом за прошивкой UEFI. Система загружается, но без ускорения графики — что для сервера в большинстве случаев некритично.

Постоянное применение

1
2

echo 'GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"' | sudo tee /etc/default/grub
sudo update-grub

Корректное решение (убрать nomodeset)

1. Установить проприетарный драйвер NVIDIA версии 570 или новее.
2. Или обновить ядро до версии 6.12+, где поддержка Blackwell добавлена в nouveau.

Вывод

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

Дополнение

Я думал переустановить систему, залив Debian. Но после выбора параметра установки в загрузочном меню, я опять получал зависшую систему. Решилась пробелма что сложнее, одного параметра nomodeset не хватило, БЯМ подсказала расширенную версию:

Вот перечень параметров, которые вы должны добавить все вместе:

nomodeset acpi=off noapic nolapic pci=nomsi pci=nommconf console=tty0 console=ttyS0,115200

Как это ввести:

1. Загрузитесь с Ventoy, выберите Debian.
2. Нажмите e для редактирования.
3. Найдите строку с linux.
4. Удалите всё содержимое после --- (или в конце строки) и вставьте туда эту строку.
5. Нажмите Ctrl+X.

Что эти флаги делают:

• acpi=off noapic nolapic: Отключают продвинутое управление питанием и прерываниями (часто выручает на серверном железе).
• pci=nomsi pci=nommconf: Отключают альтернативные методы обработки прерываний PCIe.
• console=tty0 console=ttyS0: Говорят ядру дублировать вывод на обычный экран и на «виртуальный последовательный порт» — это часто сдвигает процесс с мертвой точки

1. Базис и надстройка: техническая инфраструктура как инструмент классового господства

С марксистско-ленинской точки зрения, интернет — это часть производительных сил. Контроль над ним есть контроль над средством производства информации. Постановление №1667 от марта 2026 года, дающее Роскомнадзору, ФСБ и Минцифры право централизованно перенаправлять трафик и изолировать Рунет в реальном времени [1] [7], формализует переход от «защиты от внешних угроз» к системному управлению идеологическим воспроизводством.

Технические средства противодействия угрозам (ТСПУ) с функцией DPI (Deep Packet Inspection) — это не просто «фильтры». Это материальная база для селективного доступа к знаниям, коммуникациям и рынкам. Когда доступ к зарубежным ресурсам деградирует «незаметно» (таймауты, обрывы, замедление), это создаёт эффект естественного отбора: кто может и хочет — ищет обходные пути, кто не может — принимает новую норму.

2. «Метод лягушки» как диалектика постепенной нормализации

Для себя я процесс “регулирования” интернета чётко ассоциирую с правильным способом варки легушек - нужно медленно поднимать температуру (вводить ограничения), а не кидать лягушек в кипяток (резко всё блокировать). В диалектическом материализме количественные изменения переходят в качественные. Последовательное введение ограничений (блокировка платформ, ограничение VPN, требование русского языка в интерфейсах, хранение метаданных 3 года) — это не хаотичные шаги, а системная стратегия формирования новой субъективности.

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

3. Кто выигрывает? Классовый анализ последствий

4. Противоречия системы (диалектический взгляд)

Марксизм учит видеть внутренние противоречия как двигатель развития. В политике «суверенного интернета» их несколько:

• Технологическая зависимость: ТСПУ, системы фильтрации, оборудование для ЦМУ ССОП — часто импортного происхождения или на импортных компонентах. Изоляция усиливает уязвимость, а не снижает её.
• Экономические издержки: Ограничение доступа к глобальным сервисам снижает конкурентоспособность российской экономики, тормозит инновации, увеличивает стоимость цифровизации.
• Социальное напряжение: Постепенное сужение доступа к информации порождает не пассивность, а поиск альтернатив (зеркала, P2P-сети, офлайн-обмен). Это создаёт новые формы неформальной солидарности и знаний.
• Идеологический кризис: Чем жёстче контроль, тем выше ценность «запретного плода». Риторика защиты всё меньше убеждает, когда пользователи видят, что блокируются не только «экстремистские», но и образовательные, научные, культурные ресурсы.

5. Вывод: не изоляция, а перераспределение доступа

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

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

5. Формы классовой борьбы в цифровой сфере

С марксистской позиции, цифровое пространство — это арена классовой борьбы. Выделяются три уровня противостояния:

А) Борьба за средства производства информации

• ТСПУ и ЦМУ ССОП — это материализованная воля господствующего класса контролировать производительные силы [2] [3].
• Ответ пролетариата: децентрализованные сети (Tor, Ceno, P2P), где средство производства — вычислительные ресурсы самих пользователей. Это форма кооперации вне государственного контроля.

Б) Борьба за рабочее время и отчуждение

• Блокировка инструментов (GitHub, Stack Overflow, зарубежные SaaS) увеличивает время на выполнение задач. Это скрытая форма увеличения необходимого рабочего времени за счёт снижения производительности.
• Рост спроса на обходные пути создаёт новый сегмент «теневого цифрового труда»: настройка прокси, поддержка зеркал, обучение других. Это стихийная самоорганизация, но пока не переросшая в классовое сознание.

В) Идеологическая борьба: самоцензура как форма отчуждения

• Когда пользователь начинает фильтровать свои сообщения «на всякий случай», происходит интернализация контроля. Это высшая форма отчуждения: работник сам воспроизводит условия своего подчинения.
• Однако диалектика: чем шире блокировки, тем очевиднее их политический характер. Растёт понимание, что проблема не в «экстремизме», а в контроле.

6. Исторические параллели: СССР, Китай, Иран

СССР: цензура как административный ресурс

• Главлит контролировал содержание, но не инфраструктуру. Это создавало «лазейки»: самиздат, зарубежные радиостанции, личные контакты.
• Урок: контроль над содержанием без контроля над каналами передачи неэффективен в долгосрочной перспективе. Современная Россия пытается контролировать и то, и другое, но технические ограничения (децентрализация ТСПУ) создают аналогичные уязвимости [27].

Китай: Великий файрвол как модель зрелого контроля

• Ключевое отличие: Китай строил контроль 20+ лет, параллельно развивая полноценные внутренние аналоги (WeChat, Baidu, Douyin) [27].
• Россия копирует технические решения, но не создаёт привлекательных альтернатив. Результат: высокая проницаемость барьера (36–41% используют VPN против 10–15% в Китае) [27].
• Марксистский вывод: технологический контроль без экономического базиса (конкурентных внутренних сервисов) обречён на постоянное напряжение и высокие издержки.

Иран: изоляция как кризисная модель

• Иранский опыт показывает: полная изоляция возможна, но цена — технологическая стагнация, утечка мозгов, рост социального напряжения.
• Россия движется в этом направлении, но с поправкой на размер экономики и интеграцию в глобальные цепочки. Это создаёт дополнительное противоречие: бизнес требует доступа, государство — контроля.

7. Перспективы: диалектика развития

Количественные изменения:

• Рост числа блокировок (417 тыс. ресурсов в РФ против ~300 тыс. в Китае) [33].
• Увеличение бюджета на контроль ($780 млн на 2025–2027) [27].
• Расширение полномочий ФСБ и Роскомнадзора [2] [8].

Качественный скачок произойдёт, когда:

1. Техническая инфраструктура контроля станет достаточно точной, чтобы минимизировать «побочный ущерб» (как в Китае).
2. Внутренние сервисы достигнут паритета с зарубежными по качеству (маловероятно в среднесрочной перспективе).
3. Общественное сознание адаптируется к новой норме (пока сопротивление растёт).

Вывод: политика «суверенного интернета» — это попытка решить политические задачи техническими средствами. Но диалектика материализма учит: производительные силы (интернет как глобальная сеть) вступают в конфликт с производственными отношениями (национальный контроль). Это противоречие будет обостряться, создавая условия для новых форм социальной практики — от стихийного обхода блокировок до осознанной борьбы за цифровые права.

Дальше приложил анализ который мне помогли состявить БЯМ:

Классовая структура российского ИТ-сектора в условиях изоляции

1. Материальная база: кто владеет средствами фильтрации

2. Диалектика рынка обхода: как сопротивление становится товаром

А) Коммодификация доступа

• VPN-приложения загружены 9,2 млн раз в марте 2026 — в 14 раз больше, чем год назад [15].
• Но надёжные сервисы становятся платными, требующими криптовалюты или зарубежных карт.
• Вывод: право на доступ к информации превращается в привилегию, распределяемую по платежеспособности.

Б) Классовая дифференциация в методах обхода

В) Противоречие: каждый технический ответ государства (блокировка протокола VLESS [19]) порождает новую адаптацию, но адаптация часто остаётся индивидуальной и не перерастает в коллективную практику. Это воспроизводит атомизацию, а не солидарность.

3. Технические методы с марксистской точки зрения

ТСПУ как овеществлённая классовая воля

• Системы глубокой инспекции трафика (DPI) — это не нейтральные инструменты, а материализованная функция контроля над производительными силами.
• Их установка у операторов связи — форма принудительного отчуждения: провайдер вынужден содержать оборудование, которое работает против интересов его клиентов.

Обход как присвоение средств производства

• Когда пользователь настраивает собственный прокси, он фактически присваивает средство производства коммуникации.
• Но если это делается в одиночку, результат — временное облегчение, а не изменение отношений собственности.

Коллективное присвоение как путь

• Марксистский подход: технические решения должны быть направлены на обобществление инфраструктуры.
• Примеры: кооперативные хостинги, распределённые репозитории кода, локальные зеркала образовательных ресурсов.
• Ключевое условие: организация должна быть не технической, а социальной — через доверие, взаимопомощь, разделение труда.

4. Вывод: изоляция как ускоритель классового расслоения

Политика «суверенного интернета» не устраняет неравенство — она перекодирует его в цифровой форме:

• Те, кто владеет ресурсами (деньги, знания, доступ к зарубежной инфраструктуре), сохраняют мобильность.
• Те, кто зависит от наёмного труда и государственных сервисов, оказываются в ловушке контролируемого сегмента.

Диалектический материаллизм подсказывает: противоречие между глобальным характером производительных сил (интернет) и национально-ограниченными производственными отношениями (контроль) будет обостряться. Вопрос не в том, можно ли технически обойти блокировку, а в том, кто и на каких условиях получает право на доступ к знаниям и коммуникациям.

Источники: [1]: https://abit.ee/ru/kiberbezopasnost/sovereign-internet-runet-roskomnadzor-internet-isolation-censorship-russia-internet-law-blocking-ru “Суверенный интернет в России: с 1 марта 2026 года заработал” [2]: https://pnz.ru/laws/s-1-marta-2026-goda-vstupayut-v-silu-novye-pravila-upravleniya-runetom-kak-teper-budet-rabotat-internet/ “С 1 марта 2026 года вступают в силу новые правила управления Рунетом” [3]: https://www.ec-rs.ru/blog/novosti/suverennyy-internet-s-1-marta-2026-tsentralizovannoe-upravlenie-blokirovki-i-usilenie-antifroda/ “Суверенный интернет с 1 марта 2026: централизованное управление, блокировки и усиление антифрода” [4]: https://www.rbc.ru/technology_and_media/09/11/2025/69107d8a9a79470274160bec “Власти уточнили правила вмешательства в работу Рунета — РБК” [5]: https://www.fontanka.ru/2026/03/10/76302889/ “Российский интернет станет суверенным: отключат ли нас от глобальной сети” [6]: https://www.instagram.com/reel/DQ7DqSiAaq-/ “Постановление №1667: с 1 марта 2026 года свободного интернета в России не будет” [7]: https://habr.com/ru/articles/1006424/ “Суверенный интернет: что меняется с 1 марта 2026 года и как это работает” [8]: https://habr.com/ru/news/771194/ “Суверенному Рунету исполнилось 4 года: история закона и практика” [9]: https://www.zeluslugi.ru/info-czentr/stati/sut-zakona-o-suverennom-internete-v-rossii “Закон о суверенном интернете в России: суть и последствия” [10]: https://www.quora.com/How-difficult-is-it-for-someone-in-Russia-to-access-foreign-websites-and-apps “How difficult is it for someone in Russia to access foreign websites and apps” [11]: https://en.zona.media/article/2026/04/07/russian_internet_censorship_2026 “Russia’s internet censorship in 2026: blackouts, broken payments, shrinking tools” [12]: https://www.thedailystar.net/news/world/europe/news/internet-crackdown-russia-toughens-restrictions-vpns-4152536 “Internet crackdown: Russia toughens restrictions on VPNs” [13]: https://habr.com/ru/news/1003760/ “СМИ: на конец февраля 2026 года Роскомнадзор ограничил доступ к 469 VPN-сервисам” [14]: https://meduza.io/en/news/2026/04/16/russian-telecom-companies-agree-to-freeze-expansion-of-international-network-links-to-curb-vpn-use-rbc-reports “Russian telecom companies agree to freeze expansion of international links to curb VPN use” [15]: https://www.fontanka.ru/2026/04/16/76370317/ “Ограничения VPN в России — последние инициативы и статистика” [16]: https://korrespondent.net/world/russia/4660299-cheburnet-kak-v-rossyy-khotiat-yzolyrovat-ynternet “Чебурнет: как в России хотят изолировать интернет по китайскому образцу” [17]: https://bb.lv/statja/v-mire/2024/03/12/ekspert-v-rf-vsyo-gotovo-dlya-izolyacii-ot-vsemirnogo-interneta-video “Эксперт: в РФ всё готово для изоляции от всемирного интернета” [18]: https://www.tbank.ru/invest/social/profile/victorkoch/d3101a8f-eea6-4a61-9958-16ca5d6e0746/ “Как блокировки угрожают бизнесу и интернету: долгосрочные последствия изоляции” [19]: https://prohoster.info/blog/administrirovanie/kogda-iz-interneta-budut-delat-cheburnet-obzor-proekta “Когда из интернета будут делать «чебурнет»: обзор проекта и технические условия” [20]: https://goodlucker.ru/zakon/cheburnet.html “Чебурнет: закрытый интернет в России — главные особенности и сценарии работы” [21]: https://club.dns-shop.ru/digest/157598-v-rossii-prinyali-pravila-pozvolyauschie-izolirovat-runet-i-filtr/ “В России приняли правила, позволяющие изолировать Рунет и фильтровать трафик через ТСПУ” [22]: https://vpnblog.ru/russian-internet-control2024/ “Чебурнет наступает: как меняется интернет-ландшафт России в 2024” [23]: https://vvvtv.ru/tehnologii/internet/cheburnet/ “Чебурнет — уже насущная реальность: технология глубокой фильтрации трафика”

Расскажу про то как один параметр в кофиге Wireguard причинил мне опыт по разбору половины сетевых настроек Ubuntu. Один с виду безобидный параметр… IaC блин нужен обязательно. Я просто забыл что и для чего менял, а потом уже поздно было вспоминать.

Симптомы: тишина в эфире и гора dropped пакетов

Всё началось с того, полсе смерти системного диска в моем домашнем сервере, я перестал крутить его 24/7 и набегами по выходным конифгурировал его, пытаясь вернуть привычный набор сервисом. И вот однажды включаю я сервер, а у меня проблема с системным резолвом DNS. Так-то напрямую nslookup ya.ru 8.8.8.8 выдает всё нормально. но система ни в какую не хочет резолвить адреса. Так-то я забыл, что неделей ранее я настраивал Wireguard со своими VPS, и что именно после настройки Wireguard сервер потерял доступ к локальной сети и интернету. начал ковырять, ИИшка подсказала что на Ubuntu надо netplan копать, начал фигачить yamlики, тут время вышло и я еще на неделю забросил комп. И вот вчера, сейчас далеко за полночь, я его включил и опять начал разбираться, естественно забыл не только то что я две недели назад делал, но и то чем неделю назад занимался. И вот картинка, сервер загрузился, подозрительно долго грузился кстати, но по сети недоступен.

Первая диагностика через ip -s link show показала тревожную картину на интерфейсе eno1:

• RX: 53 000+ пакетов принято.
• Dropped: 21 000+ пакетов отброшено.
• TX: Всего 40 пакетов отправлено.

Команда ip route show выводила только маршрут для интерфейса wg0. Маршрута по умолчанию через физический интерфейс не было. Система «не видела» шлюза.

Команда ip a показала, что на всех интерфейсах, кроме loopback, ip-адреса отсутствуют.

Попытки перезапустить службы или применить конфигурацию через sudo netplan apply не давали результата. Интерфейс зависал в состоянии configuring, а адрес не присваивался.

Расследование: кто виноват?

1. Конфликт маршрутизации

Первоначальная гипотеза была в том, что WireGuard перехватывает весь трафик. Однако в конфиге wg0.conf параметр AllowedIPs был ограничен подсетью туннеля (10.8.0.0/24). Он не должен был блокировать локальную сеть.

Проблема оказалась глубже: отсутствие маршрута по умолчанию для eno1 означало, что ядро просто не знало, куда девать исходящие пакеты, кроме как в туннель (если бы он был активен) или в никуда.

2. Почему DHCP молчал?

Ubuntu 24.04 использует стек systemd-networkd для управления сетью на серверных сборках. Конфигурация задается через Netplan (YAML-файлы).

Проверка статуса показала:

1
2

networkctl status eno1
State: routable (configuring)

Статус configuring в сочетании с routable — это классический признак того, что демон ждет завершения какой-то операции. В логах journalctl -u systemd-networkd не было ошибок получения адреса IPv4, зато постоянно терялась аренда IPv6 (DHCPv6 lease lost).

Оказалось, что systemd-networkd по умолчанию пытается настроить и IPv4, и IPv6. Если сервер DHCPv6 не отвечает или есть проблемы с Router Advertisements (RA), демон может зависнуть в ожидании, блокируя переход интерфейса в полностью рабочее состояние для IPv4.

3. Долгая загрузка

При перезагрузке я заметил, что система висит на этапе Job systemd-networkd-wait-online.service. Однако служба wait-online держала систему, пока сеть не поднимется. Поскольку сеть не могла подняться из-за зависшего DHCP-клиента, загрузка затягивалась.

Решение: поэтапный демонтаж проблем

Шаг 1. Отключение ожидания сети

Чтобы система загружалась быстро, даже если сеть сбоит, отключил службу ожидания:

1
2

sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service

Шаг 2. Отключение IPv6

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

В /etc/sysctl.conf добавил:

1
2
3

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1

И применил изменения: sudo sysctl -p.

Шаг 3. Переход на прямую конфигурацию systemd-networkd

Файлы Netplan (/etc/netplan/*.yaml) генерируют конфиги для бэкенда. У меня их было два, и они могли конфликтовать или содержать избыточные параметры, тем более я уже и не помнил как и почему я их именно так писал. Изолировал прослойку Netplan, создав файл-заглушку /etc/systemd/network/10-eno1.network с настройками для systemd-networkd:

1
2
3
4
5
6
7
8

[Match]
Name=eno1

[Network]
DHCP=ipv4
IPv6AcceptRA=no
DNS=1.1.1.1
DNS=8.8.8.8

Ключевой момент здесь — DHCP=ipv4. Тут явно говорим демону: «Используй только IPv4, игнорируй IPv6». Параметр IPv6AcceptRA=no дополнительно страхует от ожидания сообщений роутера.

Удалил старые файлы из /etc/netplan/, чтобы избежать двойного применения настроек, и перезапустил службу:

1

sudo systemctl restart systemd-networkd

Интерфейс сразу получил адрес 192.168.1.3 и перешел в статус routable (configured). Системный резолв DNS заработал.

Шаг 4. Финальный босс: DNS и WireGuard

Пинги пошли, но nslookup ya.ru выдавал таймауты на 127.0.0.53 (локальный stub-resolver systemd-resolved). Вот про эту штуку я не знал, поэтому теперь знаю что не нужно поднимать на каждом сервер unbound, в systemd все есть из коробки.

Проверка resolvectl status показала странность:

• Link 2 (eno1): DNS Servers: 1.1.1.1, 8.8.8.8
• Link 5 (wg0): DNS Domain: ~.

Правда я её не заметил сперва, но консультации с ИИ не всегда являются потерей времени. Символ ~. означает «глобальный поиск». WireGuard, увидев в своем конфиге строку DNS = 1.1.1.1, автоматически сообщил системе, что этот DNS-сервер должен обрабатывать все запросы, перекрывая настройки физического интерфейса. Но так как туннель до собственных серверов и маршрутов до внешних DNS в нём нет, разрешения имен не работали.

Решение: В файле /etc/wireguard/wg0.conf я закомментировал всего лишь одну строку, как потом выяснилось добавленной в конфиг по рекомендаци такой же ИИшечки:

1

# DNS = 1.1.1.1

Переподнял туннель:

1
2

sudo wg-quick down wg0
sudo wg-quick up wg0

Теперь wg0 имеетв выводк networkctl status eno1 Current Scopes: none, а все DNS-запросы идут через основной интерфейс eno1 на публичные серверы Cloudflare и Google.

Итоги и выводы

1. WireGuard и DNS: Параметр DNS в конфиге WireGuard — это не просто рекомендация, а команда для системы изменить глобальные настройки резолвинга. Если ты не хочешь, чтобы туннель перехватывал все DNS-запросы, не указывай этот параметр в конфиге клиента, либо используйте более тонкие настройки Domains (если клиент поддерживает).
2. Ubuntu 24.04 и IPv6: По умолчанию включенный IPv6 может вызывать задержки при получении адреса IPv4, если инфраструктура не готова к v6. В домашних лабораториях его часто проще отключить, чем дебажить RA и DHCPv6.
3. Netplan vs systemd-networkd: Netplan удобен, но иногда прямая конфигурация systemd-networkd дает больше прозрачности и контроля, особенно при отладке сложных случаев с DHCP.
4. systemd-networkd-wait-online: На серверах, где сеть может падать или долго подниматься, эту службу лучше маскировать, иначе она будет тормозить загрузку всей ОС.

Эта ошибка в конфиге WG стоила мне нескольких часов, но теперь моя домашняя лаборатория работает стабильно, а конфиги приведены к минимальному и понятному виду, а я узнал еще что-то новенькое про любимый Линукс.

(Ссылка на диалог с Qwen)[https://chat.qwen.ai/s/0cfbc11b-dae3-4dba-bfaf-b0788172d07c?fev=0.2.45]