Multaj teamoj kredas, ke privata IP de Cloud SQL funkcias nur de interne de la VPC, kaj la kredo daŭras ĉar la malsukceso aspektas kiel datumbaza problemo. Google dokumentas aliron el retoj konektitaj per Cloud VPN aŭ Cloud Interconnect. Tiuj retoj bezonas ne specialan datumbazan funkcion, sed du itinajn interŝanĝojn, kiujn facile lasas duone agorditaj. La tunelo leviĝas, la komputaj instancoj respondas, kaj la datumbaza konekto finiĝas per tempolimo — ĝuste tiu kombinaĵo, kiu sendas homojn al la malĝusta konzolo.

Mito: privata IP signifas privata al la VPC

Aliro al privataj servoj estas VPC-peering inter via reto kaj produktanta reto posedata de Google. La atribuita gamo por la servo loĝas ĉe la produktanta flanko, kaj la instanca adreso estas ene de ĝi. Pro tiu peering datumbazo en via projekto povas sidi sur adreso, al kiu via VPC itinas, kvankam neniu via eksplicita subreto enhavas ĝin.

Ĉar ĝi estas peering, ĝi ankaŭ havas peering-konduton, inkluzive la parton, kie propraj itineroj ne transiras aŭtomate.

Mito: funkcianta tunelo portas la datumbazan itinon kun si

Du gamoj devas postvivi la vojaĝon. La unua estas la klienta prefikso: via loka reto devas esti konata al la Cloud Router per konkretaj prefiksoj, ĉar defaŭlta itinero ne povas liveri la importon, kiun la produktanta reto bezonas por la revena vojo. La dua estas la atribuita serva gamo, kiun la ekstera flanko devas lerni, por ke ĝiaj pakaĵoj al la datumbazo havu kien iri. Ili estas malsamaj itineroj prizorgataj ĉe malsamaj limoj, kaj ripari unu lasas la alian rompita.

Ĉe la Google-flanko tio signifas ŝalti Export custom routes sur la koncernaj peering-konektoj kaj aldoni la atribuitan servan gamon al la anoncitaj itineroj de Cloud Router por la tunelo.

Konservu la anoncojn, kiuj jam estas tie. Aldoni la servan gamon ne devus forigi la VPC-itinerojn, kiujn la sama BGP-sesio portas por alia trafiko, kaj anoncaro anstataŭigita tute estas dua paneo kaŝita malantaŭ la unua. Kontrolu ankaŭ la efektivajn itinerojn sur la ekstera aparato, ĉar povi atingi la VPN-enirejon aŭ alian subreton pruvas nur transporton.

Mito: Cloud SQL Auth Proxy solvas la reton

The Auth Proxy provizas subtenatan aŭtentikigon kaj ĉifritan transporton inter via aplikaĵo kaj la instanco. Ĝi ne kreas itinon. Prokzio startigita sur gastiganto sen vojo al la privata reto malsukcesos same kiel rekta konekto, kaj ĝiaj protokoloj malpli helpos pri la kialo. Movi la prokzion al gastiganto, kiu ja havas konektecon, ŝanĝas kiun parton de la vojo devas funkcii, kaj tio estas vera dezajna decido, ne provizora solvo.

Kion ĝi ne faras, estas ebligi al malkonektita tekkomputilo atingi instancon nur privatan.

Mito: Private Service Connect sekvas la samajn regulojn

Private Service Connect uzas finpunkton en via propra subreto kaj DNS-aranĝon, kiun vi kontrolas, do la itinero al ĝi estas ordinara itinero al adreso, kiun vi posedas. Agordoj de peering-eksporto ne validas por tiu dezajno, kaj kopii peering-ŝanĝojn en PSC-disponigon aldonas riskon sen aldoni atingeblon.

Ambaŭ donas al vi privatan adreson; la simileco ĉesas tie.

Testu la vojon en la ĝusta ordo

De la ekstera kliento testu unue la TCP-finpunkton de la datumbazo. Kompletigita TCP-manpremo signifas, ke itinado, fajromuro kaj aŭskultanto estas ĉiuj en loko, kaj la sekva testo estas permesita aŭtentikigita operacio. Rifuzo de aŭtentikigo fakte estas bona novaĵo tiumomente, ĉar ĝi pruvas, ke datumbaza aŭskultanto respondis. ICMP-tempolimo preskaŭ nenion diras pri datumbaza aliro, ĉar multaj vojoj forĵetas ĝin dum ili senprobleme plusendas TCP.

Se viaj klientaj gamoj estas ekster RFC 1918, revizuu la pliajn postulojn pri itinera eksporto kaj reta rajtigo antaŭ ol konkludi, ke la dezajno ne estas subtenata.

Notu kvar objektojn kun la konekto: la eksteran prefikson, la atribuitan servan gamon, la koncernajn peering-konektojn kaj la itinilon, kiu anoncas. Tiuj kvar klarigas la tutan privatan vojon, kaj ili anstataŭigas la folkloron, ke Cloud SQL aŭ ĉiam bezonas prokzion aŭ tute ne atingeblas tra VPN.

Rilataj artikoloj