Google API tra VPN: itineru la VIP, ne nur la subreton

Ensalutu per SSH al la loka servilo, levu la tunelon, kaj la privata VM respondas; poste la unua voko al Google API malsukcesas sen itinero. La VM-subreto kaj la VIP-adresoj de la API estas malsamaj celoj, do itinero por unu ne elektas la alian. Tri kondiĉoj devas validi antaŭ ol privata API-voko povas funkcii. La API-nomo devas solviĝi al VIP, la VIP-prefikso devas esti anoncata tra la tunelo, kaj la VPC devas scii kiel sendi la respondon reen. Ping ne diras al vi ion el tio, nek funkcianta SSH-sesio al maŝino en la subreto.

La VIP-adresoj de la API estas apartaj celoj

Google publikigas dediĉitajn VIP-adresojn por API-aliro el la loka reto, kaj tiuj estas la adresoj, kiujn via DNS devas redoni por la API-nomoj. Ambaŭ estas malgrandaj prefiksoj kaj nek unu estas spaco RFC 1918:

Adresoj, kiuj aspektas publikaj, ne signifas, ke la itinero devas forlasi la tunelon por la ordinara interreto. La prefiksoj ekzistas por ke loka kliento povu atingi la antaŭajn servojn de Google per subtenata vojo anstataŭ arbitra elirejo. Traktu ilin kiel celojn apartenantajn al la tunelo, ne kiel gastigantojn por sondi. Fajroŝirma regulo skribita por interreta eliro kutime forĵetas ilin, kaj tio estas ofta kaŭzo, kial voko malsukcesas antaŭ ol ĝi komenciĝas.

DNS decidas, kiun finpunkton vi atingas

Direktu la lokan solvilon al la rikordoj, kiujn Google dokumentas por la elektita finpunkto, por ke la nomoj bezonataj de la aplikaĵo respondu per tiu VIP. Nur googleapis.com ne estas inventaro: pakaĵregistroj, ujregistroj kaj migradaj konektiloj havas proprajn dokumentitajn nomojn. La limigita VIP ankaŭ ne portas ĉiun servon, do nomo, kiu solviĝas, povas ankoraŭ esti nesubtenata. Notu la domajnojn, kiujn la aplikaĵo efektive kontaktas, antaŭ ol tuŝi la solvilon.

Diveni VM-adreson en la VPC kiel anstataŭon por serva nomo ne estas riparo, kaj ĝi kutime kaŝas la DNS-mankon ĝis alia kliento malsukcesas.

Anoncu la VIP-prefikson, konservu la reston

Ĉe BGP-bazita konekto, la Cloud Router devas anonci la elektitan VIP-prefikson, por ke la loka itinero povu lerni tiun intervalon tra la celita sesio. Anonci nur la VPC-subretojn ne aldonas tiun intervalon, kaj la loka itinero daŭre uzas sian defaŭltan vojon por tiuj adresoj. La prefikso en la itinera tabelo estas la sola pruvo, ke la anonco trapasis la sesion.

Konservu la ekzistantajn anoncojn dum vi aldonas la novan, ĉar opcioj ĉe itinera nivelo kaj ĉe samtavola nivelo havas malsaman atingon, kaj anstataŭigi la aron povas retiri retojn, kiuj jam funkciis. Poste kontrolu la efektivan anoncon en ĉiu sesio anstataŭ en la itinero entute. Mankanta prefikso kaj retirita prefikso aspektas identaj de la loka flanko, do la sesia vido estas tio, kio apartigas preterlasadon de regreso.

La VPC-flanko bezonas propran itineron kaj revenan vojon

Ene de la VPC, la VIP-vojo devas uzi la defaŭltan interretan pordegon kiel sekvan salton, kaj malgraŭ la nomo tiu trafiko restas en la reto de Google. La VPC ankaŭ bezonas itineron reen al la loka fonto tra la VPN, kio estas aparta objekto de la anoncita prefikso. Konsideru la dokumentitajn regionajn itinrajn postulojn, kiam la tunelo kaj la kliento ne estas en la sama regiono.

Kontrolu la revenan vojon sendepende, ĉar funkcianta petdirekto povas kaŝi rompitan responddirekton. Du direktoj, du itineroj, kaj ĉiu malsukcesas per sia propra simptomo.

Testu la peton, poste legu la malakcepton

ICMP-ekoo ricevas neniun respondon de tiuj VIP-adresoj, do malsukcesa ping pruvas nenion kaj sukcesa tre malmulte. De la efektiva kliento, ekzamenu la respondon de la nomo kaj la elektitan itineron, poste faru rajtigitan HTTPS-peton al la servo, kiu gravas al vi. Se la peto atingas la servon kaj estas malakceptata, rigardu la akreditaĵojn, IAM kaj ajnan validan servperimetran politikon.

Privata itinerado ne donas API-rajtigon kaj ne ŝanĝas, kion la idento rajtas fari. Transporta sukceso kaj rajtigita respondo estas apartaj rezultoj, kaj vi bezonas ambaŭ. Tenu ankaŭ la IPv6-vojon eksplicita, ĉar agordi la IPv4-prefiksojn diras nenion pri kliento, kiu preferas IPv6.

La gvidilo de Google pri Private Google Access el la loka reto kovras kune la DNS-rikordojn kaj la itinrajn postulojn, do komparu viajn agordojn de solvilo kaj anoncado kun ĝi, ne kun forumafiŝo. Poste relanĉu la saman peton kaj notu la respondon kaj la itineron en la sama bileto.