Väite, että App Engine Standard ei voi saavuttaa yksityistä tietokantaa Cloud VPN:n kautta, on peräisin alustan aiemmasta sukupolvesta. Standard-instanssit eivät saa VPC:n natiivia osoitetta kuten eräät muut suoritusympäristöt, mutta ne voivat lähettää lähtevää liikennettä verkossasi sijaitsevan Serverless VPC Access -liittimen kautta. Kun tämä polku on olemassa, Cloud VPN ja etätulimuuri näkevät liittimen liikenteen kuin minkä tahansa muun lähteen. Epäonnistuminen johtuu harvoin itse kyvystä. Kyse on yhdestä kolmesta asetuksesta, joita ei koskaan kohdistettu.

Mistä vanha vastaus tuli

Ennen liittimien olemassaoloa käytännön vastaus oli todella, että Standard pystyi puhumaan vain julkisille päätepisteille, ja tiimit siirtyivät välityspalvelin-VM:ään tai toiseen suoritusympäristöön kiertääkseen sen. Alusta muuttui, kansanviisaus ei. Monet verkkoneuvot heijastavat edelleen aikakautta, jolloin lähtevän liikenteen vaihtoehtoa ei ollut lainkaan.

Korjaus on kapeampi kuin miltä kuulostaa. Standard voi saavuttaa yksityisen verkon, mutta vain tuetun lähtevän liikenteen integraation kautta ja vain kohteisiin, jotka kyseinen integraatio todella tavoittaa.

Valitse ensin lähtevän liikenteen polku

Palveluun liitetty liitin vie sen liikenteen VPC:hen. Liittimen dokumentaatio luettelee alueellisen edellytyksen ja lähtevän liikenteen asetukset; liittimen on oltava palvelun alueella ja käyttöönottavan identiteetin käytettävissä.

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

private-ranges-only lähettää yksityiset kohteet VPC:hen ja jättää kaiken muun normaalille internet-polkulle, mitä tietokantayhteys yleensä tarvitsee. all-traffic työntää lähtevän liikenteen laajasti VPC:n läpi, joten tavalliset internet-kutsut perivät myös VPC:n NAT- ja palomuuriasennon.

Tiedoston muokkaaminen paikallisesti ei muuta mitään ennen käyttöönottoa. Käynnissä oleva versio säilyttää konfiguraation, jolla se luotiin.

Lähdeosoite on liitin, ei kannettava tietokoneesi

Tähän kuluu suurin osa vianetsintäajasta. Etä-VPN-yhdyskäytävän ja tietokannan palomuurin on hyväksyttävä liittimelle varattu alue VPC:n sisällä, ei toimistosi osoitetta eikä palvelun julkista lähtöosoitetta. Etsi tuo alue konsolista ennen kuin kirjoitat yhtäkään sääntöä.

Kahden muunkin paikan on täsmättävä. VPC:n reititystaulu tarvitsee reitin etätietokantaverkkoon, ja etäpuoli tarvitsee paluureitin liittimen alueelle. Jos tunneli käyttää liikenteen valitsimia, varmista, että liittimen alue on neuvotellun laajuuden sisällä. Reitti, joka on olemassa vain suunnasta etä paikalliseen, on yleinen puute, ja se päästää pingit läpi mutta ei koskaan saa TCP-kättelyä valmiiksi.

Tunneli, joka hyväksyy vain VM-aliverkon, pudottaa liittimen paketit ilman hyödyllistä virheilmoitusta, minkä vuoksi tietokannan aikakatkaisu näyttää tunnistetieto-ongelmalta.

DNS kulkee eri polkua

Yksityisen tietokannan isäntänimen on ratkeava verkossa, jonka liitin saavuttaa, Cloud DNS -vertaisverkon tai VPC:n käyttämän edelleenohjausvyöhykkeen kautta. Sen ratkaiseminen työasemallasi ei todista mitään käyttöönotetusta palvelusta, koska kannettavasi ei käytä kyseistä ratkaisijaa.

Jos nimi ratkeaa julkiseksi osoitteeksi VPC:n sisältä, olet juuri selvittämässä väärää palomuuria.

URL Fetch ei käytä liitintä

Lähtevän liikenteen asetus kattaa suoritusympäristön tavalliset lähtevät socketit, eikä peritty URL Fetch -palvelu kuulu tähän polkuun. urlfetchin kautta lähetetty pyyntö jättää liittimen huomiotta riippumatta siitä, mitä konfiguraatio sanoo. Kun epäonnistuva kutsu on vanhemmassa kirjastossa, joka käyttää yhä URL Fetchiä, korjaus on siirtää kutsu tavalliseen HTTP-asiakasohjelmaan.

Tietokanta-ajurille tämä on harvoin ongelma, mutta se on klassinen syy siihen, miksi yksi päätepiste toimii ja toinen ei samasta palvelusta.

Varmista yhdellä kapealla kyselyllä

Ota käyttöön ja suorita sitten yksi sallittu tietokantatoiminto käyttöönotetusta versiosta seuraten etäpuolta. Tietokannan tai VPN-yhdyskäytävän kirjaaman lähdeosoitteen pitäisi olla liittimen. Jos ei ole, pyyntö ei koskaan päässyt VPC:hen, eikä mikään tunnelikonfiguraatio korjaa sitä. Vertaa sitä konsolista hakemaasi alueeseen; poikkeama tarkoittaa yleensä, että toinen liitin palvelee versiota.

Onnistunut kysely VPC:n sisäisestä VM:stä osoittaa, että reitti on olemassa. Se ei osoita, että palvelu valitsi sen.

Aiheeseen liittyvät artikkelit