Я держу VPN ради нейросетей, и за неделю у меня отвалились восемь рабочих сервисов

Я 19 лет в маркетинге и большую часть дня сижу в рекламных кабинетах, CRM и нейросетях одновременно. Нейросетям нужен VPN, а российские рабочие сервисы всё чаще с ним не дружат. Ниже мой журнал за 6-12 октября и решения, к которым мы пришли.

Почему VPN и рабочие сервисы теперь мешают друг другу

Claude у меня месяц писал, что недоступен в моём регионе, а 1 октября аккаунт заблокировали. 7 сентября ChatGPT массово перестал открываться в России, и заговорили о блокировке. Без VPN с ИИ сейчас почти не поработать.

С другой стороны, с 15 апреля Минцифры попросило крупные российские сервисы ограничить доступ с VPN. Яндекс начал показывать «зайти не получится из-за действующих ограничений», следом ограничения ввели Ozon, Wildberries, Авито и банки. В июне, по данным отрасли, ТСПУ стали рвать TLS-соединения к российским облакам, и у Selectel, Beget и Timeweb пошла «плавающая» недоступность сайтов. В конце августа хостингам и CDN велели выносить сайты из «белого списка» в отдельные подсети. А с конца августа и особенно с 7 сентября у пользователей волнами падали сами VPN.

С одной стороны нейросети требуют VPN, с другой рабочие сервисы его всё хуже переносят

Коллега, с которым мы это обсуждали, сформулировал проще всех:

Да, поэтому надо отдельно прописывать куда без впн ходить

Я так и сделал ещё 4-5 октября, когда настраивал WireGuard и точечные маршруты для amoCRM, TGBooster и Geekjob. Через неделю выяснилось, что этого мало.

Что ломалось с 6 по 12 октября

6 октября через VPN перестала открываться Cossa. Обычный запрос ждал 5 секунд и падал по тайм-ауту, напрямую через физический интерфейс страница отдавала HTTP 200. 8 октября то же самое случилось с Telemetr и ppc.world.

8 октября же долго грузился Хабр. Сама статья через VPN открывалась нормально, а один сторонний скрипт в HTML через туннель не подключался. Он стоял без async, поэтому держал загрузку всей страницы.

9 октября не открылась ссылка на скриншот в Skrinshoter. 10 октября завис кабинет ProxyAPI, сервиса, через который я хожу к моделям по API. Оболочка кабинета грузилась, а его отдельный API на console-api.proxyapi.ru через VPN не отвечал. Выглядело это как «кабинет висит», хотя сам сайт работал.

Снаружи всё выглядело одинаково: сайт не открывается или висит

11 октября amoCRM открыл список сделок голым HTML без оформления, а ссылка на сделку не открывалась вовсе. Telemetr снова отвалился. И 12 октября TGBooster.

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

Первая причина: путь через VPN просто не работает

Cossa, Telemetr, ppc.world, Skrinshoter, API ProxyAPI и скрипт на Хабре. Через туннель TCP-соединение не устанавливается, напрямую тот же адрес отвечает за доли секунды. Кто именно режет, VPN-сервер, промежуточная сеть или защита сайта, я не знаю, и «сайт блокирует VPN» не пишу. Доказана только разница между двумя путями.

Решение здесь одно: прямой маршрут к конкретному IPv4 через домашний шлюз, VPN для остального остаётся. Перед этим каждый раз парный запрос, через туннель и через en0, иначе можно чинить не то.

Отдельно запомнил историю с ProxyAPI. Если проверять только главную страницу, всё зелёное. Ломался другой домен, к которому страница ходит за данными. С amoCRM в первый раз было так же: странице входа нужен statix.amocrm.ru, которого не было в моём списке.

Вторая причина: у ноутбука сменился адрес в Wi-Fi

11 октября все маршруты amoCRM были на месте, шлюз правильный, интерфейс правильный. А соединение падало мгновенно с ошибкой Can’t assign requested address. Оказалось, маршруты были привязаны к старому локальному адресу ноутбука 192.168.100.77, а роутер уже выдал 192.168.100.83. Когда и почему сменился адрес, по снимкам не видно, это могли быть сон, пробуждение или DHCP.

Из семи маршрутов amoCRM сначала починили два, для самого аккаунта. Сделка открылась, но без стилей: сервер CSS и JS сидел на третьем маршруте с той же старой привязкой. Исправили оставшиеся пять одной командой:

sudo /bin/sh -c ‘for ip in 23.111.117.181 23.111.99.17 188.124.43.169 88.212.249.21 23.111.41.206; do /sbin/route -n change -host “$ip” 192.168.100.1 -ifa 192.168.100.83 || exit 1; done’

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

Третья причина: сервис переехал

TGBooster 5 октября жил на 84.201.187.142. 12 октября три разных DNS отвечали 111.88.225.134, и новый адрес снова шёл в туннель, где соединение висело 5 секунд. Старый маршрут при этом никуда не делся и указывал в пустоту.

Фиксированный маршрут к IP живёт до следующего переезда сервиса

Сервис сидит на DNS Яндекс Облака, а его CDN на yccdn.ru. Для облачных сервисов смена IP обычное дело, так что фиксированный маршрут к адресу живёт ровно до следующего переезда. Новый адрес я добавил вручную и пока не стал вписывать его в общий скрипт восстановления, чтобы скрипт не превратился в свалку устаревших IP.

И отдельно про 8 октября. В тот день после атаки на дата-центр Яндекса в Сасово зона ru-central1-b в Yandex Cloud лежала больше суток, и по рунету шёл массовый сбой. Если у вас что-то не открывалось в тот день, VPN мог быть вообще ни при чём. Я бы сначала проверил, работает ли сервис у кого-то ещё.

Что мы решили и чего больше не делаем

Самодельный kill switch на правилах PF после истории 5 октября больше не включаем. Он один раз уже положил мне интернет целиком. Маршруты добавляю по одному, через -ifa с текущим адресом, и после каждого проверяю обычный запрос без принудительной привязки к интерфейсу. Скрипт восстановления надо научить проверять локальный адрес маршрута, без этого он бесполезен.

Порядок, если рабочий сайт не открывается при включённом VPN:

1. Сделать два одинаковых запроса: через туннель и через физический интерфейс. Если напрямую работает, проблема в пути.

2. Проверить, какой IP сейчас отдаёт DNS, и сравнить с адресом в вашем исключении.

3. Посмотреть route -n -v get для этого адреса: не только шлюз и интерфейс, но и локальный адрес в последней строке.

4. Открыть страницу и выписать все домены, откуда она грузит скрипты, стили и данные.

5. Прежде чем винить VPN, проверить, не лежит ли сам сервис у всех.

Когда это не работает

Точечные маршруты не переживают перезагрузку и смену сети без отдельного скрипта. Сервисы в облаках меняют IP без предупреждения, и список придётся обновлять. На телефоне так вообще не сделать, там проще держать отдельный профиль без VPN для рабочих приложений. А если сервис закрывает доступ с VPN по требованию регулятора, маршрут спасает только пока ваш домашний IP российский или белорусский и сервис его пускает.

За неделю я потратил на это больше времени, чем на рекламу некоторых клиентов. Симптом всегда один, «не открывается», а причин три, и каждая лечится своим способом. Я бы не стал строить вокруг этого сложную автоматику, проще иметь короткий порядок проверки и вести журнал.

Работаю как внешний руководитель маркетинга, и рабочие кабинеты для меня инструмент каждый день. Про такие разборы пишу в Telegram-канале t.me/sosnovsky_a.

А у вас какие рабочие сервисы перестали открываться с VPN и как вы это решили?