App Engine можа дасягнуць вашай базы дадзеных праз VPN: што павінна супадаць

Сцвярджэнне, што App Engine Standard не можа дасягнуць прыватнай базы дадзеных праз Cloud VPN, — гэта рэштка папярэдняга пакалення платформы. Экзэмпляры Standard не атрымліваюць адрас, уласцівы VPC, як некаторыя іншыя асяроддзі выканання, але яны могуць адпраўляць выхад праз канэктар Serverless VPC Access, які знаходзіцца ў вашай сетцы. Калі гэты шлях існуе, Cloud VPN і аддалены firewall бачаць трафік канэктара як любую іншую крыніцу. Няўдалым рэдка бывае сам сродак. Гэта адна з трох налад, якія так і не ўзгаднілі.

Адкуль узяўся стары адказ

Да з'яўлення канэктараў практычны адказ сапраўды быў такі: Standard можа мець зносіны толькі з публічнымі канцавымі пунктамі, і каманды пераходзілі на проксі-VM або іншае асяроддзе выканання, каб абысці гэта. Платформа змянілася, а фальклор — не. Мноства парад у інтэрнэце дагэтуль адлюстроўвае эпоху, калі варыянту выхаду не было зусім.

Папраўка вузейшая, чым гучыць. Standard можа дасягнуць прыватнай сеткі, але толькі праз падтрымліваную інтэграцыю выхаду і толькі для тых прызначэнняў, якія гэтая інтэграцыя фактычна захоплівае.

Спачатку абярыце шлях выхаду

Менавіта канэктар, далучаны да сэрвісу, выводзіць яго трафік у VPC. Дакументацыя канэктара пералічвае рэгіянальную перадумову і налады выхаду; канэктар павінен існаваць у рэгіёне сэрвісу і быць даступным для ідэнтычнасці разгортвання.

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

private-ranges-only накіроўвае прыватныя прызначэнні ў VPC і пакідае ўсё астатняе на звычайным шляху інтэрнэту, што звычайна і патрэбна злучэнню з базай дадзеных. all-traffic шырока прапіхвае зыходзячы трафік праз VPC, таму звычайныя інтэрнэт-выклікі таксама наследаваюць пазіцыю NAT і firewall VPC.

Праўка файла лакальна нічога не змяняе, пакуль вы не разгорнеце. Працуючая версія захоўвае канфігурацыю, з якой была створана.

Адрас крыніцы — гэта канэктар, а не ваш ноўтбук

Менавіта тут сыходзіць большая частка часу на адладку. Аддалены VPN-шлюз і firewall базы дадзеных павінны дапусціць выдзелены дыяпазон канэктара унутры VPC, а не адрас вашага офіса і не публічны адрас выхаду сэрвісу. Знайдзіце гэты дыяпазон у кансолі, перш чым пісаць хоць адно правіла.

Яшчэ два месцы павінны ўзгадніцца. Табліца маршрутаў VPC патрабуе маршруту да аддаленай сеткі базы дадзеных, а аддаленаму боку — зваротны маршрут для дыяпазону канэктара. Калі тунель выкарыстоўвае селектары трафіку, пераканайцеся, што дыяпазон канэктара знаходзіцца ў межах узгоджанай вобласці. Маршрут, які існуе толькі ў кірунку ад аддаленага да лакальнага, — частая памылка, і ён прапускае пінгі, але ніколі не завяршае рукапаціск TCP.

Тунель, які дапускае толькі падсетку VM, скідвае пакеты канэктара без карыснага паведамлення пра памылку, і менавіта таму тайм-аўт базы дадзеных выглядае як праблема ўліковых дадзеных.

DNS ідзе іншым шляхам

Імя хоста прыватнай базы дадзеных павінна вырашацца ўнутры сеткі, да якой дасягае канэктар, праз пірынг Cloud DNS або зону перасылкі, якую можа выкарыстоўваць VPC. Вырашэнне яго на вашай працоўнай станцыі нічога не даказвае пра разгорнуты сэрвіс, бо ваш ноўтбук не выкарыстоўвае гэты рэзалвер.

Калі імя вырашаецца ў публічны адрас знутры VPC, вы збіраецеся адладжваць не той firewall.

URL Fetch не выкарыстоўвае канэктар

Налада выхаду пакрывае звычайныя зыходзячыя сокеты асяроддзя выканання, і сэрвіс URL Fetch, які застаўся з мінулага, не ўваходзіць у гэты шлях. Запыт, выдадзены праз urlfetch, ігнаруе канэктар, што б ні казала канфігурацыя. Калі збойны выклік знаходзіцца ў старэйшай бібліятэцы, якая ўсё яшчэ выкарыстоўвае URL Fetch, выпраўленне — перанесці гэты выклік на стандартны HTTP-кліент.

Для драйвера базы дадзеных гэта рэдка бывае праблемай, але гэта класічная прычына, чаму адзін канцавы пункт працуе, а іншы — не з таго ж сэрвісу.

Праверце адным вузкім запытам

Разгарніце, затым выканайце адну дазволеную аперацыю базы дадзеных з разгорнутай версіі, назіраючы за аддаленым бокам. Адрас крыніцы, зафіксаваны базай дадзеных або VPN-шлюзам, павінен быць адрасам канэктара. Калі не, запыт ніколі не трапіў у VPC, і ніякая колькасць налад тунеля гэтага не выправіць. Параўнайце яго з дыяпазонам, які вы знайшлі ў кансолі; несупадзенне звычайна азначае, што версію абслугоўвае другі канэктар.

Паспяховы запыт з VM унутры VPC даказвае, што маршрут існуе. Ён не даказвае, што сэрвіс выбраў менавіта яго.