Google API през VPN: насочете маршрута към VIP, а не само към подмрежата

Влезте по SSH в локалния сървър, вдигнете тунела и частната VM отговаря; после първото извикване към Google API се проваля без маршрут. Подмрежата на VM и VIP адресите на API са различни дестинации, така че маршрут към едната не избира другата. Три условия трябва да са изпълнени, преди частно извикване на API да работи. Името на API трябва да се разрешава до VIP, VIP префиксът трябва да се обявява през тунела, а VPC трябва да знае как да върне отговора. Ping не ви казва нищо от това, нито работеща SSH сесия към машина в подмрежата.

VIP адресите на API са отделни дестинации

Google публикува отделни VIP адреси за достъп до API от локална мрежа и точно тези адреси вашият DNS трябва да връща за имената на API. И двата са малки префикси и нито един не е от пространството RFC 1918:

Адреси, които изглеждат публични, не означават, че маршрутът трябва да напусне тунела за обикновения интернет. Префиксите съществуват, за да може локален клиент да достигне фронтендовете на Google по поддържан път вместо през произволна изходна точка. Отнасяйте се към тях като към дестинации, принадлежащи на тунела, а не като към хостове за проверка. Правило на защитната стена, написано за изход в интернет, обикновено ги отхвърля и това е честа причина извикване да се провали още преди да започне.

DNS определя коя крайна точка достигате

Насочете локалния резолвер към записите, които Google документира за избраната крайна точка, така че имената, от които приложението се нуждае, да отговарят с този VIP. Самото googleapis.com не е инвентар: регистрите на пакети, регистрите на контейнери и конекторите за миграция имат свои документирани имена. Ограниченият VIP също не носи всяка услуга, така че име, което се разрешава, може все още да не се поддържа. Запишете домейните, които приложението реално посещава, преди да пипате резолвера.

Отгатването на адрес на VM във VPC като заместител на име на услуга не е поправка и обикновено прикрива липсата в DNS, докато друг клиент се провали.

Обявявайте VIP префикса, запазете останалото

При връзка на базата на BGP Cloud Router трябва да обявява избрания VIP префикс, за да може локалният рутер да научи този диапазон през предвидената сесия. Обявяването само на подмрежите във VPC не добавя този диапазон и локалният рутер продължава да използва пътя си по подразбиране за тези адреси. Префиксът в таблицата за маршрутизация е единственото доказателство, че обявяването е преминало сесията.

Запазете съществуващите обявявания, докато добавяте новото, защото опциите на ниво рутер и на ниво партньор имат различен обхват и подмяната на набора може да оттегли мрежи, които вече работят. След това проверете ефективното обявяване във всяка сесия, а не на рутера като цяло. Липсващ префикс и оттеглен префикс изглеждат еднакво от локалната страна, така че именно изгледът на сесията различава пропуск от регресия.

Страната на VPC се нуждае от собствен маршрут и обратен път

Във VPC пътят към VIP трябва да използва шлюза за интернет по подразбиране като следващ хоп и въпреки името този трафик остава в мрежата на Google. VPC се нуждае и от маршрут обратно към локалния източник през VPN, което е отделен обект от обявения префикс. Съобразете се с документираните регионални изисквания за маршрутизация, когато тунелът и клиентът не са в един и същ регион.

Проверявайте обратния път независимо, защото работеща посока на заявката може да скрие счупена посока на отговора. Две посоки, два маршрута и всяка се проваля със собствен симптом.

Тествайте заявката, после прочетете отказа

ICMP echo не получава отговор от тези VIP адреси, така че неуспешен ping не доказва нищо, а успешен — много малко. От реалния клиент проверете отговора на името и избрания маршрут, после направете оторизирана HTTPS заявка към услугата, която ви интересува. Ако заявката достигне услугата и бъде отказана, погледнете идентификационните данни, IAM и всяка политика на периметър на услугата, която се прилага.

Частната маршрутизация не дава оторизация за API и не променя какво е разрешено на идентичността. Успехът на транспорта и оторизираният отговор са отделни резултати и ви трябват и двата. Пазете пътя за IPv6 също толкова явен, защото конфигурирането на IPv4 префиксите не казва нищо за клиент, който предпочита IPv6.

Ръководството на Google за Private Google Access от локална мрежа обхваща записите в DNS и изискванията за маршрутизация заедно, затова сравнявайте настройките на резолвера и обявяването с него, а не с публикация във форум. След това повторете същата заявка и запишете отговора и маршрута в същия тикет.