Ноутбук на macOS, WireGuard поднят на весь трафик, а рабочие сайты идут мимо туннеля по точечным host-маршрутам. Эту схему я собрал 4-5 октября, чтобы при включённом VPN открывались amoCRM, TGBooster и Geekjob. За следующую неделю через неё всё равно отвалились восемь сервисов. Снаружи все случаи выглядели одинаково, сайт не открывается или висит, а причин оказалось три.

Я маркетолог, а не сетевой инженер. VPN держу ради нейросетей, а в рекламных кабинетах и CRM сижу весь день. Ниже журнал этой недели, команды, которыми я разбирался, и скрипт проверки, который получился в конце.

Зачем вообще понадобились исключения

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

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

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

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

Как устроена схема

WireGuard забирает default route на интерфейс utun. Для каждого рабочего адреса я добавляю host-маршрут через домашний шлюз и явно указываю локальный адрес ноутбука в этой сети:

sudo /sbin/route -n add -host 111.88.225.134 192.168.100.1 -ifa 192.168.100.83

Сначала пробовал сделать исключения через AllowedIPs. Префиксы появлялись в таблице, но адреса всё равно уходили в оставшийся VPN default route. Явный host-маршрут сработал.

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

route -n get 111.88.225.134      # gateway 192.168.100.1, interface en0
route -n get 1.1.1.1             # interface utun
curl -q --proxy '' --ipv4 -s -o /dev/null --connect-timeout 5 \
  -w 'http=%{http_code} ip=%{remote_ip} connect=%{time_connect}\n' \
  https://app.tgbooster.ru/

Если сайт не открывается, тот же curl повторяю с --interface en0. Разница между двумя ответами сразу показывает, виноват путь или сам сайт.

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

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

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

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

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

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

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

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

Лечится новым host-маршрутом. Ловушка в том, что проверять надо все домены страницы. С ProxyAPI главная была зелёной, а ломался домен, куда страница ходит за данными. Странице входа amoCRM нужен statix.amocrm.ru, которого в моём первом списке не было. Список доменов удобно брать из вкладки Network в DevTools.

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

11 октября все маршруты amoCRM были на месте, шлюз правильный, интерфейс правильный. А соединение падало мгновенно:

connect: Can't assign requested address

Маршруты были созданы с -ifa 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 октября три разных резолвера отвечали 111.88.225.134, и новый адрес шёл в туннель, где соединение висело 5 секунд. Старый маршрут при этом остался и указывал в пустоту.

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

У сервиса NS в Яндекс Облаке, CDN на yccdn.ru. Для облачных сервисов смена IP обычное дело, так что маршрут к фиксированному адресу живёт до следующего переезда. А 8 октября в Yandex Cloud больше суток лежала зона ru-central1-b, и в тот день VPN мог быть вообще ни при чём. Прежде чем трогать маршруты, стоит проверить, открывается ли сервис у кого-то ещё.

Скрипт, который ловит все три случая

В итоге я свёл проверку в один скрипт. Он берёт список доменов, резолвит каждый и для каждого IP смотрит, куда идёт маршрут и к какому локальному адресу он привязан.

#!/bin/bash
# check-bypass.sh: проверка исключений из VPN на macOS
# hosts.txt: по одному домену на строку
GW=192.168.100.1                   # шлюз домашней сети
IF=en0                             # физический интерфейс
ME=$(ipconfig getifaddr "$IF")     # текущий адрес ноутбука

while read -r host; do
  [ -z "$host" ] && continue
  for ip in $(dig +short A "$host" | grep -E '^[0-9.]+$'); do
    r=$(route -n -v get "$ip" 2>/dev/null)
    gw=$(awk '/gateway:/{print $2}' <<<"$r")
    ifc=$(awk '/interface:/{print $2}' <<<"$r")
    if [ "$gw" != "$GW" ] || [ "$ifc" != "$IF" ]; then
      echo "$host $ip: идёт через $ifc, исключения нет (новый IP?)"
    elif ! grep -qF "$ME" <<<"$r"; then
      echo "$host $ip: маршрут привязан к старому адресу, нужен route change -ifa $ME"
    else
      code=$(curl -q --proxy '' -s -o /dev/null --connect-timeout 5 \
        -w '%{http_code}' "https://$host/")
      echo "$host $ip: маршрут в порядке, HTTP $code"
    fi
  done
done < hosts.txt

Первая ветка ловит переезд сервиса, вторая ловит сменившийся адрес в Wi-Fi. Если обе прошли, а HTTP-код 000, значит, маршрут правильный и проблема в самом сайте или в сети за роутером. Поправить маршрут скрипт не пытается, sudo я по-прежнему запускаю руками.

Что я решил и чего больше не делаю

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

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

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

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

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

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

5. Проверить, не лежит ли сервис у всех.

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

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

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

Как вы решаете смену IP у облачных сервисов в split-tunnel без ручного обновления списка? Маршрутизация по доменам на роутере, PAC, что-то ещё?