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 не задіяна.