API de Google per VPN: encamina la VIP, no només la subxarxa

Entra per SSH al servidor local, aixeca el túnel i la VM privada respon; després la primera crida a una API de Google falla sense ruta. La subxarxa de la VM i les VIP de l’API són destinacions diferents, així que una ruta per a una no selecciona l’altra. S’han de complir tres condicions abans que una crida privada a l’API pugui funcionar. El nom de l’API s’ha de resoldre a una VIP, el prefix de la VIP s’ha d’anunciar pel túnel i la VPC ha de saber com enviar la resposta de tornada. Un ping no us diu res d’això, i una sessió SSH que funciona cap a una màquina de la subxarxa tampoc.

Les VIP de l’API són destinacions separades

Google publica VIP dedicades per a l’accés a l’API des de la xarxa local, i aquestes són les adreces que el vostre DNS ha de retornar per als noms de l’API. Totes dues són prefixos petits i cap no és espai RFC 1918:

Les adreces que semblen públiques no volen dir que la ruta hagi de sortir del túnel per a la internet ordinària. Els prefixos existeixen perquè un client local pugui arribar als frontals de Google per un camí suportat en lloc d’un punt de sortida arbitrari. Tracteu-los com a destinacions que pertanyen al túnel, no com a equips per sondar. Una regla de tallafoc escrita per a la sortida a internet normalment els descarta, i és una raó habitual perquè una crida falli abans de començar.

El DNS decideix a quin punt final arribeu

Apunteu el resolutor local als registres que Google documenta per al punt final triat, de manera que els noms que l’aplicació necessita responguin amb aquella VIP. Només googleapis.com no és cap inventari: els registres de paquets, els registres de contenidors i els connectors de migració tenen els seus propis noms documentats. La VIP restringida tampoc no porta tots els serveis, així que un nom que es resol pot continuar sense suport. Anoteu els dominis que l’aplicació contacta realment abans de tocar el resolutor.

Endevinar una adreça de VM de la VPC com a substitut d’un nom de servei no és cap solució, i normalment amaga el buit de DNS fins que falla un altre client.

Anuncieu el prefix de la VIP, manteniu la resta

Amb una connexió basada en BGP, el Cloud Router ha d’anunciar el prefix de la VIP triat perquè el router local pugui aprendre aquest rang per la sessió prevista. Anunciar només les subxarxes de la VPC no afegeix aquest rang, i el router local continua utilitzant el seu camí per defecte per a aquestes adreces. El prefix de la taula d’encaminament és l’única prova que l’anunci ha travessat la sessió.

Conserveu els anuncis existents mentre l’afegiu, perquè les opcions a nivell de router i a nivell de parell tenen abast diferent, i intercanviar el conjunt pot retirar xarxes que ja funcionaven. Després comproveu l’anunci efectiu a cada sessió en lloc de al router sencer. Un prefix que falta i un prefix retirat es veuen iguals des del costat local, així que la vista de la sessió és el que separa una omissió d’una regressió.

El costat de la VPC necessita la seva pròpia ruta i camí de tornada

Dins de la VPC, el camí de la VIP ha d’utilitzar la porta d’enllaç d’internet per defecte com a següent salt, i malgrat el nom aquest trànsit es queda dins de la xarxa de Google. La VPC també necessita una ruta de tornada a l’origen local per la VPN, que és un objecte separat del prefix anunciat. Tingueu en compte els requisits regionals d’encaminament documentats quan el túnel i el client no són a la mateixa regió.

Comproveu el camí de tornada de manera independent, perquè una direcció de petició que funciona pot amagar una direcció de resposta trencada. Dues direccions, dues rutes, i cadascuna falla amb el seu propi símptoma.

Prova la petició i després llegeix el rebuig

L’eco ICMP no obté resposta d’aquestes VIP, així que un ping fallit no demostra res i un que funcioni demostra molt poc. Des del client real, examineu la resposta del nom i la ruta seleccionada, i després feu una petició HTTPS autoritzada al servei que us interessa. Si la petició arriba al servei i es rebutja, mireu les credencials, l’IAM i qualsevol política de perímetre de servei que s’apliqui.

L’encaminament privat no atorga autorització d’API i no canvia què pot fer la identitat. L’èxit del transport i una resposta autoritzada són resultats separats, i us calen tots dos. Manteniu també explícit el camí IPv6, perquè configurar els prefixos IPv4 no diu res sobre un client que prefereix IPv6.

La guia de Google sobre Private Google Access des de la xarxa local cobreix els registres DNS i els requisits d’encaminament alhora, així que compareu la configuració del resolutor i de l’anunci amb ella i no amb una publicació d’un fòrum. Després torneu a executar la mateixa petició i anoteu la resposta i la ruta al mateix tiquet.