Cloud SQL:n yksityinen IP VPN:n yli: reitti, jota kukaan ei vie

Monet tiimit uskovat, että Cloud SQL:n yksityinen IP toimii vain VPC:n sisältä, ja usko säilyy, koska vika näyttää tietokantaongelmalta. Google dokumentoi pääsyn verkoista, jotka on yhdistetty Cloud VPN:n tai Cloud Interconnectin kautta. Nuo verkot eivät tarvitse erityistä tietokantaominaisuutta, vaan kaksi reittivaihtoa, jotka on helppo jättää puoliksi määritetyiksi. Tunneli nousee, laskentainstanssit vastaavat ja tietokantayhteys aikakatkeaa — juuri se yhdistelmä, joka lähettää ihmiset väärään konsoliin.

Myytti: yksityinen IP tarkoittaa VPC:lle yksityistä

Yksityisten palvelujen käyttö on VPC-peering verkkosi ja Googlen omistaman tuottajaverkon välillä. Palvelulle varattu alue sijaitsee tuottajan puolella, ja instanssin osoite on sen sisällä. Tämän peeringin vuoksi projektisi tietokanta voi sijaita osoitteessa, johon VPC reitittää, vaikka mikään eksplisiittinen aliverkkosi ei sisällä sitä.

Koska se on peering, siihen liittyy myös peering-käyttäytyminen, mukaan lukien osa, jossa mukautetut reitit eivät ylitä automaattisesti.

Myytti: toimiva tunneli kantaa tietokantareitin mukanaan

Kahden alueen on selvittävä matkasta. Ensimmäinen on asiakasetuliite: paikallinen verkkosi on tunnettava Cloud Routerille tietyillä etuliitteillä, koska oletusreitti ei voi tarjota sitä tuontia, jonka tuottajaverkko tarvitsee paluureitille. Toinen on varattu palvelualue, joka ulkopuolen on opittava, jotta sen tietokantaan menevillä paketeilla olisi minne mennä. Ne ovat eri reittejä, joita ylläpidetään eri rajoilla, ja yhden korjaaminen jättää toisen rikki.

Googlen puolella tämä tarkoittaa Export custom routes -asetuksen käyttöönottoa asiaankuuluvissa peering-yhteyksissä ja varatun palvelualueen lisäämistä Cloud Routerin tunnelille ilmoittamiin reitteihin.

Säilytä ilmoitukset, jotka ovat jo olemassa. Palvelualueen lisääminen ei saisi poistaa VPC-reittejä, joita sama BGP-istunto kantaa muulle liikenteelle, ja kokonaan korvattu ilmoitusjoukko on toinen katkos ensimmäisen takana piilossa. Tarkista myös tehokkaat reitit ulkoisesta laitteesta, sillä VPN-yhdyskäytävään tai toiseen aliverkkoon pääseminen todistaa vain siirtokerroksen.

Myytti: Cloud SQL Auth Proxy ratkaisee verkon

The Auth Proxy tarjoaa tuetun todennuksen ja salatun siirron sovelluksesi ja instanssin välillä. Se ei luo reittiä. Isännällä, jolla ei ole polkua yksityisverkkoon, käynnistetty proxy epäonnistuu täsmälleen kuten suora yhteys epäonnistuisi, ja sen lokit ovat vähemmän hyödyllisiä syyn suhteen. Proxyn siirtäminen isännälle, jolla on yhteys, muuttaa sitä, minkä reitin osan täytyy toimia, ja se on todellinen suunnittelupäätös eikä kiertotie.

Se mitä se ei tee, on sallia irrotetun kannettavan päästä vain yksityiseen instanssiin.

Myytti: Private Service Connect noudattaa samoja sääntöjä

Private Service Connect käyttää päätepistettä omassa aliverkossasi ja hallitsemaasi DNS-järjestelyä, joten reitti sinne on tavallinen reitti omistamaasi osoitteeseen. Peering-viennin asetukset eivät koske tuota suunnittelua, ja peering-muutosten kopioiminen PSC-käyttöönottoon lisää riskiä lisäämättä tavoitettavuutta.

Molemmat antavat yksityisen osoitteen; samankaltaisuus päättyy siihen.

Testaa polku oikeassa järjestyksessä

Testaa ulkoisesta asiakkaasta ensin tietokannan TCP-päätepiste. Valmis TCP-kättely tarkoittaa, että reititys, palomuuri ja kuuntelija ovat kaikki paikallaan, ja seuraava testi on sallittu todennettu toiminto. Todennuksen hylkäys on siinä vaiheessa itse asiassa hyvä uutinen, koska se todistaa, että tietokannan kuuntelija vastasi. ICMP-aikakatko ei kerro juuri mitään tietokantapääsystä, koska monet polut pudottavat sen samalla kun välittävät TCP:tä ongelmitta.

Jos asiakasalueesi ovat RFC 1918:n ulkopuolella, käy läpi reitin viennin ja verkon valtuutuksen lisävaatimukset ennen kuin päättelet, ettei suunnittelua tueta.

Kirjaa yhteyden kanssa neljä kohdetta: ulkoinen etuliite, varattu palvelualue, mukana olevat peering-yhteydet ja ilmoittava reititin. Nuo neljä selittävät koko yksityisen polun ja korvaavat tarun, jonka mukaan Cloud SQL joko tarvitsee aina proxyn tai ei ole lainkaan tavoitettavissa VPN:n yli.