Google API через VPN: маршрутизуйте VIP, а не лише підмережу
Маршрут до підмережі в VPC не вибирає VIP-адреси API. Розв'яжіть правильні імена, анонсуйте префікс VIP, збережіть зворотний шлях у VPC і лише потім перевірте HTTPS.
Підключіться через SSH до локального сервера, підніміть тунель, і приватна ВМ відповідає; далі перший виклик Google API не вдається без маршруту. Підмережа ВМ і VIP-адреси API — різні призначення, тому маршрут до одного не вибирає інше. Три умови мають виконуватися, щоб приватний виклик API заробив. Ім'я API має розв'язуватися у VIP, префікс VIP має анонсуватися через тунель, а VPC має знати, як надіслати відповідь назад. Ping нічого з цього не повідомляє, і робоча SSH-сесія до машини в підмережі теж.
VIP-адреси API — окремі призначення
Google публікує виділені VIP-адреси для доступу до API з локальної мережі, і саме ці адреси ваш DNS має повертати для імен API. Обидва — невеликі префікси, і жоден не належить до простору RFC 1918:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Адреси, що виглядають публічними, не означають, що маршрут має залишити тунель для звичайного інтернету. Префікси існують, щоб локальний клієнт досягав фронтендів Google підтримуваним шляхом, а не через довільну точку виходу. Ставтеся до них як до призначень, що належать тунелю, а не як до хостів для перевірки. Правило міжмережевого екрана, написане для виходу в інтернет, зазвичай їх відкидає, і це часта причина, чому виклик не вдається ще до початку.
DNS вирішує, якої кінцевої точки ви досягнете
Спрямуйте локальний резолвер на записи, які Google документує для вибраної кінцевої точки, щоб імена, потрібні застосунку, відповідали цим VIP. Саме лише googleapis.com не є інвентарем: у реєстрів пакетів, реєстрів контейнерів і конекторів міграції є власні документовані імена. Обмежений VIP теж не несе кожну службу, тому ім'я, що розв'язується, може досі бути непідтримуваним. Запишіть домени, з якими застосунок справді звертається, перш ніж торкатися резолвера.
Вгадування адреси ВМ у VPC замість імені служби не є виправленням, і зазвичай воно приховує прогалину в DNS, доки не впаде інший клієнт.
Анонсуйте префікс VIP, збережіть решту
За з'єднання на основі BGP Cloud Router має анонсувати вибраний префікс VIP, щоб локальний маршрутизатор вивчив цей діапазон через потрібну сесію. Анонс лише підмереж VPC не додає цього діапазону, і локальний маршрутизатор далі використовує свій типовий шлях для цих адрес. Префікс у таблиці маршрутизації — єдиний доказ того, що анонс перетнув сесію.
Зберігайте наявні анонси, доки додаєте новий, бо параметри на рівні маршрутизатора й на рівні партнера мають різний обсяг, а заміна набору може відкликати мережі, які вже працювали. Далі перевіряйте чинний анонс у кожній сесії, а не на маршрутизаторі загалом. Відсутній префікс і відкликаний префікс виглядають з локального боку однаково, тому саме вигляд сесії відділяє пропуск від регресії.
Стороні VPC потрібен власний маршрут і зворотний шлях
Усередині VPC шлях до VIP має використовувати типовий шлюз інтернету як наступний крок, і попри назву цей трафік залишається в мережі Google. VPC також потребує маршруту назад до локального джерела через VPN, і це окремий об'єкт від анонсованого префікса. Враховуйте задокументовані регіональні вимоги до маршрутизації, коли тунель і клієнт не в одному регіоні.
Перевіряйте зворотний шлях незалежно, бо робочий напрямок запиту може приховати зламаний напрямок відповіді. Два напрямки, два маршрути, і кожен не вдається зі своїм симптомом.
Перевірте запит, потім прочитайте відмову
ICMP-луна не отримує відповіді від цих VIP, тому невдалий ping нічого не доводить, а успішний — дуже мало. З реального клієнта перевірте відповідь імені та вибраний маршрут, потім надішліть авторизований запит HTTPS до потрібної служби. Якщо запит досягає служби й відхиляється, подивіться на облікові дані, IAM і будь-яку застосовну політику периметра служби.
Приватна маршрутизація не дає авторизації API і не змінює того, що дозволено ідентичності. Успіх транспорту й авторизована відповідь — окремі результати, і потрібні обидва. Тримайте явним і шлях IPv6, бо налаштування префіксів IPv4 нічого не каже про клієнта, який віддає перевагу IPv6.
Посібник Google про Private Google Access із локальної мережі охоплює записи DNS і вимоги до маршрутизації разом, тож порівнюйте налаштування резолвера й анонсу з ним, а не з дописом на форумі. Потім повторіть той самий запит і запишіть відповідь і маршрут у тому самому тікеті.