VPN до VPC работает, но управляемый сервис завершается по тайм-ауту
Туннель заканчивается на вашей границе, а не у входной двери провайдера. Прежде чем менять маршрут, классифицируйте цель как размещённую на VM, подключённую к VPC или только публичную.
Доступ к управляемой базе данных через VPN обычно не удаётся по причине, которую никто не записал в инструкцию: туннель заканчивается на границе вашей сети, а сервис никогда не находился на вашей стороне от неё. Таблица маршрутов выглядит правильно, туннель сообщает, что работает, и соединение всё равно завершается по тайм-ауту. Выполните четыре проверки ниже по порядку и остановитесь на первой, условие прохождения которой не выполнено, потому что каждая следующая проверка предполагает, что предыдущие пройдены.
Проверка первая: где на самом деле находится конечная точка?
VPN-шлюз соединяет две сети, адресацией которых управляете вы. Управляемый сервис работает за собственной входной дверью провайдера, и эта дверь принимает одну из трёх форм в зависимости от продукта. Если вы не знаете, с какой формой имеете дело, никакая работа с маршрутами не поможет, потому что сбой может вовсе не быть сбоем маршрутизации.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Большинство потерянных послеобеденных часов возникает из-за пропуска этой классификации и перехода сразу к таблице маршрутов. Сервис, размещённый у провайдера, с публичной конечной точкой не находится за вашим туннелем, что бы ни говорила схема, а подключённый к VPC никогда не появится в публичном ответе DNS.
Проверка вторая: сервис, подключённый к VPC, например ElastiCache
Кэши такого типа адресуются внутри вашего собственного VPC и вообще не имеют слушателя, обращённого в интернет. Клиентский VPN, завершающийся в том же VPC, может до них добраться, но только когда совпадут три условия. Конечная точка кэша должна быть связана с подсетями, которые видит ваш туннель, её группа безопасности должна разрешать адрес, с которого приходят ваши клиенты, а на стороне клиента нужен маршрут, охватывающий подсети кэша.
Частая ошибка — считать, что соединение где-то рядом тоже учитывается. Подключение VPN к другому VPC или опора только на peering не расширяет группу безопасности кэша или таблицу маршрутов его подсети на ваших клиентов. Когда существующий туннель заканчивается в другом месте, обычный обходной путь — промежуточный хост или VPN-сервер, размещённый внутри этого VPC. Такой обход — это не проект, а именно обход, и в инструкции его следует так и помечать.
Проверка третья: конечная точка PaaS с публичным именем
Azure Database for PostgreSQL представляет публичное имя сервера. Он не даёт вам приватный адрес, который можно закрепить в файле hosts и направить через шлюз. Конечные точки службы виртуальной сети ограничивают, какие подсети могут достичь ресурса; они не дают разрешения локальному клиенту, приходящему через VPN.
Получение приватного доступа означает введение приватной конечной точки или схемы приватного канала, а затем добавление приватной зоны DNS, чтобы публичное имя отвечало этой точкой, а не интернетом. VPN в сочетании с правилом конечной точки службы — это другая архитектура, которая выглядит одинаково только на схеме. App Service следует той же логике с противоположной стороны: интеграция с VNet позволяет приложению делать исходящие вызовы в VNet и не создаёт входящий приватный путь из вашего туннеля. Поэтому входящий приватный доступ требует приватной конечной точки, среды App Service или шлюза перед приложением, и что из этого доступно, зависит от плана.
Проверка четвёртая: продукты с собственной входной дверью
Firebase Hosting нельзя подключить к Cloud VPN, потому что уровень хостинга — это глобальный фронтенд, а не что-то внутри VPC проекта. Документированная альтернатива — построить контролируемую точку входа самостоятельно, с прокси-инстансом или балансировщиком нагрузки на основе бакета. В любом случае сайт перестаёт быть чистым продуктом хостинга и становится инфраструктурой, которой теперь управляете вы. Эту сделку стоит назвать до того, как кто-то пообещает, что туннель её покроет.
Private API Gateway стоит ближе к стороне сервисов VPC: конечная точка VPC типа interface публикует имя хоста, ответами которого являются приватные адреса, а трафик из вашего офиса приходит через туннель или выделенное соединение. Конечная точка должна быть связана с API, а сертификат вместе с именем хоста должны соответствовать пользовательскому домену, который используют вызывающие.
Туннели Google Cloud VPN привязываются к IP-адресам партнёров, а не к именам. Переадресация DNS настраивается отдельно, поэтому туннель может быть полностью исправным, пока поиск в удалённой приватной зоне всё ещё не работает.
Затем определите границу
Выполните то же соединение с VM внутри VPC. Если там оно удаётся, а с клиента VPN нет, разрыв находится между путём клиента и конечной точкой сервиса: маршрут, группа безопасности, политика конечной точки или имя. Если не удаются обе попытки, ничто в этой сети не может достичь сервиса, и VPN никогда не был препятствием.
getent hosts db.internal.example
nc -vz db.internal.example 5432Делайте поиск имени и проверку порта отдельно, потому что они терпят неудачу по разным причинам, и эта пара говорит вам, какая половина пути нарушена. Имя, которое разрешается в публичный адрес, говорит вам, что приватная зона DNS не задействована.