Cloud Run і лакальная VPN: налада прамога выхаду VPC

Тунэль Cloud VPN не змяшчае Cloud Run у сетцы. Падключыце сэрвіс да патрэбнай падсеткі, прамаршрутызуйце яго дыяпазон крыніц, затым праверце гэтую рэвізію.

Тунэль працуе, ВМ дасягае лакальнага сервера, а сэрвіс Cloud Run атрымлівае тайм-аўт на тым жа хосце. Гэта звычайная адпраўная кропка для гэтай задачы, і тунэль рэдка бывае прычынай. Рэвізія Cloud Run па змаўчанні не знаходзіцца ў вашай VPC, а калі знаходзіцца, яна выкарыстоўвае ўласныя адрасы крыніц, а не падсетку ВМ, якую вы ўжо прамаршрутызавалі. Runbook ніжэй падключае сэрвіс, маршрутызуе яго фактычны дыяпазон крыніц і затым даказвае шлях ад рэвізіі, якая абслугоўвала запыт. Выконвайце менавіта ў гэтым парадку, бо пропуск першага кроку — гэта прычына, чаму так шмат такіх выпадкаў заканчваюцца зменай VPN, якая нічога не выпраўляе.

Падключыце рэвізію перад адладкай тунэля

Cloud Run падтрымлівае Direct VPC egress, што змяшчае трафік сэрвіса ў падсетку вашай VPC без канэктара Serverless VPC Access. Для існуючага сэрвіса абнаўленне выглядае так:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

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

Выберыце рэжым выхаду, які адпавядае прызначэнню

private-ranges-only накіроўвае пункты прызначэння, якія ён класіфікуе як прыватныя, праз VPC. Гэта не азначае «усё, што дасягальна праз VPN», і гэтая прага ўзнікае, калі лакальны сэрвіс знаходзіцца ў дыяпазоне, які налада так не класіфікуе. Калі пункт прызначэння не ахоплены, all-traffic — гэта іншы дакументаваны рэжым, і ён накіроўвае ўсё праз VPC, уключаючы публічныя залежнасці сэрвіса. Выбірайце свядома і запішыце наступствы ў запіс аб зменах.

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

Маршрутызуйце крыніцу Cloud Run, а не крыніцу ВМ

Direct VPC egress выдзяляе эфемерныя адрасы з выбранай падсеткі, і лакальны бок павінен вяртаць трафік у гэты дыяпазон. Зваротны маршрут або дазвол фаервола, напісаныя для іншай падсеткі ВМ, будуць выглядаць правільна на схеме і не спрацуюць на практыцы. Бярыце CIDR падсеткі з VPC, а не з памяці, затым пацвердзіце, што crypto ACL або табліца маршрутызацыі аддаленага прыстрою ўключае яго.

Пры дынамічнай маршрутызацыі праверце, што Cloud Router фактычна абвяшчае і што VPC імпартуе, уключаючы любую карыстальніцкую палітыку абвяшчэння. Маршрут, які існуе ў кансолі, але не выбраны для гэтага пункта прызначэння, раўназначны адсутнасці маршруту.

Тры ўмовы, якія павінны выконвацца ўсе

Працуючы шлях патрабуе ўсяго наступнага, і кожнае з іх адмаўляе па-свойму:

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

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

Не ўносьце ў спіс дазволаў адзін часовы адрас Cloud Run. Выкарыстоўвайце дыяпазон падсеткі і схему аўтарызацыі, якая адпавядае праграме.

Праверце рэвізію, якая абслугоўвала запыт

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

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

Адкат і чаго гэта не робіць

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

Гэтая схема ахоплівае злучэнні, якія ініцыюе Cloud Run, і іх адказы. Яна не дае лакальнай сетцы адрасны сокет унутры сэрвіса, бо ўваходнае ўздзеянне — гэта рашэнне ingress.

Падобныя артыкулы