Cloud SQL Auth Proxy или прямой VPN-маршрут к базе данных
Auth Proxy и прямой VPN-маршрут решают разные половины одной и той же задачи. Сначала сравните авторизацию коннектора, порты и вход в базу данных.
Есть два разумных способа добраться до приватного экземпляра Cloud SQL с ноутбука в VPN. Первый — прямое подключение к приватному адресу экземпляра по уже имеющемуся маршруту. Второй — Cloud SQL Auth Proxy, который слушает на loopback и сам открывает соединение с Cloud SQL. Это не столько конкурирующие продукты, сколько два разных ответа на вопрос, у кого учётные данные, а у кого маршрут. Неверный выбор обычно проявляется как ошибка авторизации, которая читается как ошибка сети.
Вот сравнение, которое я поставил бы перед командой, а следом проверки, которые действительно всё решают.
Два пути к одному экземпляру
Прямой путь использует маршрут private-services-access из вашей сети в VPC проекта. Ваш клиент говорит с приватным адресом экземпляра по PostgreSQL, и соединение живёт или умирает на маршрутизации, правилах firewall и учётных данных базы.
Путь через прокси использует тот же маршрут, но добавляет локальный процесс. Прокси аутентифицируется в Google API с помощью default credentials приложения, открывает соединение с экземпляром через коннектор и предоставляет loopback-порт, который ваш клиент воспринимает как PostgreSQL. Два прыжка становятся тремя, и средний несёт авторизацию IAM. Маршрут VPN по-прежнему ваш в обслуживании, и прокси никогда не считает его заменой этой проверки.
Что на самом деле авторизует каждый путь
Самое важное различие — что каждый вариант может авторизовать за вас:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Проверка IAM в прокси и вход в базу данных — это два отдельных шлюза, и проход через один не открывает другой. Команда, которая включит прокси и решит, что учётная запись приложения больше не нужна, проведёт полдня за ошибками паролей, не имеющими никакого отношения к сети.
Порты и маршруты рядом
Прокси нужен исходящий TCP 443 для API и TCP 3307 для подключения к экземпляру, оба описаны в обзоре Auth Proxy от Google. Ваш маршрут VPN покрывает второй; первый обычно уходит обычным путём.
Прямому подключению нужно, чтобы порт PostgreSQL экземпляра был доступен через приватный маршрут, а это совсем другой разговор про firewall. Если ваша сетевая команда разрешает только исходящий 443 из клиентских подсетей, прокси подходит без изменения правил, а прямой путь нет. Этот единственный факт решает выбор чаще любого архитектурного предпочтения.
Ни один из путей не требует, чтобы у экземпляра был публичный адрес, и ни один не оправдывает его добавление.
Где прокси не помогает
Прокси не исправляет отсутствующий маршрут. Если маршрут private-services-access отсутствует или VPN его не передаёт, коннектор падает, а локальный слушатель всё ещё сидит и слушает — и это самая запутанная часть.
Он также не защищает участок между вашим приложением и прокси. На одном ноутбуке этот участок — loopback, и всё в порядке. Если вы привяжете слушатель к wildcard-адресу, чтобы коллега мог до него добраться, вы построили шлюз к базе данных без аутентификации и назвали это удобством. Держите его на loopback и дайте коллеге получить собственные учётные данные.
И он не делает Private Service Connect и private services access взаимозаменяемыми. Экземпляру PSC нужна своя схема DNS и вызов --psc вместо формы --private-ip.
Выбор, а затем проверка в любом случае
Выбирайте прокси, когда хотите IAM на пути, короткоживущие учётные данные и никаких изменений входящего firewall.
Выбирайте прямой маршрут, когда поддерживаемый клиент уже имеет надёжные учётные данные базы, а сетевая команда готова открыть порт. В любом случае проверяйте реальным запросом, а не успешным подключением: подключитесь, выполните одно чтение по известной таблице и посмотрите, что сервер видит в вашей сессии.
После переподключения VPN считайте истёкшие учётные данные, отсутствующий приватный маршрут и отказ во входе в базу тремя разными сбоями. Только один из них — проблема сети, и только один должен когда-либо приводить к изменению правила firewall.