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 gateway и firewall-от на базата на податоци мора да го дозволат опсегот доделен на конекторот во VPC, не адресата на вашата канцеларија и не јавната излезна адреса на услугата. Побарајте го тој опсег во конзолата пред да напишете и едно правило.

Уште две места мора да се согласат. Табелата со рути на VPC бара рута до оддалечената мрежа на базата на податоци, а оддалечената страна бара повратна рута за опсегот на конекторот. Ако тунелот користи селектори на сообраќај, потврдете дека опсегот на конекторот е во договорениот опфат. Рута што постои само во насока од оддалечена кон локална е чест пропуст и ги пропушта пинг-овите, но никогаш не завршува TCP ракување.

Тунел што дозволува само VM подмрежа ќе ги отфрли пакетите на конекторот без корисна порака за грешка, поради што истекот на времето на базата на податоци изгледа како проблем со акредитиви.

DNS патува по друга патека

Името на домаќинот на приватната база на податоци мора да се реши во мрежата до која стигнува конекторот, преку Cloud DNS вмрежување или зона за препраќање што VPC може да ја користи. Неговото решавање на вашата работна станица не докажува ништо за распоредената услуга, бидејќи вашиот лаптоп не го користи тој резолвер.

Ако името се реши во јавна адреса од внатрешноста на VPC, само што треба да отстранувате грешки на погрешниот firewall.

URL Fetch не го користи конекторот

Поставката за излез ги опфаќа нормалните излезни сокети на средината за извршување, а наследената услуга URL Fetch не е дел од таа патека. Барањето издадено преку urlfetch го игнорира конекторот што и да вели конфигурацијата. Кога повикот што пропаѓа се наоѓа во постара библиотека што сè уште користи URL Fetch, решението е тој повик да се премести на стандардниот HTTP клиент.

За драјвер на база на податоци ова ретко е проблемот, но тоа е класичната причина зошто една крајна точка работи, а друга не од истата услуга.

Проверете со едно тесно барање

Распоредете, потоа извршете една дозволена операција со базата на податоци од распоредената верзија додека ја набљудувате оддалечената страна. Адресата на изворот што ја запишуваат базата на податоци или VPN gateway-от треба да биде на конекторот. Ако не е, барањето никогаш не влегло во VPC и ниту една конфигурација на тунелот нема да го поправи. Споредете ја со опсегот што го баравте во конзолата; несовпаѓањето обично значи дека вториот конектор ја опслужува верзијата.

Успешно барање од VM во VPC докажува дека рутата постои. Не докажува дека услугата ја избрала.