Il VPN verso il VPC funziona, ma il servizio gestito va in timeout

Raggiungere un database gestito tramite VPN di solito fallisce per un motivo che nessuno ha scritto nel runbook: il tunnel termina al bordo della tua rete, mentre il servizio non è mai stato dalla tua parte. La tabella delle rotte sembra corretta, il tunnel si dichiara attivo e la connessione va comunque in timeout. Esegui i quattro controlli seguenti in ordine e fermati al primo la cui condizione di successo è falsa, perché ogni controllo successivo presuppone che i precedenti siano stati superati.

Primo controllo: dove vive davvero l'endpoint?

Un gateway VPN unisce due reti di cui controlli l'indirizzamento. Un servizio gestito è esercito dietro la porta d'ingresso del fornitore stesso, e quella porta assume una di tre forme a seconda del prodotto. Se non sai con quale forma hai a che fare, nessuna quantità di lavoro sulle rotte aiuterà, perché il guasto potrebbe non essere affatto un guasto di routing.

La maggior parte dei pomeriggi sprecati nasce dal saltare questa classificazione e andare dritti alla tabella delle rotte. Un servizio ospitato dal fornitore con un endpoint pubblico non è dietro il tuo tunnel qualunque cosa dica il diagramma, e uno collegato al VPC non comparirà mai in una risposta DNS pubblica.

Secondo controllo: un servizio collegato al VPC come ElastiCache

Le cache di quel tipo sono indirizzate dentro il tuo VPC e non hanno alcun listener rivolto a internet. Un VPN client terminato in quello stesso VPC può raggiungerle, ma solo quando tre condizioni coincidono. L'endpoint della cache deve essere associato a sottoreti che il tuo tunnel vede, il suo gruppo di sicurezza deve consentire l'indirizzo da cui arrivano i tuoi client, e il lato client ha bisogno di una rotta che copra le sottoreti della cache.

L'errore comune è supporre che una connessione da qualche parte nelle vicinanze conti. Collegare il VPN a un altro VPC, o affidarsi solo al peering, non estende il gruppo di sicurezza della cache né la tabella delle rotte della sua sottorete ai tuoi client. Quando il tunnel esistente termina altrove, un jump host o un server VPN collocato dentro quel VPC è la solita alternativa. Quell'alternativa è un aggiramento e non un progetto, e andrebbe etichettata come tale nel runbook.

Terzo controllo: un endpoint PaaS con nome pubblico

Azure Database for PostgreSQL presenta un nome server pubblico. Non ti consegna un indirizzo privato da fissare in un file hosts e instradare attraverso un gateway. Gli endpoint di servizio di rete virtuale limitano quali sottoreti possono raggiungere una risorsa; non autorizzano un client locale che arriva tramite VPN.

Ottenere l'accesso privato significa introdurre un endpoint privato o un progetto di collegamento privato, poi aggiungere una zona DNS privata perché il nome pubblico risponda con quell'endpoint invece che con internet. Un VPN combinato con una regola di endpoint di servizio è un'architettura diversa che sembra uguale solo su un diagramma. App Service segue la stessa logica dalla direzione opposta: l'integrazione con VNet consente all'app di effettuare chiamate in uscita verso un VNet e non crea un percorso privato in ingresso dal tuo tunnel. L'accesso privato in ingresso richiede quindi un endpoint privato, un ambiente App Service o un gateway davanti all'app, e quale di questi puoi usare dipende dal piano.

Quarto controllo: prodotti con una propria porta d'ingresso

Firebase Hosting non può essere collegato a un Cloud VPN, perché il livello di hosting è un front end globale e non qualcosa dentro il VPC di un progetto. L'alternativa documentata è costruire da soli il punto d'ingresso controllato, con un'istanza proxy o un bilanciatore di carico sostenuto da un bucket. In ogni caso il sito smette di essere un prodotto di hosting puro e diventa infrastruttura che ora gestisci tu. Quello scambio merita di essere nominato prima che qualcuno prometta che il tunnel lo coprirà.

Private API Gateway sta più vicino al lato dei servizi VPC: un endpoint VPC di tipo interface pubblica un nome host le cui risposte sono indirizzi privati, e il traffico dalla tua sede arriva tramite il tunnel o un'interconnessione dedicata. L'endpoint deve essere associato all'API, e il certificato insieme al nome host devono corrispondere al dominio personalizzato usato da chi chiama.

I tunnel di Google Cloud VPN si legano a indirizzi IP dei peer, non a nomi. L'inoltro DNS si configura separatamente, ed è per questo che un tunnel può essere perfettamente sano mentre le ricerche nella zona privata remota continuano a fallire.

Poi individua il confine

Esegui la stessa connessione da una VM dentro il VPC. Quando lì funziona e fallisce dal client VPN, lo scarto sta tra il percorso del client e l'endpoint del servizio: una rotta, un gruppo di sicurezza, una politica dell'endpoint o un nome. Quando entrambi i tentativi falliscono, nulla in quella rete può raggiungere il servizio, e il VPN non è mai stato l'ostacolo.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Fai la ricerca del nome e il controllo della porta separatamente, perché falliscono per motivi diversi e la coppia ti dice quale metà del percorso è rotta. Un nome che si risolve in un indirizzo pubblico ti sta dicendo che la zona DNS privata non è in gioco.