IP privato di Cloud SQL su VPN: la rotta che nessuno esporta

Molti team credono che l'IP privato di Cloud SQL funzioni solo dall'interno della VPC, e la convinzione resiste perché il guasto sembra un problema del database. Google documenta l'accesso dalle reti connesse tramite Cloud VPN o Cloud Interconnect. A quelle reti non serve una funzione speciale del database, ma due scambi di rotte facili da lasciare a metà. Il tunnel sale, le istanze di calcolo rispondono e la connessione al database va in timeout: esattamente la combinazione che manda le persone nella console sbagliata.

Mito: IP privato significa privato per la VPC

L'accesso ai servizi privati è un peering di VPC tra la vostra rete e una rete di produttore di proprietà di Google. L'intervallo assegnato al servizio vive sul lato del produttore, e l'indirizzo dell'istanza è al suo interno. È questo peering che permette a un database del vostro progetto di stare su un indirizzo verso cui la vostra VPC instrada senza che nessuna vostra subnet esplicita lo contenga.

Poiché è un peering, ha anche un comportamento da peering, inclusa la parte in cui le rotte personalizzate non attraversano automaticamente.

Mito: un tunnel funzionante porta con sé la rotta del database

Due intervalli devono sopravvivere al viaggio. Il primo è il prefisso client: la vostra rete locale deve essere nota al Cloud Router con prefissi specifici, perché una rotta predefinita non può fornire l'import che la rete del produttore richiede per il percorso di ritorno. Il secondo è l'intervallo di servizio assegnato, che il lato esterno deve apprendere perché i suoi pacchetti verso il database abbiano dove andare. Sono rotte diverse mantenute su confini diversi, e ripararne una lascia l'altra rotta.

Sul lato Google ciò significa abilitare Export custom routes sulle connessioni di peering interessate e aggiungere l'intervallo di servizio assegnato alle rotte annunciate del Cloud Router per il tunnel.

Conservate gli annunci già presenti. L'aggiunta dell'intervallo di servizio non deve rimuovere le rotte della VPC che la stessa sessione BGP trasporta per altro traffico, e un insieme di annunci sostituito in blocco è un secondo disservizio nascosto dietro il primo. Controllate anche le rotte effettive sul dispositivo esterno, perché riuscire a raggiungere il gateway VPN o un'altra subnet dimostra solo il trasporto.

Mito: il Cloud SQL Auth Proxy risolve la rete

The Auth Proxy fornisce autenticazione supportata e trasporto cifrato tra la vostra applicazione e l'istanza. Non crea una rotta. Un proxy avviato su un host senza percorso verso la rete privata fallirà esattamente come fallirebbe una connessione diretta, e i suoi log saranno meno utili sul perché. Spostare il proxy su un host che ha connettività cambia quale tratto del percorso deve funzionare, e questa è una vera decisione progettuale, non un aggiramento.

Ciò che non fa è permettere a un portatile disconnesso di raggiungere un'istanza solo privata.

Mito: Private Service Connect segue le stesse regole

Private Service Connect usa un endpoint nella vostra subnet e una configurazione DNS che controllate, quindi la rotta verso di esso è una rotta ordinaria verso un indirizzo che possedete. Le impostazioni di export del peering non si applicano a quel progetto, e copiare modifiche di peering in una distribuzione PSC aggiunge rischio senza aggiungere raggiungibilità.

Entrambi vi danno un indirizzo privato; la somiglianza finisce lì.

Provate il percorso nell'ordine giusto

Dal client esterno, provate prima l'endpoint TCP del database. Una stretta di mano TCP completata significa che routing, firewall e listener sono tutti al loro posto, e il test successivo è un'operazione autenticata consentita. Un rifiuto di autenticazione è in quel momento una buona notizia, perché prova che un listener del database ha risposto. Un timeout ICMP non dice quasi nulla sull'accesso al database, perché molti percorsi lo scartano mentre inoltrano TCP senza problemi.

Se i vostri intervalli client sono fuori da RFC 1918, riesaminate i requisiti aggiuntivi di export delle rotte e di autorizzazione di rete prima di concludere che il progetto non è supportato.

Annotate quattro oggetti con la connessione: il prefisso esterno, l'intervallo di servizio assegnato, le connessioni di peering coinvolte e il router che annuncia. Quei quattro spiegano l'intero percorso privato e sostituiscono la leggenda secondo cui Cloud SQL o ha sempre bisogno di un proxy o non è raggiungibile affatto su VPN.