App Engine може да достигне вашата VPN база данни: какво трябва да съвпада

Твърдението, че App Engine Standard не може да достигне частна база данни през Cloud VPN, е остатък от по-ранно поколение на платформата. Standard инстанциите не получават VPC-адрес, както някои други среди за изпълнение, но могат да изпращат изход през конектор Serverless VPC Access, който живее във вашата мрежа. Щом този път съществува, Cloud VPN и отдалечената защитна стена виждат трафика на конектора като всеки друг източник. Проваля се рядко самата възможност. Това е една от три настройки, които така и не са подравнени.

Откъде идва старият отговор

Преди да има конектори, практичният отговор наистина беше, че 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 и защитната стена на VPC.

Редактирането на файла локално не променя нищо, докато не разгърнете. Работещата версия запазва конфигурацията, с която е създадена.

Адресът на източника е конекторът, а не вашият лаптоп

Тук отива по-голямата част от времето за отстраняване на проблеми. Отдалеченият VPN шлюз и защитната стена на базата данни трябва да допуснат разпределения диапазон на конектора във VPC, а не адреса на офиса ви и не публичния изходен адрес на услугата. Потърсете този диапазон в конзолата, преди да напишете дори едно правило.

Още две места трябва да се съгласуват. Таблицата за маршрутизация на VPC се нуждае от маршрут към отдалечената мрежа на базата данни, а отдалечената страна — от обратен маршрут за диапазона на конектора. Ако тунелът използва селектори на трафик, уверете се, че диапазонът на конектора е в договорения обхват. Маршрут, който съществува само в посока от отдалечената към локалната страна, е чест пропуск и пропуска пингове, без никога да завърши TCP ръкостискане.

Тунел, който допуска само VM подмрежа, ще изхвърля пакетите на конектора без полезна грешка, затова изтичането на времето за базата данни изглежда като проблем с идентификационните данни.

DNS пътува по друг път

Името на частна база данни трябва да се разрешава в мрежата, която конекторът достига, чрез Cloud DNS peering или зона за препращане, която VPC може да използва. Разрешаването му на работната ви станция не доказва нищо за разгърнатата услуга, защото лаптопът ви не използва този резолвер.

Ако името се разрешава до публичен адрес отвътре във VPC, предстои ви да отстранявате проблеми в грешната защитна стена.

URL Fetch не използва конектора

Настройката за изход покрива нормалните изходящи сокети на средата за изпълнение, а наследената услуга URL Fetch не е част от този път. Заявка, издадена през urlfetch, игнорира конектора, каквото и да казва конфигурацията. Когато неуспешното извикване се намира в по-стара библиотека, която още използва URL Fetch, поправката е да преместите това извикване към стандартния HTTP клиент.

За драйвер на база данни това рядко е проблемът, но е класическата причина една крайна точка да работи, а друга — не от същата услуга.

Проверете с една тясна заявка

Разгърнете, след което изпълнете една разрешена операция с базата данни от разгърнатата версия, докато наблюдавате отдалечената страна. Адресът на източника, записан от базата данни или VPN шлюза, трябва да е на конектора. Ако не е, заявката никога не е влязла във VPC и никаква конфигурация на тунела няма да го поправи. Сравнете го с диапазона, който потърсихте в конзолата; несъответствието обикновено означава, че втори конектор обслужва версията.

Успешна заявка от VM във VPC доказва, че маршрутът съществува. Тя не доказва, че услугата го е избрала.