API di Google su VPN: instrada la VIP, non solo la sottorete

Accedi via SSH al server locale, alza il tunnel e la VM privata risponde; poi la prima chiamata a un’API di Google fallisce senza rotta. La sottorete della VM e le VIP dell’API sono destinazioni diverse, quindi una rotta per una non seleziona l’altra. Tre condizioni devono valere prima che una chiamata API privata funzioni. Il nome dell’API deve risolversi in una VIP, il prefisso VIP deve essere annunciato attraverso il tunnel e la VPC deve sapere come rimandare indietro la risposta. Un ping non te ne dice nulla, e nemmeno una sessione SSH funzionante verso una macchina nella sottorete.

Le VIP dell’API sono destinazioni separate

Google pubblica VIP dedicate per l’accesso all’API dalla rete locale, e sono quegli indirizzi che il tuo DNS deve restituire per i nomi dell’API. Entrambi sono prefissi piccoli e nessuno è spazio RFC 1918:

Indirizzi che sembrano pubblici non significano che la rotta debba uscire dal tunnel per l’internet ordinario. I prefissi esistono perché un client locale raggiunga i front end di Google lungo un percorso supportato invece che da un punto di uscita arbitrario. Trattali come destinazioni che appartengono al tunnel, non come host da sondare. Una regola del firewall scritta per l’uscita internet di solito li scarta, ed è una ragione comune per cui una chiamata fallisce prima di iniziare.

Il DNS decide quale endpoint raggiungi

Punta il resolver locale sui record che Google documenta per l’endpoint scelto, così che i nomi necessari all’applicazione rispondano con quella VIP. Il solo googleapis.com non è un inventario: i registri dei pacchetti, i registri dei container e i connettori di migrazione hanno i propri nomi documentati. Anche la VIP limitata non trasporta ogni servizio, quindi un nome che si risolve può restare non supportato. Annota i domini che l’applicazione contatta davvero prima di toccare il resolver.

Indovinare un indirizzo VM nella VPC al posto di un nome di servizio non è una correzione, e di solito nasconde la lacuna DNS finché un altro client non fallisce.

Annuncia il prefisso VIP, conserva il resto

Con una connessione basata su BGP, il Cloud Router deve annunciare il prefisso VIP scelto perché il router locale impari quell’intervallo attraverso la sessione prevista. Annunciare solo le sottoreti della VPC non aggiunge quell’intervallo, e il router locale continua a usare il suo percorso predefinito per quegli indirizzi. Il prefisso nella tabella di routing è l’unica prova che l’annuncio ha attraversato la sessione.

Conserva gli annunci esistenti mentre aggiungi il nuovo, perché le opzioni a livello di router e a livello di peer hanno portata diversa, e sostituire l’insieme può ritirare reti che già funzionavano. Poi controlla l’annuncio effettivo su ogni sessione invece che sul router intero. Un prefisso mancante e un prefisso ritirato sembrano uguali dal lato locale, quindi è la vista della sessione a separare una dimenticanza da una regressione.

Il lato VPC ha bisogno della propria rotta e del percorso di ritorno

Dentro la VPC, il percorso della VIP deve usare il gateway internet predefinito come salto successivo, e nonostante il nome quel traffico resta nella rete di Google. La VPC ha anche bisogno di una rotta di ritorno verso l’origine locale attraverso la VPN, che è un oggetto separato dal prefisso annunciato. Tieni conto dei requisiti regionali di routing documentati quando il tunnel e il client non sono nella stessa regione.

Controlla il percorso di ritorno in modo indipendente, perché una direzione della richiesta che funziona può nascondere una direzione della risposta rotta. Due direzioni, due rotte, e ciascuna fallisce con il proprio sintomo.

Prova la richiesta, poi leggi il rifiuto

L’eco ICMP non riceve risposta da queste VIP, quindi un ping fallito non dimostra nulla e uno riuscito molto poco. Dal client reale, esamina la risposta del nome e la rotta selezionata, poi invia una richiesta HTTPS autorizzata al servizio che ti interessa. Se la richiesta raggiunge il servizio e viene rifiutata, guarda le credenziali, l’IAM e qualsiasi politica di perimetro del servizio applicabile.

Il routing privato non concede autorizzazione API e non cambia ciò che all’identità è consentito fare. Il successo del trasporto e una risposta autorizzata sono risultati separati, e servono entrambi. Mantieni esplicito anche il percorso IPv6, perché configurare i prefissi IPv4 non dice nulla su un client che preferisce IPv6.

La guida di Google su Private Google Access dalla rete locale copre insieme i record DNS e i requisiti di routing, quindi confronta le tue impostazioni di resolver e di annuncio con essa e non con un post di un forum. Poi ripeti la stessa richiesta e annota la risposta e la rotta nello stesso ticket.