Частный IP Cloud SQL через VPN: маршрут, который никто не экспортирует

Многие команды считают, что частный IP Cloud SQL работает только изнутри VPC, и это убеждение держится, потому что отказ выглядит как проблема базы данных. Google документирует доступ из сетей, подключённых через Cloud VPN или Cloud Interconnect. Этим сетям нужен не особый функционал базы данных, а два обмена маршрутами, которые легко оставить настроенными наполовину. Туннель поднимается, вычислительные инстансы отвечают, а соединение с базой уходит в таймаут — именно та комбинация, которая отправляет людей в неправильную консоль.

Миф: частный IP означает частный по отношению к VPC

Доступ к частным сервисам — это VPC peering между вашей сетью и сетью производителя, принадлежащей Google. Выделенный для сервиса диапазон живёт на стороне производителя, и адрес инстанса находится внутри него. Именно из-за этого peering база данных в вашем проекте может находиться на адресе, в который маршрутизирует ваша VPC, хотя ни одна ваша явная подсеть его не содержит.

Поскольку это peering, у него есть и поведение peering, включая ту часть, где пользовательские маршруты не переходят автоматически.

Миф: работающий туннель несёт маршрут базы данных с собой

Два диапазона должны пережить путешествие. Первый — клиентский префикс: ваша локальная сеть должна быть известна Cloud Router с конкретными префиксами, потому что маршрут по умолчанию не может дать импорт, который нужен сети производителя для обратного пути. Второй — выделенный диапазон сервиса, который внешняя сторона должна выучить, чтобы её пакеты к базе данных имели куда идти. Это разные маршруты, которые поддерживаются на разных границах, и исправление одного оставляет другой сломанным.

На стороне Google это означает включить Export custom routes на соответствующих peering-соединениях и добавить выделенный диапазон сервиса в анонсируемые маршруты Cloud Router для туннеля.

Сохраняйте объявления, которые уже есть. Добавление диапазона сервиса не должно удалять маршруты VPC, которые тот же сеанс BGP несёт для другого трафика, а набор объявлений, заменённый целиком, — это второй сбой, спрятанный за первым. Проверьте также действующие маршруты на внешнем устройстве, потому что доступность VPN-шлюза или другой подсети доказывает только транспорт.

Миф: Cloud SQL Auth Proxy решает проблему сети

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

Чего он не делает — не позволяет отключённому ноутбуку добраться до инстанса, доступного только приватно.

Миф: Private Service Connect подчиняется тем же правилам

Private Service Connect использует endpoint в вашей собственной подсети и схему DNS, которую контролируете вы, поэтому маршрут к нему — обычный маршрут к адресу, которым вы владеете. Настройки экспорта peering к этому проекту не относятся, а копирование изменений peering в развёртывание PSC добавляет риск, не добавляя доступности.

Оба дают вам частный адрес; сходство на этом заканчивается.

Проверяйте путь в правильном порядке

С внешнего клиента сначала проверьте TCP-эндпоинт базы данных. Завершённое TCP-рукопожатие означает, что маршрутизация, межсетевой экран и слушатель на месте, а следующий тест — разрешённая аутентифицированная операция. Отказ аутентификации в этот момент на самом деле хорошая новость, потому что доказывает, что слушатель базы ответил. Таймаут ICMP почти ничего не говорит о доступе к базе, потому что многие пути его отбрасывают, спокойно передавая TCP.

Если ваши клиентские диапазоны вне RFC 1918, пересмотрите дополнительные требования к экспорту маршрутов и авторизации сети, прежде чем заключить, что проект не поддерживается.

Запишите четыре объекта вместе с соединением: внешний префикс, выделенный диапазон сервиса, задействованные peering-соединения и маршрутизатор, который анонсирует. Эти четыре объясняют весь частный путь и заменяют легенду о том, что Cloud SQL либо всегда требует прокси, либо вообще недостижим через VPN.