Come instradare il traffico SaaS verso il VPN corretto del cliente

Una piattaforma SaaS si connette a una dozzina di reti di clienti, e due di questi clienti usano entrambi 10.20.0.10 per il proprio database principale. Un worker che riceve quell’indirizzo in un’attività non ha modo di sapere a quale database si riferisce l’attività, e una tabella di instradamento condivisa lo invierà volentieri al tunnel indicato dal prefisso. La soluzione non sono più tunnel; consiste nel decidere dove entra l’identità del tenant nel percorso e quale modello di isolamento richiede il piano degli indirizzi. Tre condizioni decidono la scelta: se i prefissi dei clienti si sovrappongono, quanto lontano può propagarsi un errore e chi gestisce il connettore.

Due database dei clienti, un indirizzo di destinazione

Un indirizzo IP è una posizione, non un’identità. La richiesta deve portare un tenant verificato dal server, e quel tenant deve selezionare il contesto di rete prima che la destinazione venga risolta.

Quando non accade, il guasto è silenzioso. La connessione riesce, la query viene eseguita e la risposta proviene dal database del cliente sbagliato perché la tabella di instradamento aveva una sola voce per 10.20.0.10. Il DNS peggiora le cose: un nome in cache risolto nel contesto del tenant A può essere riutilizzato da un’attività in esecuzione per il tenant B. Nulla nel pacchetto distingue i due, quindi nessuna logica di nuovo tentativo lo ripara.

Decidete prima il modello di isolamento

Scrivete le tre condizioni prima di confrontare i prodotti. La sovrapposizione decide se uno spazio di indirizzi può essere condiviso; il raggio d’impatto decide se un errore di instradamento è un ticket di supporto o una violazione; la proprietà operativa decide se potete gestire una flotta di connettori per tenant.

Se i prefissi sono distinti e la policy consente un hub controllato, un Transit Gateway con tabelle di instradamento per tenant è fattibile. L’associazione dell’attachment sceglie la tabella di instradamento usata per il traffico che entra da quell’attachment, e la propagazione sceglie quali route compaiono in una tabella. Un attachment di tenant associato solo alla propria tabella e che propaga solo i propri prefissi raggiunge l’hub e nient’altro. È una decisione di instradamento, e resta corretta solo finché nessuno aggiunge una route predefinita alla tabella condivisa.

Se i prefissi si sovrappongono, l’instradamento da solo non può separarli. Serve un contesto di rete distinto per tenant oppure un piano di traduzione che dia allo spazio di ogni cliente un significato inequivocabile.

Che cosa significa davvero l’isolamento di Transit Gateway

Associazione e propagazione sono le due manopole che contano, ed è facile confonderle. L’associazione risponde in quale tabella viene cercato un pacchetto da questo attachment; la propagazione risponde quali tabelle apprendono le route di questo attachment. L’isolamento nasce dal rendere entrambe specifiche del tenant, non dal creare più attachment.

Una configurazione predefinita tutti-con-tutti è comoda e non è isolamento. Tabelle di instradamento separate limitano la connettività, ma non danno due significati a un indirizzo di destinazione invariato dentro lo stesso contesto di instradamento. Se l’applicazione risolve 10.20.0.10 prima di conoscere il tenant, il livello di instradamento ha già perso l’informazione necessaria.

AWS ha aggiunto il 23 ottobre 2026 il NAT 1:1 a livello di attachment per Transit Gateway e Cloud WAN, il che cambia la risposta alla sovrapposizione per gli attachment supportati. La documentazione NAT di Transit Gateway descrive mappature IPv4 statiche, senza stato e a prefisso uguale, con i bit host preservati. Verificate i tipi di attachment supportati e i vincoli regionali prima di progettare su questa base.

Collegate l’attività a un tenant verificato

Ogni attività dovrebbe portare un’identità di tenant verificata dal server, e quell’identità dovrebbe selezionare un record di connessione di proprietà dell’amministratore. Il record indica il contesto di rete approvato, l’indirizzo del servizio, il riferimento alle credenziali e le operazioni consentite. Una richiesta non attendibile non deve mai fornire il proprio identificatore VPN, gateway o destinazione privata, perché un accesso valido non è il permesso di sondare lo spazio di indirizzi di ogni cliente connesso.

In un progetto con connettori isolati, il lavoro del tenant A va a un connettore specifico per A che gira nella VPC di A e può raggiungere solo le risorse approvate di A. Container separati su un solo host non creano quella separazione da soli; gli spazi dei nomi di rete, le route e la policy di uscita devono attuarla. Il connettore ha anche bisogno di credenziali e code con ambito tenant, perché una route privata non limita un segreto condiviso né un elemento di lavoro condiviso. I worker applicativi raggruppati vanno bene purché il contesto di rete e le credenziali siano scelti per tenant, non per host.

I controlli di salute dovrebbero indicare il tenant e la fase: tunnel stabilito, route presente e una richiesta di servizio reale riuscita sono tre segnali diversi. Un conteggio aggregato dei tunnel attivi nasconderà l’unico cliente il cui connettore è rotto.

Provate i percorsi che devono fallire

Eseguite tre test prima del lancio. Un’operazione A consentita deve riuscire, un’operazione B consentita deve riuscire, e un’attività A indirizzata deliberatamente al connettore di B o al suo alias tradotto deve fallire chiusa. Poi interrompete un tunnel e confermate che l’attività fallisce solo per quel tenant, senza ricadere nella sottorete con lo stesso numero di un altro cliente. Va testato anche il ripristino, perché una route obsoleta o una credenziale in cache possono sopravvivere all’interruzione.

L’architettura può essere di worker raggruppati con connettori isolati, o di risorse tenant completamente separate. L’invariante è lo stesso: il contesto tenant verificato seleziona la route e le credenziali, e nessun cambiamento di route concede mai permessi applicativi tra tenant.