Google-API’s oor ’n VPN: die roete na die VIP, nie net die subnet nie

Meld per SSH by die plaaslike bediener aan, bring die tonnel op, en die private VM antwoord; dan misluk die eerste oproep na ’n Google-API sonder ’n roete. Die VM-subnet en die API-VIP’s is verskillende bestemmings, so ’n roete vir die een kies nie die ander nie. Drie voorwaardes moet geld voordat ’n private API-oproep kan werk. Die API-naam moet na ’n VIP oplos, die VIP-voorvoegsel moet oor die tonnel geadverteer word, en die VPC moet weet hoe om die antwoord terug te stuur. ’n Ping vertel jou niks daarvan nie, en ’n werkende SSH-sessie na ’n masjien in die subnet ook nie.

Die API-VIP’s is aparte bestemmings

Google publiseer toegewyde VIP’s vir plaaslike API-toegang, en dit is die adresse wat jou DNS vir die API-name moet terugstuur. Albei is klein voorvoegsels en nie een is RFC 1918-ruimte nie:

Adresse wat publiek lyk, beteken nie dat die roete die tonnel moet verlaat nie vir die gewone internet. Die voorvoegsels bestaan sodat ’n plaaslike kliënt Google se voorkante via ’n ondersteunde pad kan bereik in plaas van ’n willekeurige uitgangspunt. Behandel hulle as bestemmings wat aan die tonnel behoort, nie as gashere om te ondersoek nie. ’n Firewall-reël wat vir internet-uitgang geskryf is, sal hulle gewoonlik laat val, en dit is een algemene rede waarom ’n oproep misluk voordat dit begin.

DNS bepaal watter eindpunt jy bereik

Rig die plaaslike oplosser na die rekords wat Google vir die gekose eindpunt dokumenteer, sodat die name wat die toepassing nodig het, met daardie VIP antwoord. Om net googleapis.com te karteer is nie ’n inventaris nie: pakketregisters, houerregisters en migrasiekonnektore het hul eie gedokumenteerde name. Die beperkte VIP dra ook nie elke diens nie, so ’n naam wat oplos, kan steeds onondersteun wees. Skryf die domeine neer wat die toepassing werklik kontak voordat jy aan die oplosser raak.

Om ’n VPC-VM-adres te raai as plaasvervanger vir ’n diensnaam is nie ’n oplossing nie, en dit verberg gewoonlik die DNS-gaping totdat ’n ander kliënt misluk.

Adverteer die VIP-voorvoegsel, behou die res

Met ’n BGP-gebaseerde verbinding moet die Cloud Router die gekose VIP-voorvoegsel adverteer sodat die plaaslike router daardie reeks oor die beoogde sessie kan leer. Om net die VPC-subnette te adverteer voeg nie daardie reeks by nie, en die plaaslike router bly sy standaardpad vir daardie adresse gebruik. Die voorvoegsel in die roetetabel is die enigste bewys dat die advertensie die sessie oorgesteek het.

Behou die bestaande advertensies terwyl jy dit byvoeg, want opsies op routervlak en portvlak het verskillende bereik, en om die stel te ruil kan netwerke onttrek wat reeds gewerk het. Kyk dan na die effektiewe advertensie op elke sessie eerder as op die router as geheel. ’n Ontbrekende voorvoegsel en ’n onttrekte voorvoegsel lyk dieselfde van die plaaslike kant, so die sessie-aansig is wat ’n weglating van ’n regressie skei.

Die VPC-kant het sy eie roete en terugpad nodig

Binne die VPC moet die VIP-pad die standaard internet-gateway as volgende sprong gebruik, en ten spyte van die naam bly daardie verkeer binne Google se netwerk. Die VPC het ook ’n roete terug na die plaaslike bron deur die VPN nodig, wat ’n aparte objek van die geadverteerde voorvoegsel is. Hou rekening met die gedokumenteerde streekroeteringsvereistes wanneer die tonnel en die kliënt nie in dieselfde streek is nie.

Kontroleer die terugpad onafhanklik, want ’n werkende versoekrigting kan ’n stukkende antwoordrigting verberg. Twee rigtings, twee roetes, en elkeen misluk met sy eie simptoom.

Toets die versoek, lees dan die verwerping

ICMP-eggokry geen antwoord van hierdie VIP’s nie, so ’n mislukte ping bewys niks en ’n suksesvolle een bewys baie min. Vanuit die werklike kliënt, ondersoek die naam se antwoord en die gekose roete, en maak dan ’n gemagtigde HTTPS-versoek aan die diens waaroor jy gaan. As die versoek die diens bereik en verwerp word, kyk na aanmeldgegewens, IAM en enige diensperimeterbeleid wat geld.

Private roetering verleen nie API-magtiging nie, en dit verander nie wat die identiteit mag doen nie. Vervoersukses en ’n gemagtigde antwoord is aparte resultate, en jy het albei nodig. Hou ook die IPv6-pad eksplisiet, want om die IPv4-voorvoegsels te configureer sê niks oor ’n kliënt wat IPv6 verkies nie.

Google se gids vir plaaslike Private Google Access dek die DNS-rekords en die roeteringsvereistes saam, so vergelyk jou oplosser- en advertensie-instellings daarmee eerder as met ’n forumplasing. Voer dan dieselfde versoek weer uit en noteer die antwoord en die roete in dieselfde kaartjie.