Domande frequenti sul gateway VPN

Articolo
03/26/2024

Connessione a reti virtuali

È possibile connettere reti virtuali in diverse aree di Azure?

Sì. Non esiste alcun vincolo di area. Una rete virtuale può connettersi a un'altra rete virtuale nella stessa area o in un'area diversa di Azure.

È possibile connettere reti virtuali in diverse sottoscrizioni?

Sì.

È possibile specificare server DNS privati nella rete virtuale durante la configurazione di un gateway VPN?

Se è stato specificato un server DNS o server quando è stata creata la rete virtuale, Gateway VPN usa i server DNS specificati. Se si specifica un server DNS, verificare che il server DNS possa risolvere i nomi di dominio necessari per Azure.

È possibile connettersi a più siti da una singola rete virtuale?

È possibile connettersi a più siti tramite Windows PowerShell e le API REST di Azure. Vedere la sezione delle domande frequenti relative alla connettività multisito e tra reti virtuali .

Sono previsti costi aggiuntivi per la configurazione di un gateway VPN come attivo/attivo?

No. Tuttavia, i costi per eventuali indirizzi IP pubblici aggiuntivi verranno addebitati di conseguenza. Vedere Prezzi degli indirizzi IP.

Quali sono le opzioni di connessione cross-premise?

Sono supportate le connessioni gateway di rete virtuale cross-premise seguenti:

Da sito a sito: connessione VPN tramite IPsec (IKE v1 e IKE v2). Per questo tipo di connessione è necessario un dispositivo VPN o RRAS. Per altre informazioni, vedere Da sito a sito.
Da punto a sito: connessione VPN tramite SSTP (Secure Socket Tunneling Protocol) o IKE v2. Questa connessione non richiede un dispositivo VPN. Per altre informazioni, vedere Da punto a sito.
Da rete virtuale a rete virtuale: questo tipo di connessione è uguale a una configurazione da sito a sito. La connessione tra reti virtuali è una connessione VPN tramite IPsec (IKE v1 e IKE v2). Non richiede un dispositivo VPN. Per altre informazioni, vedere Da rete virtuale a rete virtuale.
ExpressRoute: ExpressRoute è una connessione privata ad Azure dalla rete WAN, non una connessione VPN tramite Internet pubblico. Per altre informazioni, vedere la Panoramica tecnica relativa a ExpressRoute e le Domande frequenti su ExpressRoute.

Per altre informazioni sulle connessioni Gateway VPN, vedere Informazioni sulle Gateway VPN.

Qual è la differenza tra una connessione da sito a sito e da punto a sito?

Le configurazioni da sito a sito (tunnel VPN IPsec/IKE) si trovano tra la posizione locale e Azure. È quindi possibile connettersi da qualsiasi computer disponibile in locale a qualsiasi macchina virtuale o istanza del ruolo nella rete virtuale, in base alla configurazione scelta per il routing e le autorizzazioni. È un'ottima opzione per una connessione cross-premise sempre disponibile ed è ideale per le configurazioni ibride. Questo tipo di connessione si basa su un dispositivo VPN IPSec (dispositivo hardware o software) che è necessario distribuire in corrispondenza del perimetro della rete. Per creare questo tipo di connessione, è necessario avere un indirizzo IPv4 con connessione esterna.

Le configurazioni da punto a sito (VPN tramite SSTP) consentono di connettersi da un singolo computer da qualsiasi posizione alla rete virtuale. Questo tipo di connessione usa il client VPN incorporato di Windows. Come parte della configurazione da punto a sito, si installa un certificato e un pacchetto di configurazione client VPN, che contiene le impostazioni che consentono al computer di connettersi a qualsiasi macchina virtuale o istanza del ruolo all'interno della rete virtuale. Si tratta di un'ottima opzione quando si desidera connettersi a una rete virtuale ma non ci si trova nella sede locale. È anche una buona opzione quando non si ha accesso all'hardware VPN o a un indirizzo IPv4 esterno, entrambi necessari per una connessione da sito a sito.

È possibile configurare la rete virtuale in modo da usare sia da sito a sito che da punto a sito contemporaneamente, purché si crei la connessione da sito a sito usando un tipo VPN basato su route per il gateway. I tipi di VPN basati su route sono detti gateway dinamici nel modello di distribuzione classica.

Riservatezza

Il servizio VPN archivia o elabora i dati dei clienti?

No.

Gateway di rete virtuale

Un gateway VPN corrisponde a un gateway di rete virtuale?

Un gateway VPN è un tipo di gateway di rete virtuale, che invia traffico crittografato tra la rete virtuale e la posizione locale tramite una connessione pubblica. È possibile usare il gateway VPN anche per inviare il traffico tra reti virtuali. Quando si crea un gateway VPN, si usa il valore 'Vpn' per -GatewayType. Per altre informazioni, Informazioni sulle impostazioni del gateway VPN.

Perché non è possibile specificare tipi di VPN basati su criteri e basati su route?

A partire dal 1° ottobre 2023, non è possibile creare un gateway VPN basato su criteri tramite portale di Azure. Tutti i nuovi gateway VPN verranno creati automaticamente come basati su route. Se si dispone già di un gateway basato su criteri, non è necessario aggiornare il gateway alla route. È possibile usare PowerShell o l'interfaccia della riga di comando per creare i gateway basati su criteri.

In precedenza, gli SKU del gateway meno recenti non supportano IKEv1 per i gateway basati su route. Ora, la maggior parte degli SKU del gateway corrente supporta sia IKEv1 che IKEv2.

Tipo di gateway VPN	SKU del gateway	Versioni di IKE supportate
Gateway basato su criteri	Di base	IKEv1
Gateway basato su route	Di base	IKEv2
Gateway basato su route	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 e IKEv2
Gateway basato su route	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 e IKEv2

È possibile aggiornare il gateway VPN basato su criteri in base alla route?

No. Un tipo di gateway non può essere modificato da basato su criteri a basato su route o da basato su route a basato su criteri. Per modificare un tipo di gateway, è necessario eliminare e ricreare il gateway. Questo processo richiede circa 60 minuti. Quando si crea il nuovo gateway, non è possibile conservare l'indirizzo IP del gateway originale.

Eliminare tutte le connessioni associate al gateway.
Eliminare il gateway usando uno degli articoli seguenti:
Creare un nuovo gateway usando il tipo di gateway desiderato e quindi completare la configurazione VPN. Per i passaggi, vedere l'esercitazione da sito a sito.

È possibile specificare selettori di traffico basati su criteri personalizzati?

Sì, i selettori di traffico possono essere definiti tramite l'attributo trafficSelectorPolicies in una connessione tramite il comando PowerShell New-AzIpsecTrafficSelectorPolicy . Per rendere effettivo il selettore di traffico specificato, verificare che l'opzione Usa selettori di traffico basati su criteri sia abilitata.

I selettori di traffico configurati personalizzati verranno proposti solo quando un gateway VPN di Azure avvia la connessione. Un gateway VPN accetta tutti i selettori di traffico proposti da un gateway remoto (dispositivo VPN locale). Questo comportamento è coerente tra tutte le modalità di connessione (Default, InitiatorOnly e ResponderOnly).

Il valore 'GatewaySubnet' è necessario?

Sì. La subnet del gateway contiene gli indirizzi IP usati dai servizi del gateway di rete virtuale. È necessario creare una subnet del gateway per la rete virtuale per configurare un gateway di rete virtuale. Per poter funzionare correttamente, tutte le subnet del gateway devono essere denominate 'GatewaySubnet'. Non assegnare un nome diverso alla subnet del gateway. Non distribuire VM o altri elementi alla subnet del gateway.

Quando si crea la subnet del gateway, si specifica il numero di indirizzi IP inclusi nella subnet. Gli indirizzi IP inclusi nella subnet del gateway sono allocati al servizio del gateway. Alcune configurazioni necessitano dell'allocazione di più indirizzi IP ai servizi del gateway rispetto ad altre. È consigliabile assicurarsi che la subnet del gateway contenga una quantità di indirizzi IP sufficiente per supportare la crescita futura e per possibili nuove configurazioni aggiuntive per la connessione. Anche se è possibile creare una subnet del gateway con dimensioni pari a /29, è consigliabile crearne una con dimensioni pari a /27 o superiori, ad esempio /27, /26, /25 e così via. Esaminare i requisiti per la configurazione da creare e verificare che la subnet del gateway disponibile rispetti tali requisiti.

È possibile distribuire macchine virtuali o istanze del ruolo alla subnet del gateway?

No.

È possibile ottenere l'indirizzo IP del gateway VPN prima di crearlo?

Le risorse IP pubbliche dello SKU Standard di Azure devono usare un metodo di allocazione statico. Pertanto, si avrà l'indirizzo IP pubblico per il gateway VPN non appena si crea la risorsa IP pubblico SKU Standard che si intende usare per esso.

È possibile richiedere un indirizzo IP pubblico statico per il gateway VPN?

Le risorse dell'indirizzo IP pubblico dello SKU standard usano un metodo di allocazione statico. In futuro, è necessario usare un indirizzo IP pubblico con SKU Standard quando si crea un nuovo gateway VPN. Questo vale per tutti gli SKU del gateway, ad eccezione dello SKU Basic. Lo SKU del gateway Basic supporta attualmente solo gli indirizzi IP pubblici sku Basic. Presto verrà aggiunto il supporto per gli indirizzi IP pubblici dello SKU Standard per gli SKU gateway Basic.

Per i gateway non con ridondanza della zona e non di zona creati in precedenza (SKU del gateway che non dispongono di AZ nel nome), l'assegnazione di indirizzi IP dinamici è supportata, ma viene eliminata gradualmente. Quando si usa un indirizzo IP dinamico, l'indirizzo IP non cambia dopo che è stato assegnato al gateway VPN. L'unica volta che l'indirizzo IP del gateway VPN cambia è quando il gateway viene eliminato e quindi ricreato. L'indirizzo IP pubblico del gateway VPN non cambia quando si ridimensiona, si reimposta o si completano altre operazioni di manutenzione e aggiornamenti interni del gateway VPN.

In che modo il ritiro dello SKU Basic dell'indirizzo IP pubblico influisce sui gateway VPN?

Si sta eseguendo un'azione per garantire il funzionamento continuo dei gateway VPN distribuiti che usano indirizzi IP pubblici SKU Basic. Se si dispone già di gateway VPN con indirizzi IP pubblici SKU Basic, non è necessario eseguire alcuna azione.

Tuttavia, è importante notare che gli indirizzi IP pubblici dello SKU Basic vengono eliminati gradualmente. In futuro, quando si crea un nuovo gateway VPN, è necessario usare l'indirizzo IP pubblico dello SKU Standard. Altre informazioni sul ritiro degli indirizzi IP pubblici sku Basic sono disponibili qui.

Come si ottiene l'autenticazione del tunnel VPN?

Il tunnel VPN di Azure usa chiavi precondivise (PSK) per l'autenticazione. È possibile generare una chiave precondivisa (PSK) quando si crea il tunnel VPN. È possibile modificare il pacchetto PSK generato automaticamente con il cmdlet PowerShell Imposta chiave precondivisa o l'API REST.

È possibile usare l'API di impostazione della chiave precondivisa per configurare la VPN gateway con routing statico basata su criteri?

Sì, è possibile usare l'API di impostazione della chiave precondivisa e il cmdlet di PowerShell per configurare sia le VPN basate su criteri con routing statico sia le VPN basate su route con routing dinamico di Azure.

È possibile usare altre opzioni di autenticazione?

L'uso di chiavi precondivise (PSK) è limitato all'autenticazione.

In che modo è possibile specificare il traffico che può passare attraverso il gateway VPN?

Modello di distribuzione Resource Manager

PowerShell: usare "AddressPrefix" per specificare il traffico per il gateway di rete locale.
portale di Azure: passare al gateway > di rete locale Spazio indirizzi di configurazione>.

Modello di distribuzione classica

portale di Azure: passare alla rete > virtuale classica Connessioni VPN Da > sito a sito Connessioni > VPN Spazio indirizzi del sito locale Nome sito > locale Spazio indirizzi client del sito>.

È possibile usare NAT-T nelle connessioni VPN?

Sì, è supportato l'attraversamento NAT (NAT-T). Azure Gateway VPN NON eseguirà alcuna funzionalità simile a NAT nei pacchetti interni da/verso i tunnel IPsec. In questa configurazione verificare che il dispositivo locale avvii il tunnel IPSec.

È possibile configurare il server VPN in Azure e usarlo per connettersi alla rete locale?

Sì, è possibile distribuire i gateway o i server VPN in Azure da Azure Marketplace o tramite la creazione dei propri router VPN. È necessario configurare route definite dall'utente nella rete virtuale per assicurarsi che il traffico venga instradato correttamente tra le reti locali e le subnet della rete virtuale.

Perché determinate porte sono aperte nel gateway di rete virtuale?

Sono necessari per la comunicazione dell'infrastruttura di Azure. Sono protetti (bloccati) dai certificati di Azure. Senza certificati appropriati, le entità esterne, inclusi i clienti di tali gateway, non saranno in grado di causare alcun effetto su tali endpoint.

Un gateway di rete virtuale è fondamentalmente un dispositivo multihomed con una scheda di interfaccia di rete che si collega alla rete privata del cliente e una scheda di interfaccia di rete con connessione alla rete pubblica. Le entità dell'infrastruttura di Azure non possono accedere alle reti private dei clienti per motivi di conformità, quindi devono usare gli endpoint pubblici per la comunicazione dell'infrastruttura. Gli endpoint pubblici vengono analizzati periodicamente dal controllo di sicurezza di Azure.

È possibile creare un gateway VPN con lo SKU del gateway Basic nel portale?

No. Lo SKU Basic non è disponibile nel portale. È possibile creare un gateway VPN SKU basic usando l'interfaccia della riga di comando di Azure o PowerShell.

Dove è possibile trovare informazioni sui tipi di gateway, i requisiti e la velocità effettiva?

Fai riferimento ai seguenti articoli:

Deprecazione dello SKU per SKU legacy

Gli SKU Standard e High Performance saranno deprecati il 30 settembre 2025. È possibile visualizzare l'annuncio qui. Il team del prodotto renderà disponibile un percorso di migrazione per questi SKU entro il 30 novembre 2024. Per altre informazioni, vedere l'articolo Gateway VPN SKU legacy. In questo momento, non è necessario eseguire alcuna azione.

È possibile creare un nuovo SKU Standard/High Performance dopo l'annuncio di deprecazione il 30 novembre 2023?

No. A partire dal 1° dicembre 2023 non è possibile creare nuovi gateway con SKU Standard o Ad alte prestazioni. È possibile creare nuovi gateway usando VpnGw1 e VpnGw2 per lo stesso prezzo degli SKU Standard e High Performance, elencati rispettivamente nella pagina dei prezzi.

Quanto tempo saranno supportati i gateway esistenti in SKU Standard/High Performance?

Tutti i gateway esistenti che usano SKU Standard o High Performance saranno supportati fino al 30 settembre 2025.

È necessario eseguire la migrazione degli SKU del gateway Standard/High Performance al momento?

No, non è necessaria alcuna azione in questo momento. Sarà possibile eseguire la migrazione degli SKU a partire da dicembre 2024. Verrà inviata la comunicazione con la documentazione dettagliata sui passaggi di migrazione.

Quale SKU è possibile eseguire la migrazione del gateway?

Quando la migrazione dello SKU del gateway diventa disponibile, è possibile eseguire la migrazione degli SKU come segue:

Standard -> VpnGw1
Prestazioni elevate -> VpnGw2

Cosa accade se si vuole eseguire la migrazione a uno SKU AZ?

Non è possibile eseguire la migrazione dello SKU legacy a uno SKU AZ. Si noti tuttavia che tutti i gateway che usano ancora SKU Standard o High Performance dopo il 30 settembre 2025 verranno migrati e aggiornati automaticamente agli SKU seguenti:

Standard -> VpnGw1AZ
Prestazioni elevate -> VpnGw2AZ

È possibile usare questa strategia per eseguire automaticamente la migrazione e l'aggiornamento degli SKU a uno SKU AZ. È quindi possibile ridimensionare lo SKU all'interno della famiglia di SKU, se necessario. Vedere la pagina dei prezzi per i prezzi di AZ SKU. Per informazioni sulla velocità effettiva per SKU, vedere Informazioni sugli SKU del gateway.

Ci saranno differenze di prezzo per i gateway dopo la migrazione?

Se si esegue la migrazione degli SKU entro il 30 settembre 2025, non ci saranno differenze di prezzo. Gli SKU VpnGw1 e VpnGw2 sono offerti rispettivamente allo stesso prezzo degli SKU Standard e High Performance. Se non si esegue la migrazione entro tale data, gli SKU verranno automaticamente migrati e aggiornati agli SKU AZ. In tal caso, esiste una differenza di prezzo.

Ci sarà un impatto sulle prestazioni sui gateway con questa migrazione?

Sì, si ottengono prestazioni migliori con VpnGw1 e VpnGw2. Attualmente, VpnGw1 a 650 Mbps offre un 6,5x e VpnGw2 a 1 Gbps offre un miglioramento delle prestazioni 5 volte allo stesso prezzo dei gateway Standard e High Performance legacy, rispettivamente. Per altre informazioni sulla velocità effettiva dello SKU, vedere Informazioni sugli SKU del gateway.

Cosa accade se non si esegue la migrazione degli SKU entro il 30 settembre 2025?

Tutti i gateway che usano ancora SKU Standard o High Performance verranno migrati automaticamente e aggiornati agli SKU AZ seguenti:

Standard -> VpnGw1AZ
Prestazioni elevate -> VpnGw2AZ

La comunicazione finale verrà inviata prima di avviare la migrazione in qualsiasi gateway.

Anche Gateway VPN SKU Basic viene ritirato?

No, il Gateway VPN SKU Basic è qui per rimanere. È possibile creare un gateway VPN usando lo SKU del gateway Basic tramite PowerShell o l'interfaccia della riga di comando. Attualmente, Gateway VPN SKU del gateway Basic supportano solo la risorsa indirizzo IP pubblico SKU Basic (che si trova in un percorso di ritiro). Si sta lavorando all'aggiunta del supporto allo SKU del gateway Gateway VPN Basic per la risorsa indirizzo IP pubblico SKU Standard.

Connessioni da sito a sito e dispositivi VPN

Quali sono gli aspetti di cui tenere conto nella scelta di un dispositivo VPN?

È stato convalidato un set di dispositivi VPN standard da sito a sito in collaborazione con i fornitori di dispositivi. Per un elenco dei dispositivi VPN sicuramente compatibili, gli esempi o le istruzioni di configurazione corrispondenti e le relative specifiche, vedere l'articolo relativo ai dispositivi VPN. Tutti i dispositivi appartenenti ai gruppi di dispositivi di cui è indicata la compatibilità nota dovrebbero funzionare con Rete virtuale. Per agevolare la configurazione del dispositivo VPN, fare riferimento al collegamento o all'esempio di configurazione del dispositivo corrispondente al gruppo di dispositivi appropriato.

Dove è possibile reperire le impostazioni di configurazione per i dispositivi VPN?

Per scaricare gli script di configurazione del dispositivo VPN:

A seconda del dispositivo VPN in uso, potrebbe essere possibile scaricare uno script di configurazione per il dispositivo VPN. Per altre informazioni, vedere Scaricare gli script di configurazione del dispositivo VPN.

Per altre informazioni sulla configurazione, vedere i collegamenti seguenti:

Per informazioni sui dispositivi VPN compatibili, vedere l'articolo relativo ai dispositivi VPN.
Prima di configurare il dispositivo VPN, verificare eventuali Problemi noti di compatibilità del dispositivo per il dispositivo VPN da usare.
Per collegamenti alle impostazioni di configurazione dei dispositivi, vedere Dispositivi VPN convalidati. I collegamenti alla configurazione del dispositivo vengono forniti nel modo più efficiente possibile. È sempre consigliabile rivolgersi al produttore del dispositivo per le informazioni di configurazione più aggiornate. L'elenco include le versioni testate. Se il sistema operativo in uso non è incluso in tale elenco, è comunque possibile che la versione sia compatibile. Rivolgersi al produttore del dispositivo per verificare la compatibilità della versione del sistema operativo del dispositivo VPN.
Per una panoramica della configurazione di dispositivi VPN, vedere Panoramica delle configurazioni di dispositivi VPN.
Per informazioni sulla modifica degli esempi, vedere Modifica degli esempi di configurazione di dispositivo.
Per i requisiti di crittografia, vedere About cryptographic requirements and Azure VPN gateways (Informazioni sui requisiti di crittografia e i gateway VPN di Azure).
Per informazioni sui parametri IPsec/IKE, vedere Informazioni sui dispositivi VPN e sui parametri IPsec/IKE per connessioni del Gateway VPN da sito a sito. Tale articolo contiene informazioni su versione IKE, gruppo Diffie-Hellman, metodo di autenticazione, algoritmi di crittografia e hash, durata dell'associazione di sicurezza, PFS (Perfect Forward Secrecy) e rilevamento peer inattivo, oltre ad altre informazioni sui parametri necessarie per completare la configurazione.
Per la procedura di configurazione dei criteri IPsec/IKE, vedere Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections (Configurare i criteri IPsec/IKE per connessioni VPN S2S o tra reti virtuali).
Per connettere più dispositivi VPN basati su criteri, vedere Connettere i gateway VPN di Azure a più dispositivi VPN basati su criteri locali usando PowerShell.

Come è possibile modificare gli esempi di configurazione del dispositivo VPN?

Per informazioni sulla modifica degli esempi, vedere Modifica degli esempi di configurazione di dispositivo.

Dove è possibile reperire i parametri IPsec e IKE?

Per informazioni sui parametri IPsec/IKE, vedere Parametri.

Perché il tunnel VPN basato su criteri si arresta quando il traffico è inattivo?

Questo comportamento è previsto per gateway VPN basate su criteri (anche note come routing statico). Quando il traffico sul tunnel è inattivo per più di 5 minuti, il tunnel viene distrutto. Quando il traffico inizia a fluire in entrambe le direzioni, il tunnel viene ristabilito immediatamente.

È possibile usare soluzioni software VPN per connettersi ad Azure?

Sono supportati i server RRAS (Routing e accesso remoto) di Windows Server 2012 per la configurazione cross-premise da sito a sito.

Con il gateway dovrebbero funzionare anche altre soluzioni software VPN, purché siano conformi alle implementazioni di IPSec standard del settore. Per istruzioni sulla configurazione e sull'assistenza, contattare il fornitore del software.

È possibile connettersi a un gateway VPN tramite punto a sito quando si trova in un sito con una connessione da sito a sito attiva?

Sì, ma gli indirizzi IP pubblici del client da punto a sito devono essere diversi dall'indirizzo IP pubblico usato dal dispositivo VPN da sito a sito oppure la connessione da punto a sito non funzionerà. Le connessioni da punto a sito con IKEv2 non possono essere avviate dallo stesso indirizzo IP pubblico in cui è configurata una connessione VPN da sito a sito nello stesso gateway VPN di Azure.

Da punto a sito - Autenticazione del certificato

Questa sezione si applica al modello di distribuzione Resource Manager.

Quanti endpoint client VPN è possibile avere nella configurazione da punto a sito?

Dipende dallo SKU del gateway. Per altre informazioni sul numero di connessioni supportate, vedere SKU del gateway.

Quali sistemi operativi client è possibile usare con point-to-site?

Sono supportati i sistemi operativi client seguenti:

Windows Server 2008 R2 (solo a 64 bit)
Windows 8.1 (a 32 e 64 bit)
Windows Server 2012 (solo a 64 bit)
Windows Server 2012 R2 (solo a 64 bit)
Windows Server 2016 (solo a 64 bit)
Windows Server 2019 (solo a 64 bit)
Windows Server 2022 (solo a 64 bit)
Windows 10
Windows 11
macOS versione 10.11 o successiva
Linux (StrongSwan)
iOS

È possibile attraversare proxy e firewall usando la funzionalità da punto a sito?

Azure supporta tre tipi di opzioni VPN da punto a sito:

SSTP (Secure Socket Tunneling Protocol). SSTP è una soluzione proprietaria Microsoft basata su SSL che può penetrare i firewall perché la porta TCP 443 in uscita usata da SSL viene aperta dalla maggior parte dei firewall.
OpenVPN. OpenVPN è una soluzione basata su SSL che può penetrare i firewall perché la porta TCP 443 in uscita usata da SSL viene aperta dalla maggior parte dei firewall.
VPN IKEv2. IKEv2 VPN è una soluzione VPN IPsec basata su standard che usa le porte UDP in uscita 500 e 4500 e il protocollo IP n. 50. I firewall non aprono sempre queste porte, quindi è possibile che la VPN IKEv2 non sia in grado di attraversare proxy e firewall.

Se si riavvia un computer client configurato per la connessione da punto a sito, la VPN verrà riconnessa automaticamente?

La riconnessione automatica è una funzione del client in uso. Windows supporta la riconnessione automatica configurando la funzionalità client VPN Always On.

Il servizio DDNS è supportato da punto a sito nei client VPN?

DDNS non è attualmente supportato nelle VPN da punto a sito.

È possibile avere configurazioni da sito a sito e da punto a sito coesistere per la stessa rete virtuale?

Sì. Per il modello di distribuzione Resource Manager, è necessario un gateway di tipo VPN RouteBased. Per il modello di distribuzione classica è necessario un gateway dinamico. Non è supportato da punto a sito per gateway VPN di routing statico o gateway VPN basati su criteri.

È possibile configurare un client da punto a sito per la connessione a più gateway di rete virtuale contemporaneamente?

A seconda del software client VPN usato, è possibile connettersi a più gateway Rete virtuale, purché le reti virtuali connesse non abbiano spazi di indirizzi in conflitto tra di essi o la rete da con il client si connette. Anche se il client VPN di Azure supporta molte connessioni VPN, è possibile stabilire una sola connessione alla volta.

È possibile configurare un client da punto a sito per connettersi contemporaneamente a più reti virtuali?

Sì, le connessioni client da punto a sito a un gateway di rete virtuale distribuito in una rete virtuale con peering con altre reti virtuali possono avere accesso ad altre reti virtuali con peering. I client da punto a sito potranno connettersi alle reti virtuali con peering, purché le reti virtuali con peering usino le funzionalità UseRemoteGateway/AllowGatewayTransit. Per altre informazioni, vedere Informazioni sul routing da punto a sito.

Qual è la velocità effettiva prevista tramite connessioni da sito a sito o da punto a sito?

È difficile mantenere esattamente la velocità effettiva tramite i tunnel VPN. IPSec e SSTP sono protocolli VPN con un elevato livello di crittografia. La velocità effettiva è limitata inoltre dalla latenza e dalla larghezza di banda tra le sedi locali e Internet. Per un Gateway VPN con solo connessioni VPN da punto a sito IKEv2, la velocità effettiva totale prevista dipende dallo SKU del gateway. Per altre informazioni sulla velocità effettiva, vedere SKU del gateway.

È possibile usare qualsiasi client VPN software per il punto a sito che supporta SSTP e/o IKEv2?

No. È possibile usare solo il client VPN nativo in Windows per SSTP e il client VPN nativo in Mac per IKEv2. È tuttavia possibile usare il client OpenVPN su tutte le piattaforme per connettersi tramite il protocollo OpenVPN. Fare riferimento all'elenco dei sistemi operativi client supportati.

È possibile modificare il tipo di autenticazione per una connessione da punto a sito?

Sì. Nel portale passare alla pagina di configurazione del gateway VPN -> Da punto a sito. Per Tipo di autenticazione selezionare i tipi di autenticazione da usare. Si noti che dopo aver apportato una modifica a un tipo di autenticazione, i client correnti potrebbero non essere in grado di connettersi fino a quando non viene generato, scaricato e applicato un nuovo profilo di configurazione client VPN a ogni client VPN.

Azure supporta VPN IKEv2 con Windows?

IKEv2 è supportato in Windows 10 e Server 2016. Tuttavia, per usare IKEv2 in determinate versioni del sistema operativo, è necessario installare gli aggiornamenti e impostare un valore della chiave del Registro di sistema in locale. Le versioni del sistema operativo precedenti a Windows 10 non sono supportate e possono usare solo SSTP o OpenVPN® Protocol.

Nota

Le build del sistema operativo Windows più recenti di Windows 10 versione 1709 e Windows Server 2016 versione 1607 non richiedono questi passaggi.

Per preparare Windows 10 o Server 2016 per IKEv2:

Installare l'aggiornamento in base alla versione del sistema operativo:

Versione sistema operativo	Data	Numero/collegamento
Windows Server 2016 Windows 10 versione 1607	17 gennaio 2018	KB4057142
Windows 10 versione 1703	17 gennaio 2018	KB4057144
Windows 10 versione 1709	22 marzo 2018	KB4089848

Impostare il valore della chiave del Registro di sistema. Creare o impostare su 1 la chiave REG_DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload" del Registro di sistema.

Qual è il limite del selettore di traffico IKEv2 per le connessioni da punto a sito?

Windows 10 versione 2004 (rilasciata a settembre 2021) ha aumentato il limite del selettore di traffico a 255. Le versioni di Windows precedenti a questa hanno un limite di selettore di traffico pari a 25.

Il limite dei selettori di traffico in Windows determina il numero massimo di spazi di indirizzi nella rete virtuale e la somma massima delle reti locali, delle connessioni da rete virtuale a rete virtuale e delle reti virtuali con peering connesse al gateway. I client da punto a sito basati su Windows non riusciranno a connettersi tramite IKEv2 se superano questo limite.

Cosa accade quando configurano sia SSTP che IKEv2 per le connessioni VPN P2S?

Quando si configurano sia SSTP che IKEv2 in un ambiente misto (costituito da dispositivi Windows e Mac), il client VPN Windows proverà sempre prima il tunnel IKEv2, ma eseguirà il fallback a SSTP se la connessione IKEv2 non riesce. MacOSX si connetterà solo tramite IKEv2.

Quando nel gateway sono abilitati sia SSTP che IKEv2, il pool di indirizzi da punto a sito verrà suddiviso in modo statico tra i due, quindi ai client che usano protocolli diversi verranno assegnati indirizzi IP da uno dei due intervalli secondari. Si noti che la quantità massima di client SSTP è sempre 128 anche se l'intervallo di indirizzi è maggiore di /24, con conseguente maggiore quantità di indirizzi disponibili per i client IKEv2. Per intervalli più piccoli, il pool sarà ugualmente dimezzato. I selettori di traffico usati dal gateway potrebbero non includere il CIDR dell'intervallo di indirizzi da punto a sito, ma i due CIDR di intervallo secondario.

Oltre a Windows e Mac, quali altre piattaforme supporta Azure per VPN P2S?

supporto tecnico di Azure Windows, Mac e Linux per VPN da sito a sito.

Si dispone già di un Gateway VPN di Azure distribuito. È possibile attivare RADIUS e/o VPN IKEv2 su di esso?

Sì, se lo SKU del gateway usato supporta RADIUS e/o IKEv2, è possibile abilitare queste funzionalità nei gateway già distribuiti usando PowerShell o il portale di Azure. Lo SKU Basic non supporta RADIUS o IKEv2.

Come si rimuove la configurazione di una connessione da punto a sito?

Per rimuovere una configurazione di una connessione da punto a sito nell'interfaccia della riga di comando di Azure e PowerShell, è possibile usare i comandi seguenti:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Interfaccia della riga di comando di Azure

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Che cosa è necessario fare se si verifica una mancata corrispondenza del certificato quando si effettua la connessione tramite autenticazione del certificato?

Deselezionare "Verificare l'identità del server convalidando il certificato" oppure aggiungere il nome di dominio completo del server insieme al certificato durante la creazione manuale di un profilo. Per eseguire questa operazione, è possibile eseguire rasphone da un prompt dei comandi e selezionare il profilo dall'elenco a discesa.

Il bypass della convalida dell'identità del server non è consigliato in generale, ma con l'autenticazione del certificato di Azure lo stesso certificato viene usato per la convalida del server nel protocollo di tunneling VPN (IKEv2/SSTP) e nel protocollo EAP. Poiché il certificato del server e il nome di dominio completo sono già convalidati dal protocollo di tunneling VPN, è ridondante convalidare lo stesso in EAP.

Autenticazione da punto a sito

È possibile usare la CA radice della PKI interna per generare i certificati per la connettività da punto a sito?

Sì. In precedenza, era possibile utilizzare solo certificati radice autofirmati. È ancora possibile caricare 20 certificati radice.

È possibile usare i certificati di Azure Key Vault?

No.

Quali strumenti è possibile usare per creare certificati?

È possibile usare la propria soluzione di infrastruttura a chiave pubblica aziendale (PKI interna), Azure PowerShell, MakeCert e OpenSSL.

Sono disponibili istruzioni per le impostazioni e i parametri dei certificati?

Soluzione PKI aziendale/PKI interna: vedere la procedura per generare i certificati.
Azure PowerShell: per la procedura, vedere l'articolo relativo ad Azure PowerShell.
MakeCert: per la procedura, vedere l'articolo relativo a MakeCert.
OpenSSL:
- Quando si esportano certificati, assicurarsi di convertire il certificato radice in Base64.
- Per il certificato client:
  - Quando si crea la chiave privata, specificare una lunghezza di 4096.
  - Quando si crea il certificato, per il parametro -extensions specificare usr_cert.

Da punto a sito - Autenticazione RADIUS

Questa sezione si applica al modello di distribuzione Resource Manager.

Quanti endpoint client VPN è possibile avere nella configurazione da punto a sito?

Dipende dallo SKU del gateway. Per altre informazioni sul numero di connessioni supportate, vedere SKU del gateway.

Quali sistemi operativi client è possibile usare con point-to-site?

Sono supportati i sistemi operativi client seguenti:

Windows Server 2008 R2 (solo a 64 bit)
Windows 8.1 (a 32 e 64 bit)
Windows Server 2012 (solo a 64 bit)
Windows Server 2012 R2 (solo a 64 bit)
Windows Server 2016 (solo a 64 bit)
Windows Server 2019 (solo a 64 bit)
Windows Server 2022 (solo a 64 bit)
Windows 10
Windows 11
macOS versione 10.11 o successiva
Linux (StrongSwan)
iOS

È possibile attraversare proxy e firewall usando la funzionalità da punto a sito?

Azure supporta tre tipi di opzioni VPN da punto a sito:

SSTP (Secure Socket Tunneling Protocol). SSTP è una soluzione proprietaria Microsoft basata su SSL che può penetrare i firewall perché la porta TCP 443 in uscita usata da SSL viene aperta dalla maggior parte dei firewall.
OpenVPN. OpenVPN è una soluzione basata su SSL che può penetrare i firewall perché la porta TCP 443 in uscita usata da SSL viene aperta dalla maggior parte dei firewall.
VPN IKEv2. IKEv2 VPN è una soluzione VPN IPsec basata su standard che usa le porte UDP in uscita 500 e 4500 e il protocollo IP n. 50. I firewall non aprono sempre queste porte, quindi è possibile che la VPN IKEv2 non sia in grado di attraversare proxy e firewall.

Se si riavvia un computer client configurato per la connessione da punto a sito, la VPN verrà riconnessa automaticamente?

La riconnessione automatica è una funzione del client in uso. Windows supporta la riconnessione automatica configurando la funzionalità client VPN Always On.

Il servizio DDNS è supportato da punto a sito nei client VPN?

DDNS non è attualmente supportato nelle VPN da punto a sito.

È possibile avere configurazioni da sito a sito e da punto a sito coesistere per la stessa rete virtuale?

È possibile configurare un client da punto a sito per la connessione a più gateway di rete virtuale contemporaneamente?

È possibile configurare un client da punto a sito per connettersi contemporaneamente a più reti virtuali?

Qual è la velocità effettiva prevista tramite connessioni da sito a sito o da punto a sito?

È possibile usare qualsiasi client VPN software per il punto a sito che supporta SSTP e/o IKEv2?

È possibile modificare il tipo di autenticazione per una connessione da punto a sito?

Azure supporta VPN IKEv2 con Windows?

Nota

Le build del sistema operativo Windows più recenti di Windows 10 versione 1709 e Windows Server 2016 versione 1607 non richiedono questi passaggi.

Per preparare Windows 10 o Server 2016 per IKEv2:

Installare l'aggiornamento in base alla versione del sistema operativo:

Versione sistema operativo	Data	Numero/collegamento
Windows Server 2016 Windows 10 versione 1607	17 gennaio 2018	KB4057142
Windows 10 versione 1703	17 gennaio 2018	KB4057144
Windows 10 versione 1709	22 marzo 2018	KB4089848

Impostare il valore della chiave del Registro di sistema. Creare o impostare su 1 la chiave REG_DWORD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload" del Registro di sistema.

Qual è il limite del selettore di traffico IKEv2 per le connessioni da punto a sito?

Cosa accade quando configurano sia SSTP che IKEv2 per le connessioni VPN P2S?

Oltre a Windows e Mac, quali altre piattaforme supporta Azure per VPN P2S?

supporto tecnico di Azure Windows, Mac e Linux per VPN da sito a sito.

Si dispone già di un Gateway VPN di Azure distribuito. È possibile attivare RADIUS e/o VPN IKEv2 su di esso?

Come si rimuove la configurazione di una connessione da punto a sito?

Per rimuovere una configurazione di una connessione da punto a sito nell'interfaccia della riga di comando di Azure e PowerShell, è possibile usare i comandi seguenti:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Interfaccia della riga di comando di Azure

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

L'autenticazione RADIUS è supportata in tutti gli SKU del gateway VPN di Azure?

L'autenticazione RADIUS è supportata per tutti gli SKU, ad eccezione dello SKU Basic.

Per gli SKU legacy, l'autenticazione RADIUS è supportata in SKU Standard e a prestazioni elevate. Non è supportato nello SKU del gateway Basic.

L'autenticazione RADIUS è supportata per il modello di distribuzione classica?

No. L'autenticazione RADIUS non è supportata per il modello di distribuzione classica.

Qual è il periodo di timeout per le richieste RADIUS inviate al server RADIUS?

Le richieste RADIUS vengono impostate su timeout dopo 30 secondi. I valori di timeout definiti dall'utente non sono attualmente supportati.

I server RADIUS di terze parti sono supportati?

Sì, i server RADIUS di terze parti sono supportati.

Quali sono i requisiti di connettività per assicurarsi che il gateway di Azure possa raggiungere un server RADIUS locale?

È necessaria una connessione VPN da sito a sito al sito locale, con le route corrette configurate.

Il traffico a un server RADIUS locale (dal gateway VPN di Azure) può essere instradato tramite una connessione ExpressRoute?

No. Può essere instradato solo tramite una connessione da sito a sito.

Il numero di connessioni SSTP supportate con l'autenticazione RADIUS è stato modificato? Qual il numero massimo di connessioni SSTP e IKEv2 supportate?

Non sono state apportate modifiche al numero massimo di connessioni SSTP supportate in un gateway con l'autenticazione RADIUS. Rimane 128 per le connessioni SSTP, ma dipende dallo SKU del gateway per le connessioni IKEv2. Per altre informazioni sul numero di connessioni supportate, vedere SKU del gateway.

Qual è la differenza tra l'autenticazione del certificato usando un server RADIUS e l'uso dell'autenticazione del certificato nativo di Azure (caricando un certificato attendibile in Azure)?

Nell'autenticazione del certificato RADIUS la richiesta di autenticazione viene inoltrata a un server RADIUS che gestisce la convalida effettiva del certificato. Questa opzione è utile per l'integrazione con un'infrastruttura di autenticazione del certificato già disponibile tramite RADIUS.

Quando si usa Azure per l'autenticazione del certificato, il gateway VPN di Azure esegue la convalida del certificato. È necessario caricare la chiave pubblica del certificato nel gateway. È anche possibile specificare l'elenco di certificati revocati a cui non deve essere consentito connettersi.

L'autenticazione RADIUS funziona sia con IKEv2 che con SSTP VPN?

Sì, l'autenticazione RADIUS funziona sia con IKEv2 che con SSTP VPN.

L'autenticazione RADIUS funziona con il client OpenVPN?

L'autenticazione RADIUS è supportata per il protocollo OpenVPN.

Connessioni da rete virtuale a rete virtuale e multisito

Le domande frequenti sulla connessione tra reti virtuali si applicano alle connessioni gateway VPN. Per informazioni sul peering delle reti virtuali, vedere Peering di rete virtuale.

È previsto un addebito per il traffico tra le reti virtuali?

Il traffico da rete virtuale a rete virtuale nella stessa area è gratuito in entrambe le direzioni quando si usa una connessione gateway VPN. Per il traffico in uscita tra reti virtuali in aree diverse vengono applicate le tariffe di trasferimento dati in uscita tra reti virtuali in base alle aree di origine. Per altre informazioni, vedere la pagina Prezzi di Gateway VPN. Se si connettono le reti virtuali tramite peering di reti virtuali e non con il gateway VPN, vedere la pagina Prezzi di Rete virtuale.

Il traffico da rete virtuale a rete virtuale viene trasmesso attraverso Internet?

No. Il traffico da rete virtuale a rete virtuale passa attraverso il backbone di Microsoft Azure, non Internet.

È possibile stabilire una connessione da rete virtuale a rete virtuale tra i tenant di Microsoft Entra?

Sì, le connessioni da rete virtuale a rete virtuale che usano i gateway VPN di Azure funzionano nei tenant di Microsoft Entra.

Il traffico tra reti virtuali è sicuro?

Sì, è protetto con la crittografia IPsec/IKE.

È necessario un dispositivo VPN per connettere le reti virtuali?

No. Per il collegamento di più reti virtuali di Azure non è necessario un dispositivo VPN, a meno che non sia necessaria la connettività cross-premise.

Le reti virtuali devono trovarsi nella stessa area?

No. Le reti virtuali possono essere nelle sottoscrizioni uguale o diverse.

Se le reti virtuali non sono nella stessa sottoscrizione, è necessario che le sottoscrizioni siano associate allo stesso tenant di Active Directory?

No.

È possibile usare la connettività da rete virtuale a rete virtuale per connettere reti virtuali in istanze separate di Azure?

No. La connettività da rete virtuale a rete virtuale supporta la connessione di reti virtuali nella stessa istanza di Azure. Non è ad esempio possibile creare una connessione tra le istanze globali di Azure e le istanze di Azure cinesi, tedesche o del Governo degli Stati Uniti. Per questi scenari, considerare la possibilità di usare una connessione VPN da sito a sito.

È possibile usare la connessione da rete virtuale a rete virtuale insieme alle connessioni multisito?

Sì. La connettività di rete virtuale può essere usata contemporaneamente con VPN multisito,

A quanti siti locali e reti virtuali può connettersi una rete virtuale?

Vedere la tabella Requisiti del gateway.

È possibile usare la connessione da rete virtuale a rete virtuale per connettere macchine virtuali o servizi cloud esterni a una rete virtuale?

No. La connettività da VNet a VNet supporta la connessione di reti virtuali. Non supporta la connessione di macchine virtuali o servizi cloud non inclusi in una rete virtuale.

È possibile estendere un servizio cloud o un endpoint del servizio di bilanciamento del carico tra più reti virtuali?

No. Un servizio cloud o un endpoint del servizio di bilanciamento del carico non può essere esteso tra reti virtuali, anche se sono connesse tra loro.

È possibile usare una VPN di tipo PolicyBased per le connessioni da rete virtuale a rete virtuale o multisito?

No. La connettività tra reti virtuali e multisito richiede la presenza di gateway VPN di Azure con VPN di tipo RouteBased, denominato in precedenza routing dinamico.

È possibile connettere una rete virtuale con un tipo di VPN RouteBased a un'altra rete virtuale con un tipo di VPN PolicyBased?

No, entrambe le reti virtuali DEVONO usare VPN di tipo RouteBased, denominato in precedenza routing dinamico.

Sì. Tutti i tunnel VPN della rete virtuale condividono la larghezza di banda disponibile sul gateway VPN di Azure e i tempi di servizio del gateway VPN dello stesso contratto di servizio in Azure.

Sono supportati i tunnel ridondanti?

I tunnel ridondanti tra una coppia di reti virtuali sono supportati quando un gateway di rete virtuale è configurato come attivo/attivo.

È consentita la sovrapposizione di spazi di indirizzi per configurazioni da rete virtuale a rete virtuale?

No. Gli intervalli di indirizzi IP non possono sovrapporsi.

Possono esistere spazi di indirizzi sovrapposti tra le reti virtuali connesse e i siti locali?

No. Gli intervalli di indirizzi IP non possono sovrapporsi.

Ricerca per categorie abilitare il routing tra la connessione VPN da sito a sito e ExpressRoute?

Se si vuole abilitare il routing tra il ramo connesso a ExpressRoute e il ramo connesso a una connessione VPN da sito a sito, è necessario configurare il server di route di Azure.

È possibile usare un gateway VPN di Azure per il transito del traffico tra i siti locali o verso un'altra rete virtuale?

Modello di distribuzione Resource Manager
Sì. Per altre informazioni, vedere la sezione BGP.

Modello di distribuzione classica
Con il modello di distribuzione classica il transito del traffico attraverso il gateway VPN di Azure è possibile, ma si basa su spazi di indirizzi definiti in modo statico nel file di configurazione di rete. BGP non è ancora supportato con le Rete virtuale di Azure e i gateway VPN usando il modello di distribuzione classica. Senza BGP la definizione manuale degli spazi di indirizzi in transito è soggetta a errori e non è consigliata.

Azure genera la stessa chiave precondivisa IPsec/IKE per tutte le connessioni VPN per una stessa rete virtuale?

No, per impostazione predefinita vengono generate chiavi precondivise diverse per connessioni VPN diverse. Tuttavia, è possibile usare l'API REST o il Set VPN Gateway Key cmdlet di PowerShell per impostare il valore della chiave preferito. La chiave DEVE contenere solo caratteri ASCII stampabili ad eccezione di spazio, trattino (-) o tilde (~).

Si ottiene una maggiore larghezza di banda con più VPN da sito a sito rispetto a una singola rete virtuale?

No, tutti i tunnel VPN, incluse le VPN da punto a sito, condividono lo stesso gateway VPN di Azure e la larghezza di banda disponibile.

È possibile configurare più tunnel tra una rete virtuale e un sito locale usando una VPN multisito?

Sì, ma è necessario configurare BGP in entrambi i tunnel per la stessa località.

Azure Gateway VPN rispetta il percorso AS in sospeso per influenzare le decisioni di routing tra più connessioni ai siti locali?

Sì, il gateway VPN di Azure rispetta il percorso AS in sospeso per prendere decisioni di routing quando BGP è abilitato. Un percorso AS più breve è preferibile nella selezione del percorso BGP.

È possibile usare la proprietà RoutingWeight durante la creazione di una nuova connessione Vpn VirtualNetworkGateway?

No, questa impostazione è riservata per le connessioni gateway ExpressRoute. Se si desidera influenzare le decisioni di routing tra più connessioni, è necessario usare il percorso AS in sospeso.

È possibile usare VPN da punto a sito con la rete virtuale con più tunnel VPN?

Sì, le VPN da punto a sito (P2S) possono essere usate con i gateway VPN che si connettono a più siti locali e ad altre reti virtuali.

È possibile connettere una rete virtuale con VPN IPsec a un circuito ExpressRoute?

Sì, è possibile. Per altre informazioni, vedere Configurare connessioni VPN expressroute e da sito a sito coesistenti.

Criteri IPsec/IKE

I criteri IPsec/IKE personalizzati sono supportati in tutti gli SKU del gateway VPN di Azure?

I criteri IPsec/IKE personalizzati sono supportati in tutti gli SKU di Azure ad eccezione dello SKU Basic.

Quanti criteri è possibile specificare per una connessione?

Per una determinata connessione è possibile specificare una sola combinazione di criteri.

Per una connessione è possibile specificare criteri parziali, ad esempio solo algoritmi IKE, ma non IPsec?

No. È necessario specificare tutti gli algoritmi e i parametri sia per IKE (modalità principale) che per IPsec (modalità rapida). La specifica parziale dei criteri non è consentita.

Quali algoritmi e tipi di attendibilità della chiave sono supportati nei criteri personalizzati?

La tabella seguente elenca gli algoritmi di crittografia supportati e i punti di forza della chiave che è possibile configurare. È necessario selezionare un'opzione per ogni campo.

IPsec/IKEv2	Opzioni
Crittografia IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128
Integrità IKEv2	SHA384, SHA256, SHA1, MD5
Gruppo DH	DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
Crittografia IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None
Integrità IPsec	GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Gruppo PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None
Durata associazione di sicurezza in modalità rapida	(Facoltativo: se non diversamente specificato, vengono usati i valori predefiniti) Secondi (intero; min. 300/valore predefinito di 27000 secondi) Kilobyte (intero; min 1024/valore predefinito di 102400000 KB)
Selettore di traffico	UsePolicyBasedTrafficSelectors ($True/$False; Optional**, $False predefinito, se non diversamente specificato)
Timeout DPD	Secondi (numero intero: min. 9/max. 3600; valore predefinito 45 secondi)

La configurazione del dispositivo VPN locale deve contenere o corrispondere agli algoritmi e ai parametri seguenti specificati nei criteri IPsec/IKE di Azure:
- Algoritmo di crittografia IKE (modalità principale / fase 1)
- Algoritmo di integrità IKE (modalità principale / fase 1)
- Gruppo DH (modalità principale / fase 1)
- Algoritmo di crittografia IPsec (modalità rapida / fase 2)
- Algoritmo di integrità IPsec (modalità rapida / fase 2)
- Gruppo PFS (modalità rapida / fase 2)
- Selettore di traffico, se viene usato UsePolicyBasedTrafficSelectors
- Le durate sa sono solo specifiche locali e non devono corrispondere.
Se GCMAES viene usato come per l'algoritmo di crittografia IPsec, è necessario selezionare lo stesso algoritmo GCMAES e la stessa lunghezza della chiave per l'integrità IPsec; ad esempio, usando GCMAES128 per entrambi.
Nella tabella Algoritmi e chiavi :
- IKE corrisponde alla modalità principale o alla fase 1.
- IPsec corrisponde alla modalità rapida o alla fase 2.
- Il gruppo DH specifica il gruppo Diffie-Hellman usato nella modalità principale o nella fase 1.
- Il gruppo PFS ha specificato il gruppo Diffie-Hellman usato in modalità rapida o fase 2.
La durata della sicurezza della modalità principale IKE è fissa a 28.800 secondi nei gateway VPN di Azure.
'UsePolicyBasedTrafficSelectors' è un parametro facoltativo nella connessione. Se si imposta UsePolicyBasedTrafficSelectors su $True in una connessione, il gateway VPN di Azure verrà configurato per connettersi al firewall VPN basato su criteri in locale. Se si abilita PolicyBasedTrafficSelectors, è necessario verificare che i selettori di traffico corrispondenti siano definiti nel dispositivo VPN con tutte le combinazioni dei prefissi della rete locale (gateway di rete locale) da/verso i prefissi della rete virtuale di Azure, anziché any-to-any. Il gateway VPN di Azure accetta qualsiasi selettore di traffico proposto dal gateway VPN remoto indipendentemente da ciò che è configurato nel gateway VPN di Azure.

Se i prefissi della rete locale sono 10.1.0.0/16 e 10.2.0.0/16 e i prefissi della rete virtuale sono 192.168.0.0/16 e 172.16.0.0/16, ad esempio, è necessario specificare i selettori di traffico seguenti:
- 10.1.0.0/16 <===> 192.168.0.0/16
- 10.1.0.0/16 <===> 172.16.0.0/16
- 10.2.0.0/16 <===> 192.168.0.0/16
- 10.2.0.0/16 <===> 172.16.0.0/16
Per altre informazioni sui selettori di traffico basati su criteri, vedere Connettere più dispositivi VPN basati su criteri locali.
Timeout DPD: il valore predefinito è 45 secondi nei gateway VPN di Azure. Se si imposta il timeout su periodi più brevi, IKE verrà reimpostata in modo più aggressivo, causando la disconnessione della connessione in alcune istanze. Ciò potrebbe non essere utile se le posizioni locali sono più lontane dall'area di Azure in cui risiede il gateway VPN o la condizione di collegamento fisico potrebbe comportare una perdita di pacchetti. La raccomandazione generale consiste nell'impostare il timeout compreso tra 30 e 45 secondi.

Per altre informazioni, vedere Connettere più dispositivi VPN basati su criteri locali.

Quali gruppi Diffie-Hellman sono supportati?

La tabella seguente elenca i gruppi Diffie-Hellman corrispondenti supportati dai criteri personalizzati:

Gruppo Diffie-Hellman	DHGroup	PFSGroup	Lunghezza chiave
1	DHGroup1	PFS1	MODP a 768 bit
2	DHGroup2	PFS2	MODP a 1024 bit
14	DHGroup14 DHGroup2048	PFS2048	MODP a 2048 bit
19	ECP256	ECP256	ECP a 256 bit
20	ECP384	ECP384	ECP a 384 bit
24	DHGroup24	PFS24	MODP a 2048 bit

Per altre informazioni, vedere RFC3526 e RFC5114.

I criteri personalizzati sostituiscono i set di criteri IPsec/IKE predefiniti per i gateway VPN di Azure?

Sì. Quando per una connessione vengono specificati criteri personalizzati, il gateway VPN di Azure userà solo tali criteri per la connessione, sia come iniziatore IKE che come risponditore IKE.

Se si rimuovono i criteri IPsec/IKE personalizzati, la connessione diventa non protetta?

No. La connessione sarà comunque protetta tramite IPsec/IKE. Dopo la rimozione dei criteri personalizzati da una connessione, il gateway VPN di Azure ripristina l'elenco predefinito delle proposte IPsec/IKE e riavvia nuovamente l'handshake IKE con il dispositivo VPN locale.

L'aggiunta o l'aggiornamento di criteri IPsec/IKE determinerà un'interruzione della connessione VPN?

Sì. Potrebbe causare una breve interruzione di alcuni secondi perché il gateway VPN di Azure chiude la connessione esistente e riavvia l'handshake IKE per ristabilire il tunnel IPsec con i nuovi algoritmi di crittografia e i nuovi parametri. Per ridurre al minimo l'interruzione, verificare che il dispositivo VPN locale sia configurato anche con gli algoritmi e i tipi di attendibilità della chiave corrispondenti.

È possibile usare criteri diversi per connessioni diverse?

Sì. I criteri personalizzati vengono applicati in base alla connessione. È possibile creare e applicare criteri IPsec/IKE diversi per connessioni diverse. Si possono anche applicare criteri personalizzati a un sottoinsieme di connessioni. Le connessioni rimanenti usano i set di criteri IPsec/IKE predefiniti di Azure.

È possibile usare criteri personalizzati anche per una connessione da rete virtuale a rete virtuale?

Sì. È possibile applicare criteri personalizzati sia a connessioni cross-premise IPsec che a connessioni da rete virtuale a rete virtuale.

È necessario specificare gli stessi criteri per entrambe le risorse di connessione da rete virtuale a rete virtuale?

Sì. Un tunnel da rete virtuale a rete virtuale è costituito da due risorse di connessione di Azure, una per ogni direzione. Verificare che entrambe le risorse di connessione abbiano gli stessi criteri. In caso contrario, la connessione da rete virtuale a rete virtuale non verrà stabilita.

Qual è il valore predefinito di timeout DPD? È possibile specificare un timeout DPD diverso?

Il timeout DPD predefinito è di 45 secondi. È possibile specificare un valore di timeout DPD diverso per ogni connessione IPsec o da rete virtuale a rete virtuale, da 9 secondi a 3600 secondi.

Nota

Il valore predefinito è 45 secondi nei gateway VPN di Azure. Se si imposta il timeout su periodi più brevi, IKE verrà reimpostata in modo più aggressivo, causando la disconnessione della connessione in alcune istanze. Ciò potrebbe non essere utile se le posizioni locali sono più lontane dall'area di Azure in cui risiede il gateway VPN o quando la condizione del collegamento fisico potrebbe causare una perdita di pacchetti. La raccomandazione generale consiste nell'impostare il timeout compreso tra 30 e 45 secondi.

I criteri IPsec/IKE personalizzati funzionano in una connessione ExpressRoute?

No. I criteri IPsec/IKE funzionano solo in connessioni VPN da sito a sito e da rete virtuale a rete virtuale tramite gateway VPN di Azure.

Come si creano le connessioni con il tipo di protocollo IKEv1 o IKEv2?

Le connessioni IKEv1 possono essere create in tutti gli SKU di tipo VPN RouteBased, ad eccezione dello SKU Basic, dello SKU Standard e di altri SKU legacy. È possibile specificare un tipo di protocollo di connessione IKEv1 o IKEv2 durante la creazione delle connessioni. Se non si specifica un tipo di protocollo di connessione, IKEv2 viene usato come opzione predefinita, se applicabile. Per altre informazioni, vedere la documentazione sui cmdlet di PowerShell. Per i tipi di SKU e il supporto di IKEv1/IKEv2, vedere Connettere gateway a dispositivi VPN basati su criteri.

Il transito tra connessioni IKEv1 e IKEv2 è consentito?

Sì. Il transito tra le connessioni IKEv1 e IKEv2 è supportato.

È possibile avere connessioni IKEv1 da sito a sito per gli SKU Basic di tipo VPN RouteBased?

No. Lo SKU Basic non supporta questa operazione.

È possibile modificare il tipo di protocollo di connessione dopo la creazione della connessione (da IKEv1 a IKEv2 e viceversa)?

No. Dopo aver creato la connessione, non è possibile modificare i protocolli IKEv1/IKEv2. È necessario eliminare la connessione e ricrearne una nuova con il tipo di protocollo desiderato.

Perché la connessione IKEv1 viene riconnessa di frequente?

Se la connessione IKEv1 basata su routing statico o route viene disconnessa a intervalli di routine, è probabile che i gateway VPN non supportino le chiavi sul posto. Quando la modalità Main viene reimpostata, i tunnel IKEv1 si disconnettono e richiedono fino a 5 secondi per riconnettersi. Il valore di timeout della negoziazione in modalità principale determina la frequenza di reimpostazione delle chiavi. Per impedire queste riconnessioni, è possibile passare all'uso di IKEv2, che supporta le chiavi sul posto.

Se la connessione viene riconnessa in momenti casuali, seguire la guida alla risoluzione dei problemi.

Dove è possibile trovare informazioni e passaggi di configurazione?

Per altre informazioni e procedure di configurazione, vedere gli articoli seguenti.

BGP e routing

BGP è supportato in tutti gli SKU del gateway VPN di Azure?

BGP è supportato in tutti gli SKU del gateway VPN ad eccezione dello SKU Basic.

È possibile usare BGP con i gateway VPN di Criteri di Azure?

No, BGP è supportato unicamente nei gateway VPN basati su route.

Quali numeri ASN (Autonomous System Number) è possibile usare?

È possibile usare i propri numeri ASN pubblici o quelli privati sia per le reti locali che per le reti virtuali di Azure. Non è possibile usare gli intervalli riservati da Azure o IANA.

I seguenti numeri ASN sono riservati da Azure o da IANA:

Numeri ASN riservati da Azure:
- ASN pubblici: 8074, 8075, 12076
- ASN privati: 65515, 65517, 65518, 65519, 65520
ASN riservati da IANA:
- 23456, 64496-64511, 65535-65551 e 429496729

Non è possibile specificare questi numeri ASN per connettere i dispositivi VPN locali ai gateway VPN di Azure.

È possibile usare numeri ASN a 32 bit (4 byte)?

Sì, il gateway VPN ora supporta ASN a 32 bit (4 byte). Per configurare l'uso di ASN in formato decimale, usare PowerShell, l'interfaccia della riga di comando di Azure o Azure SDK.

Quali numeri ASN privati è possibile usare?

Gli intervalli utilizzabili di ASN privati sono:

64512-65514 e 65521-65534

Questi ASN non sono riservati per l'uso in IANA o Azure e possono quindi essere assegnati al gateway VPN di Azure.

Quale indirizzo viene usato dal gateway VPN per l'indirizzo IP del peer BGP?

Per impostazione predefinita, il gateway VPN alloca un singolo indirizzo IP dall'intervallo di GatewaySubnet per i gateway VPN di tipo attivo-standby oppure due indirizzi IP per i gateway VPN di tipo attivo-attivo. Questi indirizzi vengono allocati automaticamente durante la creazione del gateway VPN. È possibile ottenere l'indirizzo IP BGP effettivo allocato usando PowerShell o individuarlo nel portale di Azure. In PowerShell usare Get-AzVirtualNetworkGateway e cercare la proprietà bgpPeeringAddress. Nel portale di Azure, nella pagina Configurazione gateway, controllare la proprietà Configura ASN BGP.

Se i router VPN locali usano indirizzi IP APIPA (169.254.x.x) come indirizzi IP BGP, è necessario specificare uno o più indirizzi IP BGP APIPA di Azure nel gateway VPN di Azure. Azure Gateway VPN seleziona gli indirizzi APIPA da usare con il peer BGP APIPA locale specificato nel gateway di rete locale o l'indirizzo IP privato per un peer BGP non APIPA locale. Per altre informazioni, vedere Configurare BGP.

Quali sono i requisiti per gli indirizzi IP dei peer BGP nel dispositivo VPN?

L'indirizzo del peer BGP locale non deve essere uguale all'indirizzo IP pubblico del dispositivo VPN né essere incluso nello spazio indirizzi della rete virtuale del gateway VPN. Usare un indirizzo IP diverso nel dispositivo VPN per il peer BGP. Può essere un indirizzo assegnato all'interfaccia di loopback nel dispositivo, ossia un normale indirizzo IP o un indirizzo APIPA. Se il dispositivo usa un indirizzo APIPA per BGP, è necessario specificare uno o più indirizzi IP BGP APIPA nel gateway VPN di Azure, come descritto in Configurare BGP. Specificare questi indirizzi nel gateway di rete locale corrispondente che rappresenta il percorso.

Cosa occorre specificare come prefissi di indirizzo per il gateway di rete locale quando si usa BGP?

Importante

Si tratta di una modifica rispetto al requisito precedentemente documentato. Se si usa BGP per una connessione, lasciare il campo Spazio indirizzi vuoto per la risorsa gateway di rete locale corrispondente. Il gateway VPN di Azure aggiunge internamente una route host all'indirizzo IP del peer BGP locale tramite il tunnel IPsec. Non aggiungere la route /32 nel campo Spazio indirizzi. È ridondante e se si usa un indirizzo APIPA come indirizzo IP di BGP del dispositivo VPN locale, non è possibile aggiungerlo a questo campo. Se si aggiungono altri prefissi nel campo Spazio indirizzi, verranno aggiunti come route statiche sul gateway VPN di Azure, in aggiunta alle route acquisite tramite BGP.

È possibile usare lo stesso numero ASN sia per le reti VPN locali che per le reti virtuali di Azure?

No, è necessario assegnare ASN diversi alle reti locali e alle reti virtuali di Azure, se vengono connesse insieme tramite BGP. Ai gateway VPN di Azure è assegnato un ASN predefinito 65515, sia che BGP sia abilitato o meno per la connettività cross-premise. È possibile sostituire questo valore predefinito assegnando un ASN diverso durante la creazione del gateway VPN. In alternativa è possibile cambiarlo dopo aver creato il gateway. Sarà necessario assegnare i nomi ASN locali ai gateway di rete locali di Azure corrispondenti.

Quali prefissi di indirizzo vengono segnalati all'utente dai gateway VPN di Azure?

I gateway annunciano le route seguenti ai dispositivi BGP locali:

I prefissi degli indirizzi di rete virtuale.
I prefissi degli indirizzi per ogni gateway di rete locale connesso al gateway VPN di Azure.
Le route ottenute da altre sessioni di peering BGP connesse al gateway VPN di Azure, ad eccezione delle route predefinite o sovrapposte a qualsiasi prefisso di rete virtuale.

Quanti prefissi è possibile annunciare al gateway VPN di Azure?

Il gateway VPN di Azure supporta fino a 4000 prefissi. La sessione BGP viene eliminata se il numero di prefissi supera il limite.

È possibile segnalare la route predefinita (0.0.0.0/0) ai gateway VPN di Azure?

Sì. Si noti che in questo modo tutto il traffico in ingresso nella rete virtuale viene forzato verso il sito locale. Si impedisce inoltre alle VM della rete virtuale di accettare comunicazioni pubbliche provenienti direttamente da Internet, come RDP o SSH da Internet alle VM.

È possibile annunciare gli stessi prefissi della propria rete virtuale?

No, l'annuncio degli stessi prefissi degli indirizzi della rete virtuale verrà bloccato o filtrato da Azure. È tuttavia possibile annunciare un prefisso che rappresenta un superset di quello interno alla rete virtuale.

Ad esempio, se la rete virtuale usa lo spazio di indirizzi 10.0.0.0/16, è possibile annunciare 10.0.0.0/8, ma non 10.0.0.0/16 o 10.0.0.0/24.

È possibile usare BGP con le connessioni tra reti virtuali?

Sì, è possibile usare BGP sia per connessioni cross-premise che per connessioni tra reti virtuali.

È possibile combinare connessioni BGP con connessioni non BGP per i gateway VPN di Azure?

Sì, è possibile combinare connessioni BGP e connessioni non BGP per lo stesso gateway VPN di Azure.

Il gateway VPN di Azure supporta il routing di transito BGP?

Sì, il routing di transito BGP è supportato, con l'eccezione che i gateway VPN di Azure non annunciano le route predefinite ad altri peer BGP. Per abilitare il routing di transito tra più gateway VPN di Azure, è necessario abilitare BGP in tutte le connessioni intermedie tra reti virtuali. Per altre informazioni, vedere About BGP (Informazioni su BGP).

È possibile stabilire più di un tunnel tra il gateway VPN di Azure e la rete locale?

Sì, è possibile stabilire più di un tunnel VPN da sito a sito tra un gateway VPN di Azure e la rete locale. Si noti che tutti questi tunnel verranno conteggiati rispetto al numero totale di tunnel per i gateway VPN di Azure ed è necessario abilitare BGP in tutti.

Ad esempio, se sono presenti due tunnel ridondanti tra il gateway VPN di Azure e una delle reti locali, verranno consumati 2 tunnel della quota totale disponibile per il gateway VPN di Azure.

È possibile stabilire più tunnel tra due reti virtuali di Azure con BGP?

Sì, ma almeno uno dei gateway di rete virtuale deve avere la configurazione attiva/attiva.

È possibile usare BGP per una VPN da sito a sito in una configurazione di coesistenza VPN da sito a sito e Azure ExpressRoute?

Sì.

Cosa è necessario aggiungere al dispositivo VPN locale per la sessione di peering BGP?

Aggiungere una route host dell'indirizzo IP del peer BGP di Azure nel dispositivo VPN. Questa route punta al tunnel VPN da sito a sito IPsec. Ad esempio, se l'indirizzo IP del peer VPN di Azure è 10.12.255.30, è necessario aggiungere una route host per 10.12.255.30 con un'interfaccia per hop successivo dell'interfaccia del tunnel IPsec corrispondente nel dispositivo VPN.

Il gateway di rete virtuale supporta BFD per le connessioni da sito a sito con BGP?

No. Il rilevamento dell'inoltro bidirezionale (BFD) è un protocollo che è possibile usare con BGP per rilevare i tempi di inattività adiacenti più velocemente di quanto sia possibile usando "keepalives" BGP standard. BFD usa timer di sottosecondi progettati per funzionare in ambienti LAN, ma non attraverso la rete Internet pubblica o Wide Area Network.

Per le connessioni tramite Internet pubblico, la presenza di alcuni pacchetti ritardati o anche eliminati non è insolita, di conseguenza l'introduzione di questi timer aggressivi potrebbe aggiungere instabilità che potrebbero causare la conseguente attenuazione delle route da parte di BGP. In alternativa, è possibile configurare il dispositivo locale con timer di durata inferiore all'intervallo di attesa di "keepalive" predefinito di 60 secondi e il timer di attesa di 180 secondi. In questo modo si ottiene un tempo di convergenza più rapido. Tuttavia, i timer al di sotto dell'intervallo "keepalive" predefinito di 60 secondi o al di sotto del timer di blocco predefinito di 180 secondi non sono affidabili. È consigliabile mantenere i timer in corrispondenza o superiore ai valori predefiniti.

I gateway VPN di Azure avviano sessioni di peering BGP o connessioni?

Il gateway avvia le sessioni di peering BGP agli indirizzi IP peer BGP locali specificati nelle risorse del gateway di rete locale usando gli indirizzi IP privati nei gateway VPN. Ciò è indipendentemente dal fatto che gli indirizzi IP BGP locali si trovino nell'intervallo APIPA o normali indirizzi IP privati. Se i dispositivi VPN locali usano indirizzi APIPA come IP BGP, è necessario configurare l'altoparlante BGP per avviare le connessioni.

È possibile configurare il tunneling forzato?

Sì. Vedere Configurare il tunneling forzato.

NAT

NAT è supportato in tutti gli SKU di Azure Gateway VPN?

NAT è supportato in VpnGw2~5 e VpnGw2AZ~5AZ.

È possibile usare NAT nelle connessioni da rete virtuale a rete virtuale o da sito a sito?

No.

Quante regole NAT è possibile usare in un gateway VPN?

È possibile creare fino a 100 regole NAT (regole di ingresso e uscita combinate) in un gateway VPN.

È possibile usare /in un nome di regola NAT?

No. Verrà visualizzato un errore.

NAT viene applicato a tutte le connessioni in un gateway VPN?

NAT viene applicato alle connessioni con regole NAT. Se una connessione non ha una regola NAT, NAT non avrà effetto su tale connessione. Nello stesso gateway VPN è possibile avere alcune connessioni con NAT e altre connessioni senza che NAT funzionino insieme.

Quali tipi di NAT sono supportati nei gateway VPN di Azure?

Sono supportati solo NAT statici 1:1 e NAT dinamico. NAT64 NON è supportato.

NAT funziona nei gateway VPN attivi?

Sì. NAT funziona sia nei gateway VPN attivo-attivo che attivo-standby. Ogni regola NAT viene applicata a una singola istanza del gateway VPN. Nei gateway attivi-attivi creare una regola NAT separata per ogni istanza del gateway tramite il campo "ID configurazione IP".

NAT funziona con le connessioni BGP?

Sì, è possibile usare BGP con NAT. Ecco alcune considerazioni importanti:

Selezionare Abilita traduzione route BGP nella pagina di configurazione delle regole NAT per assicurarsi che le route apprese e le route annunciate vengano convertite in prefissi di indirizzi POST-NAT (Mapping esterni) in base alle regole NAT associate alle connessioni. È necessario assicurarsi che i router BGP locali pubblicizzino i prefissi esatti, come definito nelle regole IngressSNAT.
Se il router VPN locale usa un indirizzo IP normale e non APIPA e si scontra con lo spazio indirizzi della rete virtuale o con altri spazi di rete locali, assicurarsi che la regola IngressSNAT traduca l'indirizzo IP peer BGP in un indirizzo univoco e non sovrapposto e inserisca l'indirizzo POST-NAT nel campo indirizzo IP peer BGP del gateway di rete locale.
NAT non è supportato con gli indirizzi APIPA BGP.

È necessario creare le regole DNAT corrispondenti per la regola SNAT?

No. Una singola regola SNAT definisce la traduzione per entrambe le direzioni di una determinata rete:

Una regola IngressSNAT definisce la conversione degli indirizzi IP di origine che arrivano nel gateway VPN di Azure dalla rete locale. Gestisce anche la conversione degli indirizzi IP di destinazione che escono dalla rete virtuale alla stessa rete locale.
Una regola EgressSNAT definisce la conversione degli indirizzi IP di origine della rete virtuale che lasciano il gateway VPN di Azure alle reti locali. Gestisce anche la conversione degli indirizzi IP di destinazione per i pacchetti che arrivano nella rete virtuale tramite tali connessioni con la regola EgressSNAT.
In entrambi i casi, non sono necessarie regole DNAT .

Cosa fare se la rete virtuale o lo spazio di indirizzi del gateway di rete locale ha due o più prefissi? È possibile applicare NAT a tutti? O solo un subset?

È necessario creare una regola NAT per ogni prefisso necessario nat perché ogni regola NAT può includere un solo prefisso di indirizzo per NAT. Ad esempio, se lo spazio indirizzi del gateway di rete locale è costituito da 10.0.1.0/24 e 10.0.2.0/25, è possibile creare due regole come illustrato di seguito:

Regola di ingressoSNAT 1: Mappa 10.0.1.0/24 a 100.0.1.0/24
Regola di ingressoSNAT 2: Eseguire il mapping da 10.0.2.0/25 a 100.0.2.0/25

Le due regole devono corrispondere alle lunghezze del prefisso dei prefissi degli indirizzi corrispondenti. Lo stesso vale per le regole EgressSNAT per lo spazio degli indirizzi della rete virtuale.

Importante

Se si collega una sola regola alla connessione precedente, l'altro spazio indirizzi non verrà convertito.

Quali intervalli IP è possibile usare per il mapping esterno?

È possibile usare qualsiasi intervallo IP appropriato per il mapping esterno, inclusi gli indirizzi IP pubblici e privati.

È possibile usare regole EgressSNAT diverse per convertire lo spazio indirizzi della rete virtuale in prefissi diversi in reti locali diverse?

Sì, è possibile creare più regole EgressSNAT per lo stesso spazio indirizzi della rete virtuale e applicare le regole EgressSNAT a connessioni diverse.

È possibile usare la stessa regola IngressSNAT in connessioni diverse?

Sì, questo viene in genere usato quando le connessioni si trovano per la stessa rete locale per garantire la ridondanza. Non è possibile usare la stessa regola di ingresso se le connessioni si trovano per reti locali diverse.

Sono necessarie regole di ingresso e uscita per una connessione NAT?

Quando lo spazio degli indirizzi di rete locale si sovrappone allo spazio indirizzi di rete locale si sovrappone allo spazio indirizzi della rete virtuale, è necessario che le regole in ingresso e in uscita si trovino nella stessa connessione. Se lo spazio indirizzi della rete virtuale è univoco tra tutte le reti connesse, non è necessaria la regola EgressSNAT per tali connessioni. È possibile usare le regole di ingresso per evitare sovrapposizioni di indirizzi tra le reti locali.

Cosa si sceglie come "ID configurazione IP"?

"ID configurazione IP" è semplicemente il nome dell'oggetto di configurazione IP che si vuole usare la regola NAT. Con questa impostazione, è sufficiente scegliere quale indirizzo IP pubblico del gateway si applica alla regola NAT. Se non è stato specificato alcun nome personalizzato al momento della creazione del gateway, l'indirizzo IP primario del gateway viene assegnato all'IPconfiguration "default" e l'INDIRIZZO IP secondario viene assegnato all'IPconfiguration "activeActive".

Connettività cross-premise e macchine virtuali

Se la macchina virtuale si trova in una rete virtuale e si dispone di una connessione cross-premise, in che modo è possibile connettersi alla macchina virtuale?

Sono disponibili diverse opzioni. Se RDP è abilitato per la macchina virtuale, è possibile connettersi alla macchina virtuale usando l'indirizzo IP privato. In tal caso, specificare l'indirizzo IP privato e la porta a cui si vuole connettersi, in genere la porta 3389. Sarà necessario configurare la porta sulla macchina virtuale per il traffico.

È possibile connettersi alla macchina virtuale anche usando l'indirizzo IP privato di un'altra macchina virtuale presente nella stessa rete virtuale. Non è possibile usare RDP per la macchina virtuale usando l'indirizzo IP privato se ci si connette da una posizione esterna alla rete virtuale. Ad esempio, se è configurata una rete virtuale da punto a sito e non si stabilisce una connessione dal computer, non è possibile connettersi alla macchina virtuale tramite indirizzo IP privato.

Se la macchina virtuale si trova in una rete virtuale con connettività cross-premise, il traffico dalla macchina virtuale passa tutto attraverso tale connessione?

No. Attraverso il gateway della rete virtuale passerà solo il traffico con un IP di destinazione incluso negli intervalli di indirizzi IP di rete locale specificati per la rete virtuale. Il traffico che ha un indirizzo IP di destinazione nella rete virtuale rimane all'interno della rete virtuale. Il restante traffico verrà inviato alle reti pubbliche tramite il bilanciamento del carico o, se si usa il tunneling forzato, tramite il gateway VPN di Azure.

Come risolvere i problemi di una connessione RDP a una VM

Se si verificano problemi di connessione a una macchina virtuale tramite la connessione VPN, controllare gli elementi seguenti:

Verificare che la connessione VPN sia attiva.
Verificare che venga effettuata la connessione all'indirizzo IP privato per la macchina virtuale.
Se è possibile connettersi alla VM usando l'indirizzo IP privato, ma non il nome del computer, verificare di avere configurato correttamente il valore per DNS. Per altre informazioni sul funzionamento della risoluzione dei nomi per le macchine virtuali, vedere Risoluzione dei nomi per le macchine virtuali.

Quando ci si connette tramite connessione da punto a sito, controllare gli elementi seguenti:

Usare "ipconfig" per controllare l'indirizzo IPv4 assegnato alla scheda Ethernet nel computer da cui ci si connette. Se l'indirizzo IP è compreso nell'intervallo di indirizzi della rete virtuale a cui ci si connette o all'interno dell'intervallo di indirizzi di VPNClientAddressPool, questo viene definito spazio indirizzi sovrapposto. Con questo tipo di sovrapposizione, il traffico di rete non raggiunge Azure e rimane nella rete locale.
Verificare che il pacchetto di configurazione del client VPN sia stato generato dopo che sono stati specificati gli indirizzi IP del server DNS per la rete virtuale. Se gli indirizzi IP del server DNS sono stati aggiornati, generare e installare un nuovo pacchetto di configurazione del client VPN.

Per altre informazioni sulla risoluzione dei problemi di una connessione RDP, vedere Risolvere i problemi delle connessioni Desktop remoto a una macchina virtuale.

Manutenzione del gateway controllata dal cliente

Quali servizi sono inclusi nell'ambito della configurazione di manutenzione dei gateway di rete?

L'ambito Gateway di rete include le risorse del gateway nei servizi di rete. Nell'ambito gateway di rete sono disponibili quattro tipi di risorse:

Gateway di rete virtuale nel servizio ExpressRoute.
Gateway di rete virtuale nel servizio Gateway VPN.
Gateway VPN (da sito a sito) nel servizio rete WAN virtuale.
Gateway ExpressRoute nel servizio rete WAN virtuale.

Quale manutenzione è supportata o non supportata dalla manutenzione controllata dal cliente?

I servizi di Azure passano attraverso aggiornamenti periodici di manutenzione per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Dopo aver configurato una finestra di manutenzione per le risorse, la manutenzione del sistema operativo guest e del servizio viene eseguita durante tale finestra. Gli aggiornamenti dell'host, oltre gli aggiornamenti host (TOR, Power e così via) e gli aggiornamenti critici della sicurezza, non sono coperti dalla manutenzione controllata dal cliente.

È possibile ricevere una notifica avanzata della manutenzione?

Al momento, la notifica avanzata non può essere abilitata per la manutenzione delle risorse del gateway di rete.

È possibile configurare una finestra di manutenzione più breve di cinque ore?

A questo punto, è necessario configurare almeno un intervallo di cinque ore nel fuso orario preferito.

È possibile configurare una finestra di manutenzione diversa dalla pianificazione giornaliera?

In questo momento, è necessario configurare una finestra di manutenzione giornaliera.

In alcuni casi non è possibile controllare determinati aggiornamenti?

La manutenzione controllata dal cliente supporta gli aggiornamenti del sistema operativo guest e del servizio. Questi aggiornamenti riguardano la maggior parte degli elementi di manutenzione che causano problemi per i clienti. Alcuni altri tipi di aggiornamenti, inclusi gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente.

Inoltre, se si verifica un problema di sicurezza con gravità elevata che potrebbe compromettere i clienti, Azure potrebbe dover eseguire l'override del controllo cliente della finestra di manutenzione ed eseguire il push della modifica. Si tratta di rare occorrenze che verrebbero usate solo in casi estremi.

Le risorse della configurazione di manutenzione devono trovarsi nella stessa area della risorsa del gateway?

Sì

Quali SKU del gateway possono essere configurati per l'uso della manutenzione controllata dal cliente?

Tutti gli SKU del gateway (ad eccezione dello SKU Basic per Gateway VPN) possono essere configurati per l'uso della manutenzione controllata dal cliente.

Quanto tempo è necessario per rendere effettivi i criteri di configurazione della manutenzione dopo l'assegnazione alla risorsa gateway?

Potrebbero essere necessarie fino a 24 ore prima che i gateway di rete seguano la pianificazione della manutenzione dopo che i criteri di manutenzione sono associati alla risorsa gateway.

Esistono limitazioni sull'uso della manutenzione controllata dal cliente in base all'indirizzo IP pubblico dello SKU Basic?

Sì. Le risorse del gateway che usano un indirizzo IP pubblico SKU Basic potranno disporre solo degli aggiornamenti del servizio in base alla pianificazione della manutenzione controllata dal cliente. Per questi gateway, la manutenzione del sistema operativo guest non segue la pianificazione di manutenzione controllata dal cliente a causa delle limitazioni dell'infrastruttura.

Come pianificare le finestre di manutenzione quando si usa VPN ed ExpressRoute in uno scenario di coesistenza?

Quando si lavora con VPN ed ExpressRoute in uno scenario di coesistenza o ogni volta che si dispone di risorse che fungono da backup, è consigliabile configurare finestre di manutenzione separate. Questo approccio garantisce che la manutenzione non influisca contemporaneamente sulle risorse di backup.

Ho pianificato una finestra di manutenzione per una data futura per una delle mie risorse. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?

No, le attività di manutenzione non verranno sospese nella risorsa durante il periodo prima della finestra di manutenzione pianificata. Per i giorni non coperti nella pianificazione della manutenzione, la manutenzione continua come di consueto nella risorsa.

Ricerca per categorie altre informazioni sulla manutenzione del gateway controllata dal cliente?

Per altre informazioni, vedere l'articolo Gateway VPN manutenzione del gateway controllato dal cliente.

Passaggi successivi

Per altre informazioni sui gateway VPN, vedere Informazioni sul gateway VPN.
Per altre informazioni sulle impostazioni di configurazione del gateway VPN, vedere Informazioni sulle impostazioni di configurazione del gateway VPN.

"OpenVPN" è un marchio di OpenVPN Inc.