Naabot ng App Engine ang iyong VPN database: ano ang dapat magtugma

Ang pahayag na hindi maabot ng App Engine Standard ang isang pribadong database sa Cloud VPN ay labi ng naunang henerasyon ng platform. Hindi nakakakuha ng VPC-native na address ang mga Standard instance tulad ng ilang ibang runtime, pero makakapagpadala sila ng egress sa pamamagitan ng Serverless VPC Access connector na nasa iyong network. Kapag umiral na ang landas na iyon, tinitingnan ng Cloud VPN at ng remote firewall ang trapiko ng connector tulad ng alinmang pinagmulan. Bihirang mabigo ang kakayahan mismo. Isa ito sa tatlong setting na hindi kailanman naihanay.

Saan galing ang lumang sagot

Bago umiral ang mga connector, ang praktikal na sagot ay talagang makakausap lamang ng Standard ang mga pampublikong endpoint, at lumipat ang mga team sa proxy VM o ibang runtime para iwasan iyon. Nagbago ang platform, hindi ang alamat. Marami sa mga payo online ay sumasalamin pa rin sa panahong wala talagang opsyon sa egress.

Ang pagwawasto ay mas makitid kaysa sa tunog nito. Naabot ng Standard ang pribadong network, pero sa pamamagitan lamang ng sinusuportahang egress integration, at para lamang sa mga destinasyong aktwal na nahuhuli ng integration na iyon.

Piliin muna ang egress path

Ang connector na nakakabit sa serbisyo ang naglalagay ng trapiko nito sa VPC. Inililista ng dokumentasyon ng connector ang regional na paunang kondisyon at mga setting ng egress; dapat umiral ang connector sa rehiyon ng serbisyo at magagamit ng identity na nagde-deploy.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only nagpapadala ng pribadong destinasyon sa VPC at iniiwan ang lahat ng iba sa normal na internet path, na karaniwang kailangan ng koneksyon sa database. all-traffic itinutulak nang malawak ang palabas na trapiko sa VPC, kaya namamana rin ng mga ordinaryong internet call ang NAT at firewall posture ng VPC.

Ang pag-edit ng file nang lokal ay walang binabago hanggang mag-deploy ka. Pinapanatili ng tumatakbo na bersyon ang configuration kung saan ito ginawa.

Ang source address ay ang connector, hindi ang iyong laptop

Dito napupunta ang karamihan ng oras sa pag-debug. Dapat payagan ng remote VPN gateway at ng database firewall ang range na inilaan sa connector sa loob ng VPC, hindi ang address ng iyong opisina at hindi ang pampublikong egress address ng serbisyo. Hanapin ang range na iyon sa console bago ka magsulat ng kahit isang rule.

May dalawa pang lugar na dapat magtugma. Kailangan ng VPC route table ng ruta patungo sa remote database network, at kailangan ng remote side ng return route para sa range ng connector. Kung gumagamit ang tunnel ng traffic selectors, tiyakin na ang range ng connector ay nasa loob ng napagkasunduang saklaw. Ang rutang umiiral lamang sa direksyong remote-to-local ay karaniwang pagkukulang, at pinapadaan nito ang ping nang hindi kailanman kinukumpleto ang TCP handshake.

Ang tunnel na tumatanggap lamang ng VM subnet ay itatapon ang mga packet ng connector nang walang kapaki-pakinabang na error message, kaya mukhang problema sa kredensyal ang timeout ng database.

Iba ang dinaraanan ng DNS

Ang hostname ng pribadong database ay dapat ma-resolve sa loob ng network na naaabot ng connector, sa pamamagitan ng Cloud DNS peering o forwarding zone na magagamit ng VPC. Ang pag-resolve nito sa iyong workstation ay walang pinapatunayan tungkol sa naka-deploy na serbisyo, dahil hindi ginagamit ng iyong laptop ang resolver na iyon.

Kung ma-resolve ang pangalan sa pampublikong address mula sa loob ng VPC, malapit ka nang mag-debug ng maling firewall.

Hindi ginagamit ng URL Fetch ang connector

Saklaw ng egress setting ang normal na palabas na socket ng runtime, at ang legacy na URL Fetch service ay hindi bahagi ng path na iyon. Ang request na inilabas sa urlfetch ay binabalewala ang connector anuman ang sabihin ng configuration. Kapag ang bumabagsak na call ay nasa lumang library na gumagamit pa rin ng URL Fetch, ang solusyon ay ilipat ang call na iyon sa standard na HTTP client.

Para sa database driver, bihira itong maging problema, pero ito ang klasikong dahilan kung bakit gumagana ang isang endpoint at hindi ang isa mula sa parehong serbisyo.

I-verify gamit ang isang makitid na query

Mag-deploy, pagkatapos ay magpatakbo ng isang pinapayagang database operation mula sa naka-deploy na bersyon habang pinapanood ang remote side. Ang source address na naitatala ng database o ng VPN gateway ay dapat na sa connector. Kung hindi, hindi kailanman pumasok ang request sa VPC at walang tunnel configuration ang makakapag-ayos nito. Ihambing ito sa range na hinanap mo sa console; ang pagkakaiba ay karaniwang nangangahulugang may pangalawang connector na naglilingkod sa bersyon.

Ang matagumpay na query mula sa VM sa loob ng VPC ay nagpapatunay na umiiral ang ruta. Hindi nito pinapatunayan na pinili ito ng serbisyo.