Свой луна-парк с блэкджеком и нейронками: Восстанавливаем доступ к AI-сервисам без VPN

На дворе конец 2025 года. Если вы разработчик, дата-сайентист или просто энтузиаст технологий в РФ, то ваше утро начинается не с кофе, а с проверки того, какой еще сервис решил, что вы ему больше не нравитесь.

Ситуация уникальна тем, что мы находимся под перекрестным огнем. С одной стороны — гео-блокировки со стороны самих сервисов (OpenAI, Anthropic, Google, Microsoft), которые закрывают доступ для пользователей из России. OpenAI показывает “Access Denied”, Claude вежливо сообщает, что он “не доступен в вашем регионе”, а Google Gemini делает вид, что вас не существует.

С другой стороны — нестабильность самих каналов связи. Привычные VPN-протоколы периодически “штормит”, соединения отваливаются, а скорость падает до модемных времен из-за особенностей фильтрации трафика на магистралях.

Казалось бы, выход есть — старый добрый VPN. Но сегодня это решение с кучей “но”. Даже если вы нашли протокол, который не блокируется, остается проблема маршрутизации. Гонять весь трафик через Амстердам, чтобы просто спросить у ChatGPT, как отцентровать div — это как стрелять из пушки по воробьям. Банковские приложения начинают паниковать, отечественные стриминговые сервисы грузятся с задержкой, а пинг в играх вызывает желание разбить клавиатуру. К тому же, постоянное переключение тумблера утомляет, а забытый включенный клиент быстро высаживает батарею.

Нам нужно что-то более элегантное. Хирургическое. Нам нужен Split Tunneling, но не на уровне приложения VPN, а на уровне всей сети. Чтобы openai.com шел через “заграницу”, а gosuslugi.ru — напрямую.

Сегодня мы пройдем путь от “я просто хочу, чтобы оно работало” до создания собственного комбайна для маршрутизации трафика. Мы разберем существующие решения, поймем, почему они нам не подходят, и соберем свой собственный шлюз на базе Nginx (или Angie) и DNS-сервера, который будет делать магию прозрачно для всех ваших устройств.

Юридическая справка (Disclaimer)

Я не юрист, это не юридическая консультация.

Важно: С 1 марта 2024 года в РФ действует запрет на популяризацию средств обхода блокировок (Приказ РКН № 168).

Данная статья носит исключительно научно-технический характер.

1. Я рассматриваю технологии маршрутизации трафика (SNI Proxy, DNS) и преодоления гео-блокировок, наложенных иностранными сервисами (OpenAI, Google, Anthropic) на пользователей из РФ.

2. Техническое примечание: Описываемый метод (SNI Proxy) не скрывает имя запрашиваемого сайта (SNI передается в открытом виде). Поэтому он технически непригоден для обхода блокировок ТСПУ (DPI) на ресурсах, запрещенных законодательством РФ.

---

Часть 1: А что, есть варианты?

Прежде чем открывать терминал и писать конфиги, давайте посмотрим, что предлагает рынок. Может, велосипед уже изобретен?

1. Решения операторов: Анатомия “Telegram-прослойки”

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

Что предлагают операторы:
Обычно это доступ к ChatGPT, Gemini, Claude, Midjourney и подобным сервисам через специальные тарифы, агрегаторы “нейронок” или веб-чаты с подпиской.

С технической точки зрения ^[1], все они реализованы по схеме API Wrapper (через Telegram или Web).

Как это устроено:

1. Frontend: Telegram-бот. Это идеальный интерфейс: не нужно пилить свое приложение, а авторизация пользователя происходит нативно по номеру телефона (Telegram ID привязывается к биллингу оператора).

2. Middleware: На серверах оператора крутится бэкенд, который держит постоянный зашифрованный туннель до зарубежных дата-центров.

3. Backend: Оператор покупает Enterprise-доступ к API OpenAI/Anthropic (или использует пулы аккаунтов).

4. Flow: Вы пишете сообщение в Telegram -> Бот оператора его парсит -> Оборачивает в JSON-запрос к API OpenAI -> Получает ответ -> Отдает вам.

Почему это “не то”:
Это решение уровня L7 (Application Layer), причем сильно урезанное.

• Нет прямого доступа: Вы не получаете сетевой маршрут до openai.com. Вы общаетесь с ботом, а не с сервисом.

• Несовместимость: Вы не можете вставить API-ключ от этого бота в VS Code (Copilot), в Cursor или в свой Python-скрипт. Протокол общения проприетарный (Telegram API).

• Фильтрация: Оператор выступает как Man-in-the-Middle. Он видит все ваши запросы и может накладывать дополнительные фильтры поверх тех, что есть у OpenAI.

Это отличный продукт для масс-маркета (“поиграться с нейронкой”), но для профессиональной работы, где нужна интеграция с IDE или API, такая архитектура бесполезна.

2. А как же альтернативы? (Yandex, DeepSeek, Local)

Справедливости ради, мир не сошелся клином на OpenAI. Есть отличные YandexGPT 4 и GigaChat Max, мощные китайские DeepSeek и Qwen, а также возможность запустить Llama 3.2 локально через Ollama.

Они сделали огромный рывок, но почему мы всё равно ломимся в закрытые двери Запада?

1. SOTA (State of the Art): В сложных задачах кодинга и архитектуры GPT-5 (OpenAI), Claude 4.5 (Anthropic) и Gemini 3 (Google) всё ещё держат пальму первенства.

2. Экосистема: VS Code, Cursor, LangChain и тысячи других инструментов заточены под API OpenAI.

3. Железо: Для локального запуска моделей уровня GPT-5 вам понадобится сервер по цене квартиры, а облачные API китайцев пока не так стабильны.

Поэтому, при всем уважении к альтернативам, доступ к этой “большой тройке” нам всё ещё нужен.

3. Бесплатные Smart DNS сервисы

В сети существуют бесплатные DNS-серверы, которые делают именно то, что мы хотим: перенаправляют запросы к заблокированным ресурсам через свои прокси.

Как это работает:
Это технология Smart DNS (или DNS Hijacking во благо). Когда ваш компьютер спрашивает “Где находится microsoft.com?”, обычный DNS (например, от Google 8.8.8.8) ответит реальным IP-адресом Microsoft. Smart DNS ответит IP-адресом их сервера. Ваш трафик пойдет к ним, а они уже перешлют его в Microsoft.

Плюсы:

• Бесплатно: Вообще. Это филантропия в чистом виде.

• Простота: Прописал два IP-адреса в настройках сетевой карты (или роутера) — и всё заработало.

• Работает: Отлично справляется с обновлениями Windows, доступом к Copilot, ChatGPT и даже некоторыми стримингами.

Минусы:

• Black Box: Вы не контролируете сервер. Сегодня он работает, завтра — изменит политику, закроется или станет платным. Стабильность — величина переменная.

• Privacy (Приватность): Это самый жирный минус, о котором многие забывают ^[2]. Используя чужой DNS, вы добровольно отдаете историю ВСЕХ своих DNS-запросов третьей стороне.

  • Владелец DNS-сервера знает, на какие сайты вы ходите, когда и как часто.

  • Даже если авторы сервиса имеют хорошую репутацию и заявляют, что не собирают логи, с технической точки зрения это Man-in-the-Middle (хоть и на уровне метаданных).

  • Если сервер взломают, злоумышленники могут подменить IP-адрес вашего банка на свой фишинговый сайт.

• Скорость: Если сервера перегружены (а халяву любят все), у вас будет тормозить весь интернет, даже тот, который не блокируется (потому что DNS-запросы идут долго).

• Ограниченный список: Вы не можете добавить свой домен. Если сервис не проксирует нужный вам ресурс (например, какой-нибудь новый стартап super-ai.io), вы ничего не сможете с этим сделать. Вы зависите от админа сервиса.

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

4. API-прокси и “Обертки”

Есть класс сервисов, которые предоставляют доступ к API OpenAI/Anthropic через свои эндпоинты. Вы меняете api.openai.com на адрес прокси-сервиса, вставляете их ключ, и всё работает.

Плюсы:

• Идеально для разработки и интеграций.

• Оплата в рублях.

• Стабильность выше, чем у бесплатных решений.

Минусы:

• Цена: Обычно дороже, чем прямой доступ (наценка за сервис).

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

• Нет веб-интерфейса: Это решение для кода, а не для “початиться в браузере”.

5. Классические VPN с Split Tunneling

Некоторые VPN-провайдеры предлагают функцию раздельного туннелирования. Вы ставите клиент, указываете, какие приложения пускать через VPN, и живете спокойно.

Плюсы:

• Надежное шифрование.

• Проверенные решения.

• Работает “из коробки” (обычно).

Минусы:

• Требует клиента: Нужно ставить приложение на каждое устройство. На телефон, на ноутбук, на планшет. А как быть с телевизором? А с умной колонкой? А с PlayStation?

• Сложность настройки: Настроить списки маршрутизации на роутере (чтобы работало на всех устройствах сразу) — задача не для слабонервных. Вам придется возиться с BGP, списками IP-адресов (которые у OpenAI меняются чаще, чем настроение у подростка) и правилами фаервола.

• Батарея: Постоянно висящий VPN-процесс на телефоне кушает заряд. Шифрование требует CPU.

• Капчи: Это бич всех публичных VPN. Google видит, что с одного IP-адреса идет миллион запросов, и начинает показывать вам светофоры. Конечно, наш метод тоже от этого не застрахован, если завернуть туда весь google.com. Но прелесть своего решения в том, что мы можем точечно пустить gemini.google.com через прокси, а обычный поиск оставить напрямую. В VPN такое разделение внутри одного домена сделать крайне сложно.

• Блокировки протоколов: WireGuard и OpenVPN сейчас активно блокируются провайдерами (ТСПУ). Вам придется искать обфусцированные протоколы (VLESS, Shadowsocks, AmneziaWG), что опять же повышает порог входа.

---

Часть 2: Путь Самурая (Ручная сборка)

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

1. Прозрачной: Никаких кнопок “подключить”. Устройства просто работают.

2. Приватной: Мы не расшифровываем трафик (SNI Proxy). Мы не видим ваши пароли, мы видим только домены.

3. Управляемой: Мы сами решаем, что проксировать, а что нет.

4. Дешевой: VPS стоит как чашка кофе (300-500 рублей).

Архитектура: Два пути самурая

Прежде чем покупать сервер, нужно определиться с топологией. У нас есть два варианта, как это всё собрать.

Вариант А: “Перфекционист” (Два сервера)

Это классическая схема для тех, кто хочет идеальной скорости.

1. Сервер 1 (РФ): Это ваш промежуточный DNS-сервер (например, дешевый VPS в Москве). Он отвечает на запросы мгновенно (пинг 1-5 мс).

2. Сервер 2 (За рубежом): Это ваш SNI-прокси (Нидерланды/Финляндия). Он нужен только для доступа к AI.

• Как работает: Вы спрашиваете у российского DNS “Где Яндекс?”. Он отвечает реальным IP Яндекса. Вы спрашиваете “Где ChatGPT?”. Он отвечает IP вашего зарубежного сервера.

• Плюсы: Максимальная скорость интернета, независимость от зарубежного канала.

• Минусы: Нужно администрировать две точки. Требуется два “белых” IP-адреса (один для российского сервера, один для зарубежного), что увеличивает бюджет.

Вариант Б: “All-In-One” (Один сервер)

Это схема для тех, кто хочет “сделать и забыть”. Полная замена бесплатным Smart DNS сервисам.

1. Сервер 1 (За рубежом): На нем крутится И DNS, И SNI-прокси.

• Как работает: Вы прописываете IP этого сервера как свой DNS в настройках роутера/телефона. Все запросы летят туда.

• Плюсы: Простота. Один сервер, одна оплата, одна настройка. Работает везде (даже на мобильном интернете).

• Минусы: Пинг до DNS увеличивается (30-50 мс до Европы). Это добавляет небольшую задержку при первичном открытии сайтов (время резолвинга), что может быть заметно при активном веб-серфинге.

Выбор VPS: Квест “Оплати меня, если сможешь”

Выбор хостинга в 2025 году — это отдельная мини-игра. Нам нужен сервер с белым публичным IPv4-адресом (NAT не подойдет) и каналом хотя бы 100 Мбит/с.

Критерии выбора:

• Локация: Чем ближе к вам, тем лучше пинг. Для европейской части РФ идеальны Финляндия (Helsinki), Швеция (Stockholm), Эстония (Tallinn) или Нидерланды (Amsterdam). Для ДВ — Япония или Сингапур.

• IP-репутация: Это критически важно. Если вы возьмете самый дешевый VPS у “ноунейм” хостера, его IP может быть уже забанен в Google или OpenAI из-за предыдущих жильцов (спамеров).

• Оплата: Самая большая боль ^[3].

Варианты хостеров:

Российские хостеры с зарубежными локациями. Принимают карты МИР, СБП. Техподдержка на русском. Из минусов — часто дороже зарубежных аналогов, IP-адреса могут быть “заезженными”.

Зарубежные хостеры. Надежность, дешевизна (от ~4€), чистые IP. Из минусов — не принимают карты РФ, требуют верификацию личности (KYC) с паспортом. Как платить: карты зарубежных банков, посредники (платишь им рублями + комиссия, они платят за тебя), или криптовалюта (если хостер принимает).

Крипто-хостинги. Анонимность, оплата криптовалютой. Из минусов — часто дороже.

Технология: SNI Proxy (Магия без расшифровки)

Многие думают, что для проксирования HTTPS нужно расшифровывать трафик (MITM), подменять сертификаты и устанавливать корневые сертификаты на устройства. Это сложно, небезопасно и ломает многие приложения (Certificate Pinning).

Но есть SNI (Server Name Indication).

Представьте, что вы отправляете запечатанное письмо (HTTPS-пакет). Вы не можете прочитать содержимое письма (оно зашифровано). Но на конверте написан адрес получателя: “OpenAI, ул. Искусственного Интеллекта ^[4], д. 1”.

Когда ваш браузер начинает рукопожатие (TLS Handshake) с сервером, он открытым текстом в первом пакете (Client Hello) говорит: “Я хочу подключиться к api.openai.com“. Это и есть SNI.

Наш прокси-сервер работает как почтальон. Он:

1. Принимает конверт.

2. Читает адрес на конверте (SNI).

3. Видит “Ага, это для OpenAI”.

4. Открывает соединение с реальным сервером OpenAI.

5. Передает конверт туда.

6. Получает ответный конверт и отдает его вам.

В чем профит?

• Мы не вскрываем конверт. Шифрование остается end-to-end (от вашего браузера до сервера OpenAI).

• Сертификат остается оригинальным. Браузер видит сертификат, подписанный OpenAI, и не ругается.

• Никаких настроек на клиенте. Не нужно ставить сертификаты в систему.

В чем подвох?

• Мы видим только домен, но не URL. Мы не можем заблокировать конкретную страницу openai.com/bad-page, только весь домен openai.com. Но для нашей задачи (обход блокировок) это именно то, что нужно!

Критически важно: ECH и QUIC (Убийцы схемы)

Вся наша схема держится на том, что мы можем прочитать имя домена (SNI) из первого пакета. Но современные браузеры пытаются это скрыть. Более того, в РФ эти протоколы находятся под пристальным вниманием ^[5] ТСПУ.

1. ECH (Encrypted Client Hello): Эта технология шифрует SNI.

   • Проблема: Во-первых, наш сервер не сможет прочитать домен и не поймет, куда пересылать трафик. Во-вторых, ТСПУ в РФ активно блокируют соединения с ECH, так как не могут их инспектировать. Включение ECH часто приводит к недоступности даже незаблокированных ресурсов (например, за Cloudflare).

   • Решение: Отключите ECH в браузере.

   • Chrome: chrome://flags -> Encrypted Client Hello -> Disabled.

   • Firefox: about:config -> network.dns.echconfig.enabled -> false.

2. QUIC (HTTP/3): Протокол, работающий поверх UDP.

   • Проблема: Наш простой SNI-прокси работает по TCP. Если браузер уйдет в QUIC, он пойдет мимо прокси (и скорее всего упрется в блокировку). К тому же, UDP-трафик на 443 порту часто шейпится (замедляется) провайдерами.

   • Решение: Отключите «Experimental QUIC protocol» в флагах или заблокируйте исходящий UDP на порт 443 на клиенте. Это заставит браузер использовать старый добрый TCP, который мы умеем маршрутизировать.

Шаг 1: Настройка VPS (Nginx/Angie)

Я рекомендую использовать Angie (форк Nginx от российских разработчиков) или классический Nginx. Angie крут тем, что у него более продвинутые возможности по мониторингу и ACME (автоматические сертификаты), что нам пригодится позже.

А почему не Caddy?

Многие любят Caddy за его простоту и автоматический HTTPS. И у него даже есть модуль layer4 для SNI-проксирования. Казалось бы, идеальный кандидат?

К сожалению, всё не так радужно. Во-первых, модуль layer4 не поставляется “из коробки”. В стандартных репозиториях дистрибутивов его нет. Вам придется либо собирать конструктор на сайте Caddy и качать кастомный бинарник, либо компилировать сервер вручную.

Во-вторых, на момент написания статьи, модуль layer4 в Caddy имеет проблемы с корректным проксированием некоторых специфических TLS-рукопожатий, которые используют современные AI-сервисы.

Особенно критично это для GitHub Copilot и Microsoft Copilot. Из-за специфики обработки SNI и ECH, Caddy не всегда обеспечивает полную прозрачность туннеля. Сервис умудряется детектировать ваше реальное местоположение и выдает блокировку по геолокации, даже если трафик технически идет через прокси.

Возможно, есть способы заставить эту связку работать, но я не увидел в этом смысла. В Angie всё работает сразу из коробки, как автомат Калашникова. К тому же, с Caddy мы теряем его главное преимущество — простой и понятный Caddyfile, так как модуль layer4 настраивается через нативный caddy.json.

Установка Angie

Перейдем от слов к делу. Устанавливаем Angie на VPS. Лучше всего использовать официальные репозитории, чтобы получать свежие версии.
Подробная инструкция для всех дистрибутивов (Ubuntu, Debian, CentOS, Alpine и др.) есть в официальной документации ^[6].

Например, для Ubuntu/Debian:

1. Устанавливаем curl и ca-certificates.

2. Скачиваем ключ и подключаем репозиторий.

3. sudo apt-get update && sudo apt-get install angie.

Нам понадобится модуль stream (он включен в базовую поставку Angie).

Файл /etc/angie/angie.conf (или nginx.conf):

user angie;
worker_processes auto;

events {
    worker_connections 1024;
}

stream {
    # Настраиваем резолвер, чтобы Nginx мог найти реальные IP
    resolver 1.1.1.1 8.8.8.8 ipv6=off;

    # Магия SNI: читаем имя хоста из TLS Client Hello
    map $ssl_preread_server_name $backend_name {
        hostnames;

        # AI Services
        .aistudio.google.com $ssl_preread_server_name;
        .aistudiocdn.com $ssl_preread_server_name;
        .alkalimakersuite-pa.clients6.google.com $ssl_preread_server_name;
        .anthropic.com $ssl_preread_server_name;
        .api.github.com $ssl_preread_server_name;
        .bard.google.com $ssl_preread_server_name;
        .character.ai $ssl_preread_server_name;
        .chatgpt.com $ssl_preread_server_name;
        .claude.ai $ssl_preread_server_name;
        .clients6.google.com $ssl_preread_server_name;
        .cohere.ai $ssl_preread_server_name;
        .copilot-proxy.githubusercontent.com $ssl_preread_server_name;
        .copilot.microsoft.com $ssl_preread_server_name;
        # Не добавляйте login.live.com! Он доступен напрямую, а вход через дата-центр может вызвать подозрения у MS.
        .edgeservices.bing.com $ssl_preread_server_name;
        .files.oaiusercontent.com $ssl_preread_server_name;
        .gemini.google.com $ssl_preread_server_name;
        .generativelanguage.googleapis.com $ssl_preread_server_name;
        .github.com $ssl_preread_server_name;
        .githubcopilot.com $ssl_preread_server_name;
        .grok.com $ssl_preread_server_name;
        .huggingface.co $ssl_preread_server_name;
        .meta.ai $ssl_preread_server_name;
        .midjourney.com $ssl_preread_server_name;
        .mistral.ai $ssl_preread_server_name;
        .musicgpt.com $ssl_preread_server_name;
        .openai.com $ssl_preread_server_name;
        .perplexity.ai $ssl_preread_server_name;
        .pi.ai $ssl_preread_server_name;
        .poe.com $ssl_preread_server_name;
        .replicate.com $ssl_preread_server_name;
        .stability.ai $ssl_preread_server_name;
        .static.microsoft $ssl_preread_server_name;
        .sydney.bing.com $ssl_preread_server_name;
        .udio.com $ssl_preread_server_name;
        .x.ai $ssl_preread_server_name;
        .you.com $ssl_preread_server_name;

        # По умолчанию - никуда не пускаем (или можно сделать fallback)
        default                 deny_backend;
    }

    # Заглушка для неизвестных хостов
    upstream deny_backend { server 127.0.0.1:443; }

    # Слушаем 443 порт
    server {
        listen 443;
        listen [::]:443; # Поддержка IPv6

        # Включаем чтение SNI
        ssl_preread on;

        # Проксируем на основе карты (используем имя хоста как адрес назначения)
        proxy_pass $backend_name:443;
    }
}

Что здесь происходит?

1. Мы слушаем порт 443 (HTTPS).

2. ssl_preread on — Nginx заглядывает в первый пакет и вытаскивает имя домена в переменную $ssl_preread_server_name.

3. map проверяет, есть ли домен в нашем “белом списке”. Если есть — переменная $backend_name становится равна имени домена (например, api.openai.com).

4. proxy_pass $backend_name:443 резолвит этот домен (через resolver 1.1.1.1) и отправляет трафик на его реальный IP.

Сохраняем, перезагружаем: sudo angie -t && sudo systemctl reload angie.

Шаг 2: Настройка DNS (AdGuard Home vs Blocky)

Теперь нам нужно заставить наши домашние устройства думать, что api.openai.com находится не в Калифорнии, а на нашем VPS. Для этого нам нужен свой DNS-сервер.

Тут есть два пути:

Путь 1: AdGuard Home (Красиво и мышкой)
AdGuard Home — это мощный комбайн с веб-интерфейсом. Он умеет блокировать рекламу, показывать красивые графики и управлять клиентами.

• Плюсы: Веб-интерфейс, статистика, простота настройки для новичков.

• Минусы: Тяжеловат (жрет память ^[7]), требует отдельного порта для веб-морды. Нет 2FA: Выставлять панель управления в открытый интернет небезопасно, лучше прятать её за VPN или ограничивать доступ по IP.

Путь 2: Blocky (Быстро и конфигом)
Blocky — это легковесный DNS-прокси на Go.

• Плюсы: Супер-быстрый, потребляет копейки ресурсов, конфигурируется одним YAML-файлом. Идеален для слабых VPS или Raspberry Pi.

• Минусы: Нет веб-интерфейса (только метрики для Prometheus), настройка через текстовый файл.

Настройка AdGuard Home:

1. Ставим (можно в Docker):

   docker run -d --name adguardhome 
     --restart unless-stopped 
     -v /opt/adguardhome/work:/opt/adguardhome/work 
     -v /opt/adguardhome/conf:/opt/adguardhome/conf 
     -p 53:53/tcp -p 53:53/udp 
     -p 3000:3000/tcp 
     adguard/adguardhome
   

2. Заходим в веб-интерфейс (http://IP_ВАШЕГО_VPS:3000) -> Фильтры -> Перезапись DNS-запросов.

3. Добавляем записи (для каждого домена указываем IP_ВАШЕГО_VPS):

   • *.aistudio.google.com

   • *.aistudiocdn.com

   • *.alkalimakersuite-pa.clients6.google.com

   • *.anthropic.com

   • *.api.github.com

   • *.bard.google.com

   • *.cdn.openai.com

   • *.character.ai

   • *.chatgpt.com

   • *.claude.ai

   • *.clients6.google.com

   • *.cohere.ai

   • *.copilot-proxy.githubusercontent.com

   • *.copilot.microsoft.com

   • *.edgeservices.bing.com

   • *.files.oaiusercontent.com

   • *.gemini.google.com

   • *.generativelanguage.googleapis.com

   • *.github.com

   • *.githubcopilot.com

   • *.grok.com

   • *.huggingface.co

   • *.meta.ai

   • *.midjourney.com

   • *.mistral.ai

   • *.musicgpt.com

   • *.openai.com

   • *.perplexity.ai

   • *.pi.ai

   • *.poe.com

   • *.replicate.com

   • *.stability.ai

   • *.static.microsoft

   • *.sydney.bing.com

   • *.udio.com

   • *.x.ai

   • *.you.com

Настройка Blocky:
Создаем config.yml:

customDNS:
  mapping:
    aistudio.google.com: IP_ВАШЕГО_VPS
    aistudiocdn.com: IP_ВАШЕГО_VPS
    alkalimakersuite-pa.clients6.google.com: IP_ВАШЕГО_VPS
    anthropic.com: IP_ВАШЕГО_VPS
    api.github.com: IP_ВАШЕГО_VPS
    bard.google.com: IP_ВАШЕГО_VPS
    character.ai: IP_ВАШЕГО_VPS
    chatgpt.com: IP_ВАШЕГО_VPS
    claude.ai: IP_ВАШЕГО_VPS
    clients6.google.com: IP_ВАШЕГО_VPS
    cohere.ai: IP_ВАШЕГО_VPS
    copilot-proxy.githubusercontent.com: IP_ВАШЕГО_VPS
    copilot.microsoft.com: IP_ВАШЕГО_VPS
    edgeservices.bing.com: IP_ВАШЕГО_VPS
    gemini.google.com: IP_ВАШЕГО_VPS
    generativelanguage.googleapis.com: IP_ВАШЕГО_VPS
    github.com: IP_ВАШЕГО_VPS
    githubcopilot.com: IP_ВАШЕГО_VPS
    grok.com: IP_ВАШЕГО_VPS
    huggingface.co: IP_ВАШЕГО_VPS
    meta.ai: IP_ВАШЕГО_VPS
    midjourney.com: IP_ВАШЕГО_VPS
    mistral.ai: IP_ВАШЕГО_VPS
    musicgpt.com: IP_ВАШЕГО_VPS
    openai.com: IP_ВАШЕГО_VPS
    perplexity.ai: IP_ВАШЕГО_VPS
    pi.ai: IP_ВАШЕГО_VPS
    poe.com: IP_ВАШЕГО_VPS
    replicate.com: IP_ВАШЕГО_VPS
    stability.ai: IP_ВАШЕГО_VPS
    static.microsoft: IP_ВАШЕГО_VPS
    sydney.bing.com: IP_ВАШЕГО_VPS
    udio.com: IP_ВАШЕГО_VPS
    x.ai: IP_ВАШЕГО_VPS
    you.com: IP_ВАШЕГО_VPS

И запускаем:

docker run -d --name blocky 
  --restart unless-stopped 
  -v $(pwd)/config.yml:/app/config.yml 
  -p 53:53/tcp -p 53:53/udp 
  -p 4000:4000 
  spx01/blocky

Важно для Android (Private DNS):
Если вы планируете использовать функцию “Частный DNS” (Private DNS) на Android, вам обязательно нужен валидный SSL-сертификат для вашего домена (например, от Let’s Encrypt). Самоподписанные сертификаты Android не принимает — соединение просто не установится.
Для этого вам понадобится доменное имя и настройка DoT/DoH (DNS-over-TLS / DNS-over-HTTPS). Если вы используете Angie, сертификаты можно получать автоматически через встроенный ACME-клиент. С обычным Nginx придется повозиться с Certbot.

Лайфхак: Не обязательно покупать домен. Некоторые хостеры выдают бесплатные технические доменные имена (вида vm12345.хостер.com) при покупке VPS. Вам останется только подключить услугу DNS-хостинга (часто тоже бесплатную у того же провайдера), чтобы управлять записями и получать сертификаты.

---

Шаг 2.5: Безопасность (Не оставляйте дверь открытой)

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

1. Firewall:
Закройте всё, кроме нужного.

КРИТИЧЕСКИ ВАЖНО ПРО DNS (53 ПОРТ): Никогда не открывайте 53 порт (UDP) всему интернету! Ваш сервер мгновенно станет усилителем для DDoS-атак (DNS Amplification), и хостер заблокирует вас.

• Идеально: используйте DoT/DoH (порты 853/443), тогда 53 порт можно держать закрытым.

• Если нужен обычный DNS (для старых роутеров): разрешите доступ только с вашего IP-адреса.

Выберите ваш инструмент:

Вариант A: UFW (Ubuntu/Debian — самый простой)

apt install ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh       # 22 порт (или какой у вас)
ufw allow 80/tcp    # HTTP (для ACME)
ufw allow 443/tcp   # HTTPS (наш прокси + DoH)
ufw allow 853/tcp   # DNS-over-TLS
# ufw allow from ВАШ_IP to any port 53 proto udp # Только если нужен обычный DNS
ufw enable

Вариант B: Firewalld (CentOS/Fedora/RHEL)

systemctl start firewalld
systemctl enable firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-port=853/tcp
# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="ВАШ_IP" port port="53" protocol="udp" accept'
firewall-cmd --reload

Вариант C: Iptables (Old School / Универсальный)

# Сброс правил
iptables -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# Разрешаем установленные соединения и loopback
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Открываем порты
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 853 -j ACCEPT

# Сохраняем (для Debian/Ubuntu нужен iptables-persistent)
# apt install iptables-persistent
# netfilter-persistent save

Вариант D: nftables (Современная замена iptables)

# /etc/nftables.conf
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Разрешаем установленные соединения и loopback
        ct state established,related accept
        iif "lo" accept

        # Открываем порты
        tcp dport 22 accept
        tcp dport 80 accept
        tcp dport 443 accept
        tcp dport 853 accept

        # ICMP (ping)
        ip protocol icmp accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Применить: nft -f /etc/nftables.conf

2. Fail2Ban: Защита от подбора паролей SSH.

apt install fail2ban
systemctl enable fail2ban

3. Отключите вход по паролю: Используйте только SSH-ключи. В /etc/ssh/sshd_config поставьте PasswordAuthentication no.

Шаг 3: Настройка клиентов (Чтобы работало везде)

Сервер настроен и защищен. Теперь нужно объяснить вашим гаджетам, что использовать нужно именно ваш DNS, а не провайдерский.

1. Роутер (Уровень “Бог”)

Самый удобный способ — настроить DNS на роутере. Мы будем использовать шифрованные протоколы (DoT/DoH), так как 53 порт у нас закрыт (см. шаг 2.5).

Инструкции от производителей:

• Keenetic: Настройка DNS-over-TLS и DNS-over-HTTPS ^[8]

• Mikrotik: DNS over HTTPS ^[9]

• OpenWRT: DNS over HTTPS with Dnsmasq ^[10]

• Asus (Merlin): DNS Privacy ^[11]

Если ваш роутер не умеет DoT/DoH (обычные TP-Link, D-Link), настраивайте DNS на самих устройствах.

2. Windows и Браузеры

В Windows 11 поддержка DoH встроена:

1. Параметры -> Сеть и Интернет -> Ethernet (или Wi-Fi).

2. Назначение DNS-сервера -> Изменить.

3. Включаем “DNS поверх HTTPS”.

В Windows 10 или 7 проще всего настроить Secure DNS прямо в браузере (Chrome/Edge/Firefox):

1. Настройки -> Конфиденциальность и безопасность -> Безопасность.

2. “Использовать безопасный DNS-сервер” -> Выбрать “Свой” -> Ввести URL вашего DoH (https://ваш-домен.com/dns-query).

3. Android (Private DNS)

Android поддерживает DoT нативно (функция “Частный DNS”):

1. Настройки -> Сеть и Интернет -> Частный DNS-сервер.

2. Выбираем “Имя хоста провайдера частного DNS”.

3. Вписываем ваш домен (например, dns.yourdomain.com).

• Обратите внимание: Android понимает только доменные имена, IP-адрес тут не сработает.

4. iOS (iPhone/iPad)

iOS требует установки профиля конфигурации (.mobileconfig) для DoT/DoH. Его можно сгенерировать вручную или скачать из интерфейса AdGuard Home (Настройки -> Настройки шифрования).

Если генерируем вручную:
Создайте файл dns.mobileconfig со следующим содержимым (замените ВАШ_ДОМЕН и IP_ВАШЕГО_VPS):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>DNSSettings</key>
            <dict>
                <key>DNSProtocol</key>
                <string>HTTPS</string>
                <key>ServerURL</key>
                <string>https://ВАШ_ДОМЕН/dns-query</string>
                <key>ServerAddresses</key>
                <array>
                    <string>IP_ВАШЕГО_VPS</string>
                </array>
            </dict>
            <key>PayloadDescription</key>
            <string>Configures device to use Custom DoH</string>
            <key>PayloadDisplayName</key>
            <string>My Custom DNS</string>
            <key>PayloadIdentifier</key>
            <string>com.example.dns.profile</string>
            <key>PayloadType</key>
            <string>com.apple.dnsSettings.managed</string>
            <key>PayloadUUID</key>
            <string>e506563b-225f-4438-904d-1234567890ab</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>My Custom DNS Profile</string>
    <key>PayloadIdentifier</key>
    <string>com.example.dns.profile.root</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>16267442-3232-4321-8765-1234567890ab</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

Отправьте этот файл себе через AirDrop или iCloud Drive и откройте на устройстве.

Шаг 4: Проверка

Самый простой способ проверить, что всё работает:

1. В браузере: Откройте chatgpt.com (или другой настроенный ресурс).

   • Сайт должен открыться. Если вы видите окно логина или чата вместо заглушки “Access Denied” — всё работает.

2. В AdGuard Home:

   • Зайдите в “Журнал запросов” (Query Log).

   • Вы должны увидеть запросы к chatgpt.com от вашего IP-адреса.

   • Если вы настроили DoT/DoH, рядом с запросом будет значок замочка (Encrypted).

Примечание: Команда nslookup или dig с компьютера может не сработать, если вы закрыли 53 порт на сервере. Это нормально. Браузеры и настроенные роутеры будут использовать защищенный канал (DoT/DoH).

Вы великолепны! Вы только что восстановили доступ к инструменту, который необходим вам для работы, преодолев несправедливые географические ограничения.

---

Бонус: Моя автоматизация

Описанный выше процесс работает, но требует ручного редактирования конфигов каждый раз, когда нужно добавить новый домен или обновить сертификат. После нескольких итераций я написал для себя утилиту на Python, которая объединяет Angie (или Nginx) и AdGuard Home (или Blocky) в единую связку.

Что умеет:

• Добавлять/удалять домены для SNI-проксирования одной командой (CLI) или через веб-интерфейс

• Автоматически обновлять конфиги веб-сервера и DNS-перезаписи

• Получать сертификаты Let’s Encrypt (через ACME-клиент Angie или Certbot для Nginx)

• Публиковать локальные сервисы наружу (reverse proxy)

• Готовые Docker-образы для быстрого развёртывания

Исходный код открыт и доступен на GitHub: github.com/crim50n/flowgate ^[12]. Можете использовать как есть, форкнуть или просто подсмотреть идеи для своей реализации.

---

Итог

Мы живем в интересное время, когда доступ к информации требует инженерных навыков. Можно платить операторам за “специальные тарифы”, можно доверять бесплатным DNS-сервисам, а можно потратить вечер, арендовать VPS за чашку кофе и поднять свою собственную, независимую систему доступа.

Надеюсь, эта статья и предложенные инструменты сэкономят вам пару часов жизни и нервных клеток, позволив сосредоточиться на действительно важных задачах.

В конце концов, свобода — это просто правильно настроенная маршрутизация.