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.
Получаването на частен достъп означава въвеждане на частна крайна точка или дизайн с private link, след което добавяне на частна DNS зона, така че публичното име да отговаря с тази крайна точка вместо с интернет. VPN, комбиниран с правило за крайна точка на услуга, е друга архитектура, която изглежда подобна само на диаграма. App Service следва същата логика от другата посока: интеграцията с VNet позволява на приложението да прави изходящи повиквания към VNet и не създава входящ частен път от вашия тунел. Затова входящият частен достъп изисква частна крайна точка, среда на App Service или шлюз пред приложението, а кое от тях можете да използвате, зависи от плана.
Проверка четвърта: продукти със собствена входна врата
Firebase Hosting не може да бъде прикачен към Cloud VPN, защото слоят за хостване е глобален фронтенд, а не нещо вътре в VPC на проекта. Документираната алтернатива е да изградите контролираната входна точка сами, с прокси инстанция или балансиращ товара, поддържан от кофа за съхранение. Във всеки случай сайтът престава да бъде чист продукт за хостване и се превръща в инфраструктура, която вие вече управлявате. Тази размяна заслужава да бъде назована, преди някой да обещае, че тунелът ще я покрие.
Private API Gateway стои по-близо до страната на VPC услугите: интерфейсна VPC крайна точка публикува име на хост, чиито отговори са частни адреси, а трафикът от вашия обект пристига през тунела или през отделен интерконект. Крайната точка трябва да е свързана с API, а сертификатът и името на хоста трябва да съответстват на персонализирания домейн, който извикващите използват.
Тунелите на Google Cloud VPN се обвързват с IP адреси на партньори, а не с имена. Пренасочването на DNS се конфигурира отделно и затова тунелът може да е напълно здрав, докато търсенията в отдалечената частна зона все още се провалят.
След това открийте границата
Изпълнете същата връзка от VM вътре в VPC. Когато там успее, а от VPN клиента се провали, разликата е между пътя на клиента и крайната точка на услугата: маршрут, група за сигурност, политика на крайна точка или име. Когато и двата опита се провалят, нищо в тази мрежа не може да достигне услугата и VPN никога не е бил пречката.
getent hosts db.internal.example
nc -vz db.internal.example 5432Правете търсенето на име и проверката на порт поотделно, защото те се провалят по различни причини и двойката ви казва коя половина от пътя е счупена. Име, което се разрешава до публичен адрес, ви казва, че частната DNS зона не участва.