Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода — актуализация 2026

Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода

Архивное переиздание с актуализацией. Оригинал опубликован на Habr (2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.

TL;DR — версия 2026

Тематическая статья сохранена в архиве; ниже — что в ней осталось актуальным к 2026 и что изменилось.

Мы сохраняем оригинал как исторический артефакт эпохи, когда об инфраструктуре сети и безопасности можно было писать открыто. К 2026 контекст изменился: по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов, ТСПУ (DPI-боксы) стоят у всех крупных российских провайдеров и умеют резать VPN-хендшейки WireGuard, OpenVPN и «голый» Shadowsocks, и часть инструментов статьи уже не выдерживает реальности, а часть — классика, которая не устареет.

Статус оригинала

URL: https://habr.com/ru/articles/1027276/
Статус на Habr: ЖИВА — ВОССТАНОВЛЕНА (удалена 29.07.2026, вернули; снимок Wayback от 21.10.2026)
Картинки: 14/14 сохранено локально

Что стоит знать в 2026

Общий вектор с момента публикации: протоколы без маскировки умирают первыми; всё, что не шифрует метаданные, видно оператору; персональные данные в логах — главный риск администратора. Проверяйте любую инструкцию из старых статей по трём вопросам: (1) виден ли протокол DPI, (2) куда утекает DNS, (3) где физически и юридически живут сервер и логи.

Иллюстрации из оригинала

Иллюстрация из оригинала статьи

Что изменилось с 2026 года

все внешние ссылки проверены на живость в момент переиздания
версии ПО из текста — исторические, актуальные см. в репозиториях проектов
в тексте оригинала: у «ванильного» WireGuard статичный хендшейк — DPI его режет; обфусцированный вариант — AmneziaWG

Чек-лист 2026

перепроверять команды на актуальной ОС
искать живой форк инструмента, если оригинал мёртв
сохранять копию гайда локально

Вердикт

Архив существует, чтобы такие тексты не исчезали. Оригинал — ниже, без купюр: читайте его как документ времени.

ОРИГИНАЛ СТАТЬИ (без изменений)

Привет, Хабр!

Думаю вы уже в курсе что происходит в РФ с белыми списками. кратко: в РФ работают белые списки, ТСПУ в режиме drop-all пропускает только одобренные IP + SNI, рунет медленно но верно становится ИнТрАнЕтОм. Я об этом писал в Чебурнет 2026 и DPI IS ALL YOU NEED, но там было больше про историю и законы.

А здесь будет только техника. как это работает, как мы это сканировали, что нашли.

Статья основана на результатах сканирования белых списков через мобильный интернет Мегафона. Весь код и данные лежат в репозитории - openlibrecommunity/twl (обновляется в идеале еженедельно).

Что такое белые списки

Иллюстрация из оригинала статьи

Если у вас открывается vk.com но не открывается google.com - Это ТСПУ работающий в режиме белых списков. Физический сигнал у вас есть. Байты идут. Просто ТСПУ решает какие байты пропустить, а какие дропнуть.

Классические блокировки работают по принципу чёрных списков - “запрещено X, Y, Z, остальное можно”. Белые списки работают наоборот: запрещено всё, кроме явно разрешённого.

Архитектура фильтрации: L3 + L7

Начнём с самого важного. Белые списки работают на двух уровнях одновременно.

Уровень 1 (L3, сетевой) - CIDR-фильтрация по IP. Список разрешённых подсетей. Пакет идёт не к разрешённому IP -> drop на маршрутизаторе ещё до DPI.

Уровень 2 (L7, приложения) - DPI проверяет SNI в ClientHello. Даже если IP разрешён, но SNI в чёрном списке - RST.

Порядок такой:

Пакет → [L3: IP в белом списке?]
          ↓ НЕТ → DROP (пакет просто исчезает)
          ↓ ДА
       [L7: SNI в чёрном списке?]
          ↓ ДА → RST (соединение рвётся)
          ↓ НЕТ → PASS (трафик идёт)

Разберём оба уровня по порядку.

L3: пакеты физически не выходят наружу

Для не-вайтлист IP (Google, Telegram, Twitter) не работает вообще ничего. Ни ICMP, ни TCP:80, ни TCP:443, ни произвольный UDP. 100% packet loss по всем направлениям.

Пакеты физически не покидают сеть оператора. Маршрутизатор на 2-м прыжке просто не пускает трафик дальше, если dst IP не в списке.

Для вайтлист IP картина другая:

Протокол/порт

Статус

ICMP

TCP:80

TCP:443

UDP:443 (QUIC)

NO_RESP

UDP:53

NO_RESP

UDP:51820 (WireGuard)

NO_RESP

| Протокол/порт | Статус | | ICMP | OK | | TCP:80 | OK | | TCP:443 | OK | | UDP:443 (QUIC) | NO_RESP | | UDP:53 | NO_RESP |

UDP:51820 (WireGuard)	NO_RESP

TCP 80/443/22 работают. Всё остальное мимо. Фильтрация идёт не только по IP, но и по портам. UDP режется почти весь - включая QUIC, DNS и логично WireGuard на стандартных портах. в зависимости от оператора ситуация может меняться, но обычно все именно так.

L7: как ТСПУ читает SNI

Если IP в белом списке, ТСПУ смотрит на SNI внутри TLS ClientHello.

Для проверки - берём вайтлист IP Яндекса и пытаемся подключиться с разными SNI:

SNI

Результат

ya.ru

TLS handshake OK, HTTP 302

google.com

TLS handshake OK, HTTP 406

twitter.com

Connection reset by peer

telegram.org

TLS handshake OK, HTTP 406

telegram.org	TLS handshake OK, HTTP 406

google.com прошёл. Казалось бы, странно - гугл же заблокирован. Но нет, гугл заблокирован только по IP, а в чёрном списке SNI его нет. Моя теория - если бы туда запихнули google.com - легли бы тысячи легитимных сервисов, которые ходят на Google API через свои собственные IP. Поэтому в SNI-блеклисте только совсем явные вещи: твиттер, отдельные домены заблокированных ресурсов и… но почему то заблокированный telegram SNI все равно отдает OK, почему - я так и не выяснил.

Забавный нюанс - правила SNI-фильтрации неконсистентны между подсетями:

SNI

через 77.88.55.242 (Яндекс)

через 87.240.132.78 (VK)

через 217.20.147.1 (MAX)

FAIL

FAIL

| SNI | через 77.88.55.242 (Яндекс) | через 87.240.132.78 (VK) | через 217.20.147.1 (MAX) | | telegram.org | OK | FAIL | OK | | youtube.com | OK | OK | OK | | google.com | OK | OK | OK |

twitter.com	OK	FAIL	FAIL

Один и тот же SNI через Яндекс пропускается, через VK и MAX - режется. Либо правила ТСПУ разные для разных ASN, либо на каких-то узлах их забыли обновить. Факт в том, что единого общего чёрного списка SNI нет.

Где физически сидит ТСПУ

Когда пакет идёт по сети, у него есть счётчик - TTL. Каждый роутер на пути уменьшает его на единицу. Линукс начинает с 64. Получил пакет с TTL 53 - значит он прошёл 11 роутеров. Получил с TTL 62 - всего два.

Теперь смотрим что приходит от Яндекса и что приходит от Телеграма (заблокированного):

Ответ от ya.ru - TTL 53. Одиннадцать хопов, это настоящий сервер где-то далеко.

“Ответ” от Telegram - TTL 62. Два хопа. Не может сервер Телеграма быть так близко.

Значит никакого ответа от Телеграма не было. Ответ сгенерировало устройство которое стоит прямо у оператора, сразу за первым роутером:

[Ты] → [роутер оператора] → [ТСПУ] → [интернет]

Сканирование: что внутри белого списка

Если ТСПУ отвечает RST для заблокированных IP и пропускает только разрешённые - значит можно просто прогнать masscan по всем российским подсетям через интерфейс с БС и получить полный список того, что пропускается.

Так и сделали. Источник - 80 600 российских подсетей (RU allocation от RIPE). Логика: порт 443 открылся через БС — значит IP в списке.

Дисклеймер: мы любители. Masscan долбит как сумасшедший и теряет пакеты пачками, половина IP на 443 просто никого не слушает, часть отвечает через раз. Реальные цифры могут плавать на 20-30%. Но мы не академический институт с финансированием и не пишем статью в журнал, для понимания масштаба хватит.

Итого: 63 126 IP в белом списке. 2 557 уникальных ASN. Из 46 миллионов российских адресов через БС пропускается ~0.14%.

Топ-15 ASN по количеству IP:

ASN

Организация

AS200350

Yandex.Cloud

12 906

AS9123

Timeweb

2 904

AS12389

Ростелеком

2 312

AS47764

1 958

AS34879

ССТ

1 806

AS198610

Beget

1 644

AS57363

CDNvideo

1 638

AS29182

IOT

1 591

AS197695

REG.RU

1 380

AS49505

Selectel

1 037

AS13238

YANDEX LLC

978

AS50340

Selectel

917

AS3216

Билайн

884

AS210079

EuroByte

869

AS47541

791

| # | ASN | Организация | IP | | 1 | AS200350 | Yandex.Cloud | 12 906 | | 2 | AS9123 | Timeweb | 2 904 | | 3 | AS12389 | Ростелеком | 2 312 | | 4 | AS47764 | VK | 1 958 | | 5 | AS34879 | ССТ | 1 806 | | 6 | AS198610 | Beget | 1 644 | | 7 | AS57363 | CDNvideo | 1 638 | | 8 | AS29182 | IOT | 1 591 | | 9 | AS197695 | REG.RU | 1 380 | | 10 | AS49505 | Selectel | 1 037 | | 11 | AS13238 | YANDEX LLC | 978 | | 12 | AS50340 | Selectel | 917 | | 13 | AS3216 | Билайн | 884 | | 14 | AS210079 | EuroByte | 869 |

15	AS47541	VK	791

Яндекс.Облако - 12 906 IP. Каждый пятый адрес в белом списке принадлежит им. Yandex.Cloud тупо хостит половину сервисов, от которых зависит государство, и выкинуть его из БС невозможно. Именно поэтому это главная точка для обхода .

VK через три разных ASN набирает ~3000 IP. Selectel - почти 2000 через два ASN. Timeweb - 2904. Мобильные операторы тоже в списке - МТС (531), Билайн (884), МегаФон (236), их внутренняя инфраструктура.

А еще почему то мемы.смешные.online нету в белых списках, кто знает почему?

Иллюстрация из оригинала статьи

Что не так с этим списком

Агрегировал все IP в /24 подсети. Считал плотность - сколько IP из 256 попадает в БС.

Максимальная плотность: 37.5%. Подсетей с плотностью 50%+: ноль.

Плотность

Подсеть

Владелец

37.5%

185.71.67.0/24

Storm Networks

34.4%

95.129.236.0/24

DDOS-GUARD

32.0%

87.240.166.0/24

VK CDN

31.6%

87.240.167.0/24

VK CDN

31.6%

77.88.0.0/24

Яндекс

30.1%

31.31.198.0/24

REG.RU

| Плотность | Подсеть | Владелец | | 37.5% | 185.71.67.0/24 | Storm Networks | | 34.4% | 95.129.236.0/24 | DDOS-GUARD | | 32.0% | 87.240.166.0/24 | VK CDN | | 31.6% | 87.240.167.0/24 | VK CDN | | 31.6% | 77.88.0.0/24 | Яндекс |

30.1%	31.31.198.0/24	REG.RU

Почему не 100%? Потому что masscan находит только IP где реально что-то слушает на 443. В подсетях много пустых адресов без серверов. Но фильтрация-то идёт по CIDR целиком - то есть вся подсеть /24.

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

DNS в режиме белых списков

Отдельная история с DNS у МЕГАФОНА. Проверял доступность разных DNS-серверов.

Все внешние DNS - TIMEOUT:

DNS

Статус

8.8.8.8 (Google)

TIMEOUT

1.1.1.1 (Cloudflare)

TIMEOUT

77.88.8.8 (Яндекс)

TIMEOUT

10.233.58.133 (Мегафон)

РАБОТАЕТ

10.233.58.133 (Мегафон)	РАБОТАЕТ

Порт UDP:53 на любые внешние DNS закрыт. Работает только DNS самого провайдера.

Пример - curl max.ru резолвится и работает, потому что использует DNS Мегафона. Попробуй dig @8.8.8.8 ya.ru - timeout.

И опять - это зависит от провайдера. У разных операторов разные правила.

География: где и когда работает БС

Белые списки работают неравномерно:

Регион

Режим работы

Москва

Эпизодически, ~3 часа

Санкт-Петербург

Редко, бывают недели без БС

Большинство регионов

Постоянно 24/7

Большинство регионов	Постоянно 24/7

Зависит от региона И от провайдера. У Мегафона и Т2 в одном регионе БС работает постоянно, в другом включается по расписанию. У МТС свои правила. У Билайна свои.

Даже не регионы — районы. Точки. Едешь по городу и видишь полную энтропию: на одной остановке работает один IP, на следующей он уже недоступен, а ещё через километр БС вообще отключены и интернет внезапно нормальный. Что именно в белом списке - тоже меняется от точки к точке. Подробнее в разделе про приоритеты.

Вот наглядный пример из чата olc - человек в реальном времени описывает, как обход БС и сам БС работают от вышки к вышке.

Иллюстрация из оригинала статьи

Кстати, обход тут через olcng, наш бесплатный opensource инструмент.

И списки тоже разные у разных операторов. Одна подсеть в БС у Мегафона может не быть у МТС.

Списки постоянно меняются. Что-то добавляют, что-то убирают. Поэтому у нас в olc есть репа где это еженедельно обновляется - openlibrecommunity/twl.

Приоритеты в белых списках

После анализа получается такая иерархия:

1 уровень (обязательный) - max.ru. Всегда в БС. У всех. Везде. Этот мессенджер можно даже не проверять - он работает всегда.

2 уровень (почти всегда) - vk.com, ya.ru, Государственно значимая инфраструктура.

3 уровень (необязательный) - банки, маркетплейсы, прочие сервисы. Тут лотерея: у Мегафона может быть Тинькофф, а у МТС - нет. Логики никакой.

Забавная деталь: почти все банки в БС - кроме Сбербанка. При этом salutejazz.ru - сервис видеозвонков от сбера - есть. Крупнейший банк страны недоступен, а его корпоративная видеозвонилка которой пользуется полтора землекопа - пожалуйста.

Отдельный жанр: VPN в белом списке

Когда просканировал список доменов по whitelisted IP, обнаружил кое-что. В белом списке полно VPN-сервисов. Государство душит VPN на L7 через TLS-фингерпринты, режет протоколы, банит сервисы - а в собственном белом списке лежат сотни серверов со словом vpn в домене. Вот просто навскидку:

Иллюстрация из оригинала статьи

**zalupavpn.dpdns.org** - без комментариев.

**vpn.gov45.ru** - государственный VPN (Курганская область)

**russvpn.ru**, **vpn-russia.cherna.ru** - патриотические, тоже пропускаются.

И это только VPN. А ещё есть GitLab.

Пока рыл список, случайно наткнулся на ittask-git.gitlab.yandexcloud.net. Попробовал curl через БС:

Иллюстрация из оригинала статьи

Открывается. Страница логина GitLab, через мобильный инет в режиме белых списков. Не через VPN, не через прокси - напрямую.

Иллюстрация из оригинала статьи

Что не работает в БС

Сначала закроем тему методов которые **не помогут **( в зависимости от провайдера может менятся ):

QUIC/HTTP3 - иногда блокируется даже на домашних провайдерах без БС. UDP:443 режется. В режиме БС тем более.

ECH/ESNI (Encrypted Client Hello) - блокируется ТСПУ. И даже если бы работал, не помог бы. Потому что основная блокировка идёт по IP (L3), а не по SNI. Шифровать имя домена бесполезно, когда сам адрес назначения не в белом списке.

Обычный VPN на обычном VPS за границей - не работает тк IP не в БС.

Что работает и как их обойти

Метод 1: VLESS + Reality на российском VPS

Основной метод. Работает стабильно, относительно просто настраивается.

Требования:

IP сервера в белом списке (VPS у Timeweb/Yandex/VK)

SNI whitelisted домена (vk.com, ya.ru, vklive.enotfast.com)

Reality + XTLS-Vision для маскировки

Пример конфига:

vless://UUID@IP:443?type=tcp&security=reality&pbk=...&fp=chrome&sni=vklive.enotfast.com&sid=...&flow=xtls-rprx-vision

Где брать VPS:

Провайдер

Плюсы

Минусы

Timeweb

Бесплатный reroll IP

Долго выбивать, но дело времени

Yandex.Cloud

Бесплатный грант 4000₽ при регистрации, высокий шанс попасть в БС

Быстро сносят

VK Cloud

Долго держится

Сложная верификация и сложно выбивать, дорого

VK Cloud	Долго держится	Сложная верификация и сложно выбивать, дорого

Хорошие SNI для маскировки (из сканирования 1176 whitelisted доменов):

Яндекс CDN: storage.yandex.net, yastatic.net

VK CDN: userapi.com, vkuser.net, vkuservideo.ru

Хостинги: hosting.reg.ru

CDN: cdnvideo.ru, okcdn.ru

Остальные из списка openlibrecommunity/twl

Опасные SNI - те которые проверяются:

twitter.com / x.com / youtube.com - RST через некоторые IP

Всё что очевидно заблокировано

Метод 2: Yandex Cloud Functions

Serverless-функция как прокси. Эндпоинт functions.yandexcloud.net универсально в БС у всех провайдеров.

Free tier (бессрочный, ежемесячно):

1 000 000 вызовов

100 000 ГБ-секунд

40 000 ГГц-секунд

Пишешь SOCKS5 клиент, подключаешь к функции - готово. DPI не применяется к IP Яндекса на уровне L3 и L7, домены *.yandexcloud.net в белом списке SNI/CIDR у всех провайдеров.

Минусы - нужна карта для верификации Yandex Cloud, производительность хуже чем у прямого VPS.

Метод 3: Yandex API Gateway

UPD: после моей статьи этот способ забанили

Новый способ от olc, представляющий собой настоящий абуз инфраструктуры Яндекса. Мы используем Yandex API Gateway как прокладку (зеркало) между нами и нашим сервером (VPS), IP которого не входит в белые списки.

Как это настроить:

Берем свой домен. например, furry.xiqull.xyz и делегируем его на Cloudflare.

Идем в Yandex Cloud -> Certificate Manager. Выпускаем бесплатный Let’s Encrypt сертификат на наш домен.

Иллюстрация из оригинала статьи

Проходим валидацию: добавляем CNAME запись _acme-challenge... в Cloudflare указывающую на сервер Яндекса, выключаем “оранжевое облако”, оставляя проксирование только по DNS, Ждем выпуска сертификата.

Иллюстрация из оригинала статьи

Создаем API Gateway в Yandex Cloud.

Иллюстрация из оригинала статьи

В спецификации OpenAPI прописываем проксирование всех запросов на IP (или домен) вашего сервера, на котором крутится Nginx.

Иллюстрация из оригинала статьи

В разделе “Домены” вашего API-шлюза привязываем наш домен и выпущенный сертификат.

Иллюстрация из оригинала статьи

Наконец, в Cloudflare добавляем CNAME запись, которая направляет наш домен на служебный домен Yandex API-шлюза

например, d5dbrua4t7rk7alm539p.iwzqm34r.apigw.yandexcloud.net в этом случае*

Пример OpenAPI спецификации для шлюза:

openapi: 3.0.0
info:
  title: имя
  version: 1.0.0
servers:
- url: https://ур.лэ.apigw.yandexcloud.net
- url: https://са.й.т
paths:
  /{proxy+}:
    x-yc-apigateway-any-method:
      x-yc-apigateway-integration:
        type: http
        url: http://а.й.п.и/{proxy}
      parameters:
      - explode: false
        in: path
        name: proxy
        required: true
        schema:
          type: string
        style: simple
  /:
    get:
      x-yc-apigateway-integration:
        type: http
        url: http://а.й.п.и/

Трафик от вас пойдет на железобетонно разрешенные IP Yandex Cloud API Gateway, который легитимно терминирует TLS (сертификат-то настоящий) и проксирует HTTP/HTTPS трафик на ваш спрятанный сервак.

Метод 4: olcRTC - туннель через видеозвонки

Мой проект. Писал про него отдельную статью. Принцип: паразитируем на whitelisted сервисах видеозвонков. Трафик идёт через WebRTC SFU. самый сложный в настройке но почти бесплатный и работает везде где работает telemost/jazz/wbstream.

Каналы:

Канал

Статус

Скорость

DataChannel

Работает

до 10 MB/s

V8 Channel

В разработке

~1 MB/s

VideoChannel

В разработке

~100 KB/s

VideoChannel	В разработке	~100 KB/s

Сервисы: telemost.yandex.ru, salutejazz.ru, stream.wb.ru.

Самый стабильный - wbstream от Wildberries. У них почти нет прослойки посередине которая анализирует трафик, почти прямой relay. Говнокод спасает.

Статус: пре-альфа. Подробности в репо openlibrecommunity/olcrtc.

Метод 5: xDNS

Туннелирование через DNS-запросы.

Работает только там где UDP:53 к внешним DNS открыт.

Схема:

Клиент → 8.8.8.8 → "кто NS для f.example.com?" → fns.example.com (твой сервер:53) → Xray

Скорость низкая - природа DNS-протокола. Не для HD-видео, но для текста и ssh хватит. MAN тут happchat/78343/172504

Метод 6: TURN relay

UPD: (Wed Apr 29 12:15:47 AM MSK 2026) - пофиксили, VK теперь шейпит до 250кбс

Использование публичных TURN серверов VK/Яндекса для relay WireGuard.

Работает - но быстро банят. Яндекс уже заточил свои TURN серверы relay’ить только на IP Яндекса. VK натыкал капч.

Время жизни: непредсказуемо. Но дырка новая появляется регулярно, потому что компании сами же их и делают. есть реализация от cacggghp/vk-turn-proxy

Битва методов

Метод

Сложность

Стоимость

Стабильность

Скорость

VLESS + Reality на VPS

Низкая

~2000₽/мес

Высокая

Yandex Functions или API Gateway

Средняя

Бесплатно (free tier каждый месяц)

Высокая

Средняя

olcRTC

Высокая

VPS

Средняя

xDNS

Высокая

Домен + VPS

Низкая

TURN relay

Средняя

VPS

Низкая

Средняя

TURN relay	Средняя	VPS	Низкая	Средняя

Обычный ТСПУ никуда не делся

Кстати: белые списки это не замена обычных блокировок, а слой поверх них. Тот же ТСПУ что на домашнем провайдере рубит запрещённые домены по чёрному списку и палит VPN по TLS-фингерпринтам - здесь работает точно так же. Просто до него твои пакеты ещё должны пройти через L3-фильтр белого списка.

Это значит:

Нужна маскировка под браузер (uTLS в Xray/Sing-box)

fp=chrome или fp=firefox в конфиге обязательно

Reality сама по себе не спасает если фингерпринт палевный

Всё что блокируется на домашнем инете - блокируется и тут, сверху

Что делать сейчас

Да ничего особо. На домашнем инете чебурнет не наступит, БС - это история про мобильный инет, и то не везде.

Так что подписывайся на наш тгк, там выкладываем новые способы и обновлённые списки.

Иллюстрация из оригинала статьи

Итого

Запрещено всё, разрешено избранное.

Что мы точно знаем по экспериментам:

Фильтрация двухуровневая: L3 (IP) + L7 (SNI)

ТСПУ на 2-м хопе, генерирует RST для заблокированных IP

UDP режется почти полностью - DNS, QUIC, WireGuard

63 тысячи IP в белом списке из 46 миллионов.

Работает неравномерно - по регионам, районам и провайдерам

У каждого оператора свой белый список. Но есть те кто в нём всегда.

Что работает для обхода:

VLESS + Reality на российском VPS - основной метод

Yandex Cloud Functions - универсальный вариант

olcRTC - экспериментально, через видеозвонки

xDNS - если UDP:53 открыт

Наши контакты

Гитхаб: openlibrecommunity

Код сканера и пруфы: openlibrecommunity/twl

Телеграм канал: t.me/openlibrecommunity ( фри прокси для обхода бс в закреп посте )

По проблемам: zarazaex@tuta.io

UPD: ребята, мой сайт смешные.online теперь в БС, не рофл, сами чекните

UPD: я не спал часов 13, пишу эту статью, мой баланс на симке ушел в минус, я не знаю залетит ли это, я не знаю что со мной будет и одобрят ли статью, LOL

UPD: еще есть темка с абузом сертификатов для обхода БС, но об этом как нить позже

UPD: оказывается хабр и докер есть в БС Поддержать нас донатом

РУБЛИ. СБП, КАРТА: pay.cloudtips.ru/p/28c476e5

КРИПТА. TON, USDT: UQD_Qc2cxLGe1P4wANi46cKdEvvzyJRrJTYPvGX2KAZDnsDh

КРИПТА, TRC 20, USDT: TYQqdACH5PrScvsMowSyS8JjaaF5wvFf5Q

КРИПТА, BTC: bc1qvw0ts0jk5e5dfj9fdez76j9ck95lqz04fpf02a