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 не го додава тој опсег, а локалниот рутер продолжува да ја користи својата стандардна патека за тие адреси. Префиксот во табелата за рутирање е единствениот доказ дека објавувањето ја поминало сесијата.

Задржете ги постојните објавувања додека го додавате новото, бидејќи опциите на ниво на рутер и на ниво на peer имаат различен дофат, а замената на множеството може да повлече мрежи што веќе работеа. Потоа проверете го ефективното објавување на секоја сесија наместо на рутерот како целина. Префиксот што недостасува и префиксот што е повлечен изгледаат исто од локалната страна, така што токму приказот на сесијата го одделува пропустот од регресија.

Страната на VPC бара своја рута и повратен пат

Внатре во VPC, патеката до VIP мора да го користи стандардниот интернет gateway како следен хоп, и покрај името тој сообраќај останува во мрежата на Google. VPC бара и рута назад до локалниот извор преку VPN, што е одделен објект од објавениот префикс. Земете ги предвид документираните регионални барања за рутирање кога тунелот и клиентот не се во истиот регион.

Проверете го повратниот пат независно, бидејќи работниот правец на барањето може да скрие расипан правец на одговорот. Два правци, две рути и секоја не успева со свој симптом.

Тестирајте го барањето, потоа прочитајте го одбивањето

ICMP ехото не добива одговор од овие VIP адреси, така што неуспешниот ping не докажува ништо, а успешниот многу малку. Од вистинскиот клиент, проверете го одговорот на името и избраната рута, потоа упатете овластено HTTPS барање до услугата што ве интересира. Ако барањето стигне до услугата и биде одбиено, погледнете ги акредитивите, IAM и секоја применлива политика на периметарот на услугата.

Приватното рутирање не дава авторизација за API и не менува што смее да прави идентитетот. Успехот на транспортот и овластениот одговор се одделни резултати и ви требаат двете. Држете ја и IPv6 патеката експлицитна, бидејќи конфигурирањето на IPv4 префиксите не кажува ништо за клиент што претпочита IPv6.

Водичот на Google за Private Google Access од локалната мрежа ги покрива записите во DNS и барањата за рутирање заедно, затоа споредете ги поставките на резолверот и објавувањето со него, а не со објава на форум. Потоа повторете го истото барање и запишете го одговорот и рутата во истиот тикет.