Cloudflare in versione beta instrada il traffico pubblico verso app private tramite DNS e reti private

Cloudflare ha annunciato una nuova funzionalità che consente alle organizzazioni di indirizzare il traffico internet pubblico verso applicazioni che girano su indirizzi IP privati, non pubblici, senza esporre direttamente tali applicazioni. La funzionalità, chiamata routing pubblico-privato, è ora in beta chiusa per i clienti Enterprise idonei, con disponibilità generale (GA) prevista per il quarto trimestre del 2026. L'approccio utilizza il Domain Name System (DNS), la rubrica di Internet, per instradare le richieste, combinato con la connettività di rete privata di Cloudflare.

Al centro del sistema c'è un cambiamento nel modo in cui la piattaforma proxy di Cloudflare, l'intermediario che si frappone tra gli utenti e i server del cliente, decide dove inviare ogni richiesta. Quando arriva una richiesta per un hostname come app.example.com, Cloudflare interroga la sua API Origin interna. La risposta include metadati con un flag chiamato use_private_routing. Se quel flag è impostato su true, il proxy non tenta di connettersi all'indirizzo IP privato tramite Internet pubblico. Invece, passa la richiesta al livello di rete privata di Cloudflare, che la invia attraverso la connettività di rete privata esistente del cliente. I percorsi supportati includono IPsec, un insieme di protocolli per crittografare il traffico di rete tra siti; GRE, un protocollo di tunneling; Cloudflare Tunnel, un connettore di uscita sicuro; CNI, Cloudflare Network Interconnect; e Cloudflare Mesh.

Lo stesso modello di routing ora si estende oltre il traffico web ordinario. Un'origine non deve più essere un server web; può essere un database TCP, un endpoint di logging UDP o un'API privata chiamata direttamente da Cloudflare Workers, la piattaforma serverless dell'azienda. Spectrum, il proxy di livello 4 di Cloudflare per protocolli non web, ora può essere posto davanti a servizi TCP e UDP che girano su IP privati. Invece di creare un pool di bilanciamento del carico come intermediario, un'applicazione Spectrum può specificare un virtual_network_id direttamente nella sua configurazione di origine. Ad esempio, un servizio SSH (il protocollo di accesso remoto sicuro) può essere definito con un IP privato e un ID di rete virtuale. Cloudflare verifica che l'indirizzo IP corrisponda a una rotta nel tunnel Cloudflare del cliente prima di salvare la configurazione; se non c'è corrispondenza, l'API rifiuta la richiesta. In questa versione iniziale, le origini private di Spectrum sono supportate solo tramite Cloudflare Tunnel, ma il supporto per ulteriori opzioni di connettività di rete privata arriverà in seguito.

Cloudflare Workers VPC chiude il cerchio per il codice che gira su Cloudflare. Un binding, un'impostazione di connessione, dice al runtime di Workers di instradare attraverso lo stesso percorso privato dei record DNS. Di conseguenza, browser, app mobili, Workers e agenti AI possono tutti raggiungere origini private tramite Cloudflare. Per il traffico internet, i record DNS definiscono il routing; per Workers, i binding fanno lo stesso lavoro. Il vantaggio principale è che i servizi rimangono privati: nessun indirizzo IP pubblico, nessun software di connettore e nessun bilanciatore di carico richiesti.

Guardando al futuro, Cloudflare prevede di andare oltre i flussi pubblico-privato per passare al traffico privato-privato: utenti, servizi e agenti AI su reti private che raggiungono in modo sicuro applicazioni su altre reti private, con i servizi applicativi di Cloudflare nel mezzo. L'azienda descrive uno stato finale in cui la stessa infrastruttura Cloudflare protegge il traffico indipendentemente dal fatto che l'utente o l'origine sia pubblica. Ad esempio, un dipendente che usa Cloudflare One Client per accedere a wiki.company.internal riceverebbe le stesse protezioni del firewall per applicazioni web (WAF), limitazione della velocità e gestione dei bot di un cliente che accede a un'API pubblica. Allo stesso modo, un agente AI che consuma un'API interna proprietaria passerebbe attraverso lo stesso stack di sicurezza di un browser, e il traffico da servizio a servizio tra cloud e data center riceverebbe gli stessi controlli del traffico internet, anche quando nessuno dei due endpoint si trova su Internet pubblico.

L'accesso alla beta chiusa è disponibile oggi per i clienti Enterprise idonei. I team interessati dovrebbero contattare il proprio account team Cloudflare per richiedere l'accesso. Una volta abilitato, il processo di configurazione è documentato nella documentazione per sviluppatori di Cloudflare. I clienti avranno bisogno della connettività Cloudflare One tramite una delle opzioni supportate (IPsec, GRE, CNI o Cloudflare Mesh) e dovranno configurare una rotta di ritorno nella loro rete privata per l'intervallo di indirizzi IP di origine di Cloudflare 100.64.0.0/12. Per le organizzazioni che gestiscono i propri domini e applicazioni private, proteggere i record DNS che puntano a quei servizi è importante quanto proteggere il percorso di rete; l'uso di un servizio DNS crittografato come AEU DNS può aiutare a prevenire spoofing DNS e tentativi di dirottamento che potrebbero reindirizzare gli utenti lontano dalla tua applicazione privata.