Usare il collegamento privato nella rete WAN virtuale

Collegamento privato di Azure è una tecnologia che consente di connettere le offerte di piattaforma distribuita come servizio di Azure usando la connettività degli indirizzi IP privati esponendo gli endpoint privati. Con la rete WAN virtuale di Azure è possibile distribuire un endpoint privato in una delle reti virtuali connesse a qualsiasi hub virtuale. Questo collegamento privato fornisce connettività a qualsiasi altra rete virtuale o ramo connesso alla stessa rete WAN virtuale.

Operazioni preliminari

I passaggi descritti in questo articolo presuppongono che sia stata distribuita una rete WAN virtuale con uno o più hub e almeno due reti virtuali connesse alla rete WAN virtuale.

Per creare una nuova rete WAN virtuale e un nuovo hub, attenersi ai passaggi descritti negli articoli seguenti:

• Creare una rete WAN virtuale
• Creare un hub
• Connettere una rete virtuale a un hub

Considerazioni sul routing con collegamento privato nella rete WAN virtuale

La connettività dell'endpoint privato in Azure è con stato. Quando una connessione a un endpoint privato viene stabilita tramite la rete WAN virtuale, il traffico viene instradato attraverso uno o più hop del traffico tramite diversi componenti della rete WAN virtuale, ad esempio router dell'hub virtuale, gateway ExpressRoute, Gateway VPN, Firewall di Azure o appliance virtuale di rete. Il traffico di hop esatto si basa sulle configurazioni di routing della rete WAN virtuale. Dietro le quinte, il livello di rete software-defined di Azure invia tutti i pacchetti correlati a un singolo flusso a 5 tuple a una delle istanze back-end che eseguono la manutenzione di diversi componenti della rete WAN virtuale. Il traffico instradato asimmetricamente (ad esempio, il traffico corrispondente a un singolo flusso di 5 tupla indirizzato a istanze back-end diverse) non è supportato e viene eliminato dalla piattaforma Azure.

Durante gli eventi di manutenzione nell'infrastruttura della rete WAN virtuale, le istanze back-end vengono riavviate una alla volta, il che può causare problemi di connettività intermittenti all'endpoint privato perché l'istanza di manutenzione del flusso non è temporaneamente disponibile. Il problema simile può verificarsi quando il Firewall di Azure o il router dell'hub virtuale aumenta il numero di istanze. Lo stesso flusso di traffico può essere con carico bilanciato in una nuova istanza back-end diversa dall'istanza attualmente in fase di manutenzione del flusso.

Per ridurre l'impatto degli eventi di manutenzione e scalabilità orizzontale sul traffico di collegamento privato o di endpoint privato, prendere in considerazione le procedure consigliate seguenti:

• Configurare il valore di timeout TCP dell'applicazione locale in modo che sia compreso tra 15 e 30 secondi. Un valore di timeout TCP più piccolo consentirà al traffico dell'applicazione di ripristinare più rapidamente gli eventi di manutenzione e scalabilità orizzontale. In alternativa, testare valori di timeout dell'applicazione diversi per determinare un timeout appropriato in base alle esigenze.
• Componenti della rete WAN virtuale con scalabilità preliminare per gestire i picchi di traffico per impedire che si verifichino eventi di scalabilità automatica. Per il router dell'hub virtuale, è possibile impostare le unità di infrastruttura di routing minime nel router hub per impedire il ridimensionamento durante i picchi di traffico.

Infine, se si usa la connettività locale tra Azure e locale tramite VPN o ExpressRoute, assicurarsi che il dispositivo locale sia configurato per usare lo stesso tunnel VPN o lo stesso router Microsoft Enterprise Edge dell'hop successivo per ogni tupla da 5 tuple corrispondente al traffico dell'endpoint privato.

Creare un endpoint di collegamento privato

È possibile creare un endpoint di collegamento privato per molti servizi diversi. In questo esempio si usa il database SQL di Azure. Per altre informazioni su come creare un endpoint privato per un database SQL di Azure, vedere Guida introduttiva: Creare un endpoint privato usando il portale di Azure. L'immagine seguente mostra la configurazione di rete del database SQL di Azure:

Dopo aver creato il database SQL di Azure, è possibile verificare l'indirizzo IP dell'endpoint privato che esplora gli endpoint privati:

Facendo clic sull'endpoint privato creato, verrà visualizzato il relativo indirizzo IP privato e il relativo nome di dominio completo (FQDN). L'endpoint privato deve avere un indirizzo IP nell'intervallo della rete virtuale (10.1.3.0/24):

Verificare la connettività dalla stessa rete virtuale

In questo esempio viene verificata la connettività al database SQL di Azure da una macchina virtuale Linux con gli strumenti MS SQL installati. Il primo passaggio consiste nel verificare che la risoluzione DNS funzioni e che il nome di dominio completo del database SQL di Azure venga risolto in un indirizzo IP privato, nella stessa rete virtuale in cui è stato distribuito l'endpoint privato (10.1.3.0/24):

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Come si può notare nell'output precedente, il nome di dominio completo wantest.database.windows.net viene mappato a wantest.privatelink.database.windows.net, che la zona DNS privata creata lungo l'endpoint privato risolverà nell'indirizzo IP privato 10.1.3.228. Esaminando la zona DNS privata, si verifica che sia presente un record A per l'endpoint privato mappato all'indirizzo IP privato:

Dopo aver verificato la risoluzione DNS corretta, è possibile tentare di connettersi al database:

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.3.75

Come si può notare, viene usata una query SQL speciale che fornisce l'indirizzo IP di origine visualizzato dal client da SQL Server. In questo caso il server vede il client con l'indirizzo IP privato (10.1.3.75), il che significa che il traffico passa dalla rete virtuale direttamente all'endpoint privato.

Impostare le variabili username e password in modo che corrispondano alle credenziali definite nel database SQL di Azure e fare in modo che gli esempi in questa guida funzionino.

Connettersi da una rete virtuale diversa

Ora che la rete virtuale in rete WAN virtuale di Azure ha connettività all'endpoint privato, anche tutte le altre reti virtuali e i rami connessi alla rete WAN virtuale possono accedervi. È necessario fornire la connettività tramite uno dei modelli supportati dalla rete WAN virtuale di Azure, ad esempio lo scenario Any-to-any o lo scenario rete virtuale di Servizi condivisi, per nominarne un paio.

Dopo aver ottenuto la connettività tra la rete virtuale o il ramo e la rete virtuale in cui è stato distribuito l'endpoint privato, è necessario configurare la risoluzione DNS:

• Se ci si connette all'endpoint privato da una rete virtuale, è possibile usare la stessa zona privata creata con il database SQL di Azure.
• Se ci si connette all'endpoint privato da un ramo (VPN da sito a sito, VPN da punto a sito o ExpressRoute), è necessario usare la risoluzione DNS locale.

In questo esempio ci si connette da una rete virtuale diversa. Collegare prima di tutto la zona DNS privata alla nuova rete virtuale in modo che i carichi di lavoro possano risolvere il nome di dominio completo del database SQL di Azure all'indirizzo IP privato. Questa operazione viene eseguita tramite il collegamento della zona DNS privata alla nuova rete virtuale:

Ora qualsiasi macchina virtuale nella rete virtuale collegata dovrebbe risolvere correttamente l'FQDN del database SQL di Azure nell'indirizzo IP privato del collegamento privato:

nslookup wantest.database.windows.net

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
wantest.database.windows.net    canonical name = wantest.privatelink.database.windows.net.
Name:   wantest.privatelink.database.windows.net
Address: 10.1.3.228

Per verificare che la rete virtuale (10.1.1.1.0/24) disponga della connettività alla rete virtuale originale in cui è stato configurato l'endpoint privato (10.1.3.0/24), è possibile verificare la tabella di route effettiva in qualsiasi macchina virtuale nella rete virtuale:

Come si può notare, è presente una route che punta alla rete virtuale 10.1.3.0/24 inserita dai gateway di rete virtuale nella rete WAN virtuale di Azure. Ora è possibile testare la connettività al database:

query="SELECT CONVERT(char(15), CONNECTIONPROPERTY('client_net_address'));"
sqlcmd -S wantest.database.windows.net -U $username -P $password -Q "$query"

10.1.1.75

Con questo esempio è stato illustrato come creare un endpoint privato in una delle reti virtuali collegate a una rete WAN virtuale offre connettività al resto delle reti virtuali e dei rami nella rete WAN virtuale.

Passaggi successivi

Per altre informazioni sulla rete WAN virtuale, vedere le domande frequenti.