WordPress и WoW-сервер через WireGuard без открытия базы наружу

Когда «сделать регистрацию на сайте» внезапно упирается в сеть

На словах задача выглядела мирно: есть сайт на WordPress, есть WoW-сервер, нужно связать их так, чтобы пользователь мог зарегистрироваться на портале, а дальше получить нормальную точку входа в игровой проект. Без ручной возни, без плясок с SQL по ночам, без схемы «сначала напиши в Telegram, потом мы что-нибудь заведём руками».

Проблема началась в том месте, где обычно и начинается настоящая работа: сайт и игровой сервер живут не в одной коробке. WordPress крутится на продакшн-хосте с DirectAdmin, где кроме ARK висят и другие сайты. WoW-сервер стоит отдельно. Просто открыть MySQL наружу — плохая идея. Тащить весь трафик через VPN — ещё хуже. На рабочем сервере такие эксперименты обычно заканчиваются не инженерией, а некрасивым вечером.

Во что упёрлись

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

Вторая проблема — доступ к базе. WordPress должен был видеть данные игрового сервера, но не через публичный адрес, не через белый IP MySQL и не через «авось firewall спасёт». Такая схема удобна только до первого лишнего правила, первой ошибки в bind-address или первого забывчивого админа через месяц.

Как проверяли и почему выбрали именно эту схему

Решение оказалось довольно прямым: не городить «большой VPN для сервера», а поднять узкий site-to-site WireGuard-туннель только для связки ARK ↔ WoW. Без перетаскивания default route, без ломки сетевой логики DirectAdmin, без желания превратить продакшн в лабораторию.

На одной стороне туннеля сервер ARK получил адрес 10.30.40.1/24, на второй стороне WoW — 10.30.40.2/24. Этого хватило, чтобы дать WordPress безопасный маршрут до нужной базы и больше ничего лишнего не трогать.

Отдельно проверяли самую неприятную вещь: не начнёт ли новый интерфейс мешать сайтам. Не начал. И это как раз следствие нормальной архитектуры. WireGuard здесь работает как отдельный служебный коридор для одной задачи, а не как попытка переучить весь сервер жить по-новому.

Что меняли по факту

Дальше уже пошла нормальная инженерная рутина. На WoW-сервере доступ к MySQL настроили так, чтобы база принимала соединения не «откуда угодно», а только там, где они действительно нужны. Для WordPress был создан отдельный пользователь уровня связки, а не универсальный логин с лишними правами. В grant это выглядело не как безразмерный root-подход, а как аккуратный доступ для конкретного узла внутри туннеля — по адресу 10.30.40.1.

Параллельно WordPress получил свою прикладную часть. На сайте появилась логика регистрации и привязки аккаунтов, а в базе портала — таблица сопоставления между пользователем WordPress и игровым аккаунтом. Не абстрактный «кабинет когда-нибудь потом», а вполне прикладная схема, где портал уже понимает, кто перед ним, какой игровой логин связан с профилем и откуда эта связка появилась.

Снаружи всё выглядит скромно: страница регистрации, личный кабинет, раздел World of Warcraft. Внутри уже нормальная инженерия: REST-маршрут, отдельная таблица, обмен данными по туннелю, понятная логика записи и чтения без прямой публикации чувствительных сервисов в интернет.

Что получили в итоге

Получили самую полезную вещь в таких проектах — рабочую связку без лишнего героизма. WordPress не лезет в игровую базу по белому адресу. WoW-сервер не выставляет наружу то, что не обязан выставлять. Основной хостинг под DirectAdmin продолжает жить своей жизнью. Остальные сайты не замечают, что рядом появился ещё один инфраструктурный канал.

И вот тут начинается разница между «что-то собрали» и «сделали нормально». Нормальная схема не держится на одном случайном правиле в firewall. Она читается. Её можно проверить. Её можно перенести. Через месяц в ней не приходится вспоминать, почему база внезапно открыта на весь мир и кто вообще решил, что так можно.

Что осталось за кадром, но никуда не делось

Такая связка не отменяет осторожность. Если уж WordPress становится точкой входа в игровой проект, за ним нужно следить как за реальным продакшн-узлом: бэкапы, журналирование, контроль прав, проверка REST-логики, защита от мусорных запросов, мониторинг самого туннеля. WireGuard даёт удобный и быстрый транспорт, но не делает архитектуру умнее автоматически.

Есть и второе ограничение. Когда портал начинает общаться с игровым сервером напрямую, соблазн быстро нарастить функциональность очень большой: кабинет, статусы, привязки, восстановление, телеграм-бот, игровые сервисы. Если не держать границы, аккуратная интеграция быстро превращается в толстый комок логики, который уже неприятно трогать. Поэтому правильный путь здесь один: каждая новая функция проходит через тот же фильтр, через который прошёл туннель. Зачем нужна, что именно открывает, какие права требует и что будет, если одна из сторон недоступна.

Почему такая схема вообще стоит усилий

Потому что она взрослая. Не «лишь бы работало», а «работает и не стыдно оставить на проде». Для маленьких проектов это особенно важно. Когда людей мало, времени мало, а сервер один и на нём всё сразу, дисциплина в архитектуре окупается быстрее любого красивого редизайна.

В итоге задача про регистрацию оказалась не про форму на сайте и не про кнопку в кабинете. Она оказалась про границы между сервисами. Про аккуратный доступ. Про нормальную сеть. Про привычку сначала не ломать, а потом уже улучшать. И вот с такой привычкой проект обычно и начинает походить на настоящий.