IP privada de Cloud SQL por VPN: a ruta que ninguén exporta

Moitos equipos cren que a IP privada de Cloud SQL só funciona desde dentro da VPC, e a crenza mantense porque o fallo parece un problema de base de datos. Google documenta o acceso desde redes conectadas mediante Cloud VPN ou Cloud Interconnect. Esas redes non necesitan unha función especial de base de datos, senón dous intercambios de rutas fáciles de deixar a medio configurar. O túnel levanta, as instancias de computación responden e a conexión á base de datos caduca, que é exactamente a combinación que manda a xente á consola equivocada.

Mito: IP privada significa privada para a VPC

O acceso a servizos privados é un emparellamento de VPC entre a súa rede e unha rede de produtor propiedade de Google. O rango asignado ao servizo vive no lado do produtor, e o enderezo da instancia está dentro del. Ese emparellamento é a razón pola que unha base de datos do seu proxecto pode ocupar un enderezo ao que a súa VPC encamiña sen que ningunha subrede explícita súa o conteña.

Como é un emparellamento, tamén ten comportamento de emparellamento, incluída a parte na que as rutas personalizadas non cruzan automaticamente.

Mito: un túnel que funciona leva consigo a ruta da base de datos

Dous rangos teñen que sobrevivir á viaxe. O primeiro é o prefixo de cliente: a súa rede local debe ser coñecida polo Cloud Router con prefixos concretos, porque unha ruta por defecto non pode achegar a importación que a rede do produtor necesita para o camiño de volta. O segundo é o rango de servizo asignado, que o lado externo debe aprender para que os seus paquetes cara á base de datos teñan onde ir. Son rutas distintas mantidas en fronteiras distintas, e arranxar unha deixa a outra rota.

No lado de Google, iso significa activar Export custom routes nas conexións de emparellamento pertinentes e engadir o rango de servizo asignado ás rutas anunciadas do Cloud Router para o túnel.

Conserve os anuncios que xa están aí. Engadir o rango de servizo non debe retirar as rutas de VPC que a mesma sesión BGP transporta para outro tráfico, e un conxunto de anuncios substituído por completo é unha segunda caída agochada detrás da primeira. Revise tamén as rutas efectivas no dispositivo externo, porque poder alcanzar a pasarela VPN ou outra subrede só demostra transporte.

Mito: o Cloud SQL Auth Proxy resolve a rede

The Auth Proxy fornece autenticación compatible e transporte cifrado entre a súa aplicación e a instancia. Non crea unha ruta. Un proxy iniciado nun host sen camiño á rede privada fallará igual que fallaría unha conexión directa, e os seus rexistros serán menos útiles sobre o porqué. Mover o proxy a un host que si ten conectividade cambia que treito do camiño ten que funcionar, e iso é unha decisión de deseño real e non unha solución improvisada.

O que non fai é permitir que un portátil desconectado chegue a unha instancia só privada.

Mito: Private Service Connect segue as mesmas regras

Private Service Connect usa un endpoint na súa propia subrede e un arranxo de DNS que vostede controla, así que a ruta cara a el é unha ruta ordinaria a un enderezo que vostede posúe. Os axustes de exportación de emparellamento non se aplican a ese deseño, e copiar cambios de emparellamento nun despregamento de PSC engade risco sen engadir alcance.

Ambos lle dan un enderezo privado; o parecido remata aí.

Probe o camiño na orde correcta

Desde o cliente externo, probe primeiro o endpoint TCP da base de datos. Un aperto de mans TCP completado significa que encamiñamento, cortalumes e oínte están todos no seu sitio, e a seguinte proba é unha operación autenticada permitida. Un rexeitamento de autenticación é nese momento unha boa noticia, porque demostra que un oínte da base de datos respondeu. Un tempo de espera de ICMP non di case nada sobre o acceso á base de datos, porque moitas rutas descártano mentres reenvían TCP sen problema.

Se os seus rangos de cliente están fóra de RFC 1918, revise os requisitos adicionais de exportación de rutas e autorización de rede antes de concluír que o deseño non está soportado.

Anote catro obxectos coa conexión: o prefixo externo, o rango de servizo asignado, as conexións de emparellamento implicadas e o encamiñador que fai o anuncio. Eses catro explican todo o camiño privado e substitúen a lenda de que Cloud SQL ou sempre precisa un proxy ou non se pode alcanzar por VPN en absoluto.