Сервис открывается, отвечает, всё работает — но цены в другой валюте, половина функций спрятана, а платёжный шаг падает с невнятной ошибкой. Через час выясняется, что выдача зависит от того, из какого региона пришёл запрос, а вы ходите из «неправильного». Знакомо всем, кто проверял локализацию продукта или подключался к региональному B2B‑порталу из другой страны.
Дальше обычно появляется VPN до нужного региона, и на этом задача считается решённой. На практике решённой она не считается — просто проблема переезжает в то место, где её не видно. Прежде чем чинить, стоит выписать, что вообще должно работать:
Выход настроен в одном месте, а не на каждом устройстве и сервере по отдельности.
На выбор маршрута не влияет память и внимательность человека.
Когда что‑то ломается, это видно сразу, а не всплывает потом.
Добавить регион или сменить провайдера можно, не обходя все хосты.
Правило по возможности цепляется к домену, а не к адресу: адрес за CDN живёт своей жизнью. «По возможности» — потому что имя в трафике есть не всегда, и там, где его нет, деваться некуда, кроме адреса.
Почему привычные способы это не закрывают
Начнём с того, как выход настраивают по факту. На клиентах — VPN с тумблером, который переключают руками. На серверах интереснее: на одном HTTP_PROXY прописан в окружении, на другом прокси зашит прямо в код, на третьем стоит статический ip route через конкретный шлюз, а рядом живёт прокси‑контейнер, поднятый когда‑то под одну интеграцию. Каждый кусок настраивали в своё время свои руки, и через год никто не помнит, какой сервис каким путём выходит наружу. Это сразу первые два пункта мимо: картины нет, а половина маршрутов держится на том, что кто‑то не забыл.
Хочется навести порядок и сматчить трафик с правилом централизованно — и тут выясняется, что даже руками это делается двумя разными способами, и у обоих свой потолок.
Можно матчить по адресу. Отдельная таблица маршрутизации и ip rule, который заворачивает нужные подсети назначения на выходной шлюз, а тот делает SNAT в своём регионе:
ip rule add to 198.51.100.0/24 lookup 100
ip route add default via <выходной-шлюз> table 100
Голое ядро, без всякого софта, и работает надёжно — пока цель это стабильный диапазон адресов: свой сервер, фиксированный пул партнёра. Для домена с плавающими адресами список CIDR придётся вести руками, и он устареет быстрее, чем вы его поправите.
Можно матчить по имени — тогда в дело идёт Squid с ACL по dstdomain и cache_peer на выходной узел. Доменная гранулярность появляется, но об неё же всё и спотыкается, как только цель уезжает за CDN. Squid защищается от подмены Host: запрошенное имя он резолвит сам и сверяет результат с адресом, на который реально идёт соединение. За CDN клиент и Squid спрашивают DNS в разные моменты и получают разные адреса из общего пула — проверка не сходится, и Squid рвёт соединение, посчитав это попыткой подмены. Домен при этом живой, сервис доступен, а через прокси не проходит ничего.
Корень в том, что адрес за CDN раздаётся из пула, который меняется и делится между тысячами чужих доменов; обратный резолв такого адреса не возвращает ничего осмысленного, а связка «домен → адрес → маршрут» течёт на каждом обновлении DNS. Для пары доменов на собственном хостинге сойдёт, как общее решение — рассыпается. Цепляться надо за имя, причём там, где оно ещё известно, а не вычислять его обратно по адресу.
Ни один из этих способов сам по себе не плох — это рабочие кирпичи, и если хочется покопаться, на них вполне можно собрать своё. Но мониторинга, единой политики и внятного поведения при сбое в них нет; всё это пишется сверху руками. А без поведения при сбое всплывает третий пункт, и он неприятнее остальных: когда тумблер на клиенте отвалился или прокси стал недоступен, трафик молча уходит напрямую, с реального адреса. Тест локализации показывает свою выдачу, и вы принимаете её за чужую, потому что ошибки‑то не было.
Как это решить
Все пять пунктов сходятся в одну точку: выбор региона — это решение «куда отправить трафик», то есть маршрутизация, и принимать его должна маршрутизация в одном месте, а не сто клиентов и серверов вразнобой.
Достаточно двух ролей. Точка входа — шлюз, через который трафик и так уже идёт: сотрудники через корпоративный VPN, серверы, гостевой Wi‑Fi. Выходные узлы — по лёгкой виртуалке в каждом нужном регионе. Между ними политика, которая и говорит, что куда:
правило "portal-eu":
назначения: *.portal.example, *.billing.example
выход через: узел в регионе EU
Это правило лежит на шлюзе и применяется ко всем сразу. Трафик к указанным доменам уходит через нужный регион независимо от того, кто его начал — сотрудник с ноутбука или бэкенд со своим исходящим вызовом. Включать на устройстве нечего, забыть нечего, зайти «не оттуда» нельзя. Резолв при этом происходит на самой точке входа, пока имя ещё на руках, — поэтому матчинг по домену не разваливается об CDN так, как разваливается у Squid с маршрутизацией постфактум.
Имя берётся из самого трафика: у обычного HTTP это заголовок Host, у HTTPS — SNI в начале TLS‑рукопожатия, ещё до шифрования. В большинстве случаев этого достаточно. Но не всегда: соединение прямо по IP без SNI, ECH, который имя как раз прячет, протокол без имени вовсе — тогда в пакете цепляться не за что, и остаётся адрес. Здесь выручает то, что часть крупных сервисов сами публикуют свои диапазоны: облака и большие CDN выкладывают списки IP, которые остаётся подтянуть в правило по адресу и обновлять по расписанию. Не у всех такое есть и не панацея, но для трафика без имени — рабочая подпорка.
Дешёвые изменения получаются сами собой: новый регион — это виртуалка и строчка в политике, а не обход всех хостов; смена провайдера выходного узла видна только этому узлу. Локальное при этом через регион не гоняется — RFC 1918, CGNAT и .local/.lan идут напрямую, иначе ssh на соседнюю машину поехал бы кругосветку.
Отдельно стоит отказ, потому что в централизованной схеме его можно сделать громким. Выходной узел недоступен — соединение рвётся видимой ошибкой, а не утекает напрямую; а если по умолчанию стоит «не выпускать», то либо трафик идёт через нужный регион, либо не идёт вообще. При этом единой точки отказа для самого трафика нет: выходные узлы держат последнюю версию политики у себя и продолжают работать, даже если управляющий узел лёг, — теряется возможность менять маршруты, а не пропускать их.
Сносить существующее ради этого не нужно. OpenVPN с Pritunl (или WireGuard‑mesh, или просто корпоративный шлюз) остаётся на месте и занимается своим — аутентификацией, OTP, аудитом; выбор региона встаёт рядом отдельным слоем. Канал между узлами разумно держать на обычном 443, чтобы не плодить экзотических портов, которые потом объяснять в firewall‑политике.
Собрать это можно и руками — из тех самых кирпичей с ip rule и Squid, если регионов немного и менять их приходится редко. Когда регионов больше и хочется единой политики с громким отказом, обвязка вокруг них дорастает до отдельного проекта, и в какой‑то момент проще взять готовое. Я свой вариант собрал в ololo‑relay — там ровно эта схема: узел совмещает точку входа и выход, а регион задаётся политикой.