Condividi tramite


Domande frequenti sul gateway VPN

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 i server DNS privati nella rete virtuale durante la configurazione di un gateway VPN?

Se è stato specificato uno o più server DNS 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 di Indirizzi IP.

Quali sono le opzioni di connessione cross-premise?

Sono supportate le connessioni del 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 Sockets 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 è analogo alla 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: si tratta di una connessione privata ad Azure dalla rete WAN, non di 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 di Gateway VPN, vedere Informazioni sul gateway VPN.

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

Le configurazioni da sito a sito (tunnel VPN IPsec/IKE) connettono il percorso locale ad 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. Questa opzione è ottimale per una connessione cross-premise sempre disponibile ed è adatta alle 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 accessibile pubblicamente.

Le configurazioni da punto a sito (VPN tramite SSTP) consentono di connettersi da un qualsiasi computer singolo a qualsiasi elemento disponibile nella rete virtuale. Questo tipo di connessione usa il client VPN incorporato di Windows. La configurazione da punto a sito prevede l'installazione di un certificato e di 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. È utile anche quando non si ha accesso all'hardware VPN o a un indirizzo IPv4 accessibile pubblicamente, entrambi necessari per una connessione da sito a sito.

È possibile configurare la rete virtuale in modo da usare sia la connettività da punto a sito che da sito a sito contemporaneamente, purché la connessione da sito a sito venga creata usando un tipo di 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 sarà possibile creare un gateway VPN basato su criteri tramite il 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 impostare il gateway basato su route. È possibile usare PowerShell o l'interfaccia della riga di comando per creare i gateway basati sui criteri.

In precedenza, gli SKU del gateway meno recenti non supportavano 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 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 un gateway VPN basato su criteri trasformandolo in gateway VPN basato su route?

No. Non è possibile modificare il tipo di gateway passando da basato su criteri a basato su route o da basato su route a basato su criteri. Per modificare il 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.

  1. Eliminare qualsiasi connessione associata al gateway.

  2. Eliminare il gateway usando uno degli articoli seguenti:

  3. Creare un nuovo gateway usando il tipo di gateway desiderato e quindi completare la configurazione VPN. Per i passaggi, vedere l'esercitazione relativa alla connessione da sito a sito.

È possibile specificare i 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 New-AzIpsecTrafficSelectorPolicy di PowerShell. Per rendere effettivo il selettore di traffico specificato, assicurarsi che l'opzione Usa i selettori del traffico basato su criteri sia abilitata.

I selettori di traffico configurati in modo personalizzato 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 in 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 riceverà l'indirizzo IP pubblico per il gateway VPN non appena si crea la risorsa IP pubblico dello 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. Andando avanti, è necessario usare un indirizzo IP pubblico con SKU standard quando si usa un nuovo gateway VPN. Questo vale per tutti gli SKU del gateway, ad eccezione dello SKU di base. Lo SKU del gateway di base supporta attualmente solo gli indirizzi IP pubblici con SKU di base. Presto verrà aggiunto il supporto per gli indirizzi IP pubblici con SKU standard per gli SKU del gateway di base.

Per i gateway senza ridondanza della zona e non di zona creati in precedenza (gli SKU del gateway che non hanno AZ nel nome), l'assegnazione di indirizzi IP dinamici è supportata, ma verrà eliminata gradualmente. Quando si usa un indirizzo IP dinamico, l'indirizzo IP non cambia dopo che è stato assegnato al gateway VPN. L'indirizzo IP del gateway VPN cambia solo quando il gateway viene eliminato e ricreato. L'indirizzo IP pubblico del gateway VPN non cambia quando si ridimensiona, si reimposta o si completano altre operazioni interne di manutenzione e aggiornamento del gateway VPN.

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

Microsoft si sta attivando per garantire il funzionamento continuo dei gateway VPN distribuiti che usano indirizzi IP pubblici con SKU di base. Se si dispone già di gateway VPN con indirizzi IP pubblici con SKU di base, non è necessario eseguire alcuna azione.

Tuttavia, è importante notare che gli indirizzi IP pubblici con SKU di base vengono eliminati gradualmente. In futuro, quando si creerà un nuovo gateway VPN, sarà necessario usare un indirizzo IP pubblico con SKU standard. Altri dettagli sul ritiro degli indirizzi IP pubblici con SKU di base 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 la chiave precondivisa generata automaticamente impostando la propria con il cmdlet di PowerShell di impostazione della 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?

Per l'autenticazione possono essere usate solo chiavi precondivise.

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 > Configurazione > Spazio indirizzi.

Modello di distribuzione classica

  • Portale di Azure: passare alla rete virtuale classica > Connessioni VPN > Connessioni VPN da sito a sito > Nome del sito locale > Sito locale > Spazio indirizzi client.

È possibile usare NAT-T nelle connessioni VPN?

Sì, l'attraversamento NAT (NAT-T) è supportato. Gateway VPN di Azure 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 garantire che il traffico venga indirizzato correttamente tra le reti locali e le subnet della rete virtuale.

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

Sono necessarie per la comunicazione dell'infrastruttura di Azure. Sono protette (bloccate) dai certificati di Azure. Senza certificati appropriati, le entità esterne, compresi i clienti di questi gateway, non potranno 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 utilizzare le reti private del cliente per motivi di conformità, pertanto devono utilizzare 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 di base nel portale?

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

Dove è possibile trovare altre 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 con prestazioni elevate 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 SKU legacy di Gateway VPN. In questo momento, non è necessario eseguire alcuna azione.

È possibile creare un nuovo SKU standard/con prestazioni elevate 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 con prestazioni elevate. È possibile creare nuovi gateway usando VpnGw1 e VpnGw2 allo stesso prezzo degli SKU standard e con prestazioni elevate, elencati rispettivamente nella pagina dei prezzi.

Per quanto tempo saranno supportati i gateway esistenti negli SKU standard/con prestazioni elevate?

Tutti i gateway esistenti che usano SKU standard o con prestazioni elevate saranno supportati fino al 30 settembre 2025.

È necessario eseguire la migrazione degli SKU del gateway standard/con prestazioni elevate al momento?

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

A quale SKU è possibile eseguire la migrazione del gateway?

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

  • Standard -> VpnGw1
  • Con prestazioni elevate -> VpnGw2

Cosa fare 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 con prestazioni elevate dopo il 30 settembre 2025 verranno migrati e aggiornati automaticamente agli SKU seguenti:

  • Standard -> VpnGw1AZ
  • Con 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 dello SKU AZ. 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 allo stesso prezzo degli SKU standard e con prestazioni elevate, rispettivamente. Se non si esegue la migrazione entro tale data, gli SKU verranno automaticamente migrati e aggiornati agli SKU AZ. In tal caso, c'è 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 miglioramento delle prestazioni di 6,5 volte e VpnGw2 a 1 Gbps lo offre di 5 volte allo stesso prezzo dei gateway standard e con prestazioni elevate 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 gli SKU standard o con prestazioni elevate verranno migrati automaticamente e aggiornati agli SKU AZ seguenti:

  • Standard -> VpnGw1AZ
  • Con prestazioni elevate -> VpnGw2AZ

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

Anche lo SKU di base di Gateway VPN viene ritirato?

No, lo SKU di base di Gateway VPN rimarrà invariato. È possibile creare un gateway VPN usando lo SKU del gateway di base tramite PowerShell o l'interfaccia della riga di comando. Attualmente, gli SKU del gateway di base di Gateway VPN supportano solo la risorsa dell'indirizzo IP pubblico dello SKU di base (che verrà presto ritirata). Microsoft si sta impegnando per aggiungere il supporto allo SKU del gateway di base di Gateway VPN per la risorsa dell'indirizzo IP pubblico dello 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 da sito a sito standard 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:

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 attraverso il tunnel è inattivo per più di 5 minuti, il tunnel viene arrestato. Quando il traffico inizia a scorrere in una delle due direzioni, il tunnel viene ripristinato immediatamente.

È possibile usare soluzioni software VPN per connettersi ad Azure?

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

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 una connessione da punto a sito quando ci 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 dagli indirizzi IP pubblici usati dal dispositivo VPN da sito a sito altrimenti 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 del client VPN è possibile includere nella configurazione da punto 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 la connettività da punto a sito?

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 64 bit)
  • Windows 10
  • Windows 11
  • macOS versione 10.11 o successiva
  • Linux (StrongSwan)
  • iOS

È possibile attraversare proxy e firewall con 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. La VPN IKEv2 è una soluzione VPN IPsec basata sugli standard che usa le porte UDP 500 e 4500 in uscita e il protocollo IP numero 50. Non sempre queste porte vengono aperte dai firewall ed esiste quindi la possibilità che la VPN IKEv2 non riesca ad attraversare proxy e firewall.

Se si riavvia un computer client configurato per la funzionalità 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.

La funzionalità da punto a sito supporta DDNS nei client VPN?

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

È possibile la coesistenza di configurazioni da sito a sito e da punto a sito 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. La configurazione da punto a sito non è supportata per gateway VPN con routing statico o PolicyBased.

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

A seconda del software client VPN usato, potrebbe essere possibile connettersi a più gateway di rete virtuale purché nelle reti virtuali a cui si è connessi non siano presenti spazi di indirizzi in conflitto tra loro o con la rete da cui si connette il client. 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 dei 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 sono in grado di 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.

Che velocità effettiva è possibile prevedere usando 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 che ha solo connessioni VPN da punto a sito IKEv2, la velocità effettiva totale che è possibile prevedere dipende dallo SKU del gateway. Per altre informazioni sulla velocità effettiva, vedere SKU del gateway.

È possibile usare qualsiasi client VPN del software per la connettività da 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. Vedere l'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 Gateway VPN - > Configurazione da punto a sito. Per Tipo di autenticazione selezionare i tipi di autenticazione che si desidera usare. 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 del client VPN a ogni client VPN.

Quando è necessario generare un nuovo pacchetto di configurazione del profilo del client VPN?

Quando si apportano modifiche alle impostazioni di configurazione del gateway VPN da punto a sito, ad esempio se si aggiunge un tipo di tunnel o si modifica un tipo di autenticazione, è necessario generare un nuovo pacchetto di configurazione del profilo per il client VPN. Il nuovo pacchetto include le impostazioni aggiornate necessarie ai client VPN per connettersi correttamente al gateway da punto a sito. Dopo aver generato il pacchetto, usare le impostazioni contenute nei file per aggiornare i client VPN.

Azure supporta VPN IKEv2 con Windows?

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

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:

  1. 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
  2. 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.

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

Il limite dei selettori di traffico per OpenVPN è di 1000 route.

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 ad accedere al 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. Il numero massimo di client SSTP è sempre 128, anche se l'intervallo di indirizzi è maggiore di /24, cosa che determina un numero maggiore di indirizzi disponibili per i client IKEv2. Per intervalli più piccoli, il pool è 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?

Per le VPN da punto a sito Azure supporta Windows, Mac e Linux.

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 di base 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 "Verifica l'identità del server mediante convalida del certificato" o aggiungere il nome di dominio completo del server insieme al certificato quando si crea un profilo manualmente. Per eseguire questa operazione, è possibile eseguire rasphone da un prompt dei comandi e selezionare il profilo dall'elenco a discesa.

Ignorare la convalida dell'identità del server non è consigliabile 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 convalidarli nuovamente 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 del client VPN è possibile includere nella configurazione da punto 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 la connettività da punto a sito?

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 64 bit)
  • Windows 10
  • Windows 11
  • macOS versione 10.11 o successiva
  • Linux (StrongSwan)
  • iOS

È possibile attraversare proxy e firewall con 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. La VPN IKEv2 è una soluzione VPN IPsec basata sugli standard che usa le porte UDP 500 e 4500 in uscita e il protocollo IP numero 50. Non sempre queste porte vengono aperte dai firewall ed esiste quindi la possibilità che la VPN IKEv2 non riesca ad attraversare proxy e firewall.

Se si riavvia un computer client configurato per la funzionalità 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.

La funzionalità da punto a sito supporta DDNS nei client VPN?

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

È possibile la coesistenza di configurazioni da sito a sito e da punto a sito 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. La configurazione da punto a sito non è supportata per gateway VPN con routing statico o PolicyBased.

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

A seconda del software client VPN usato, potrebbe essere possibile connettersi a più gateway di rete virtuale purché nelle reti virtuali a cui si è connessi non siano presenti spazi di indirizzi in conflitto tra loro o con la rete da cui si connette il client. 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 dei 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 sono in grado di 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.

Che velocità effettiva è possibile prevedere usando 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 che ha solo connessioni VPN da punto a sito IKEv2, la velocità effettiva totale che è possibile prevedere dipende dallo SKU del gateway. Per altre informazioni sulla velocità effettiva, vedere SKU del gateway.

È possibile usare qualsiasi client VPN del software per la connettività da 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. Vedere l'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 Gateway VPN - > Configurazione da punto a sito. Per Tipo di autenticazione selezionare i tipi di autenticazione che si desidera usare. 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 del client VPN a ogni client VPN.

Quando è necessario generare un nuovo pacchetto di configurazione del profilo del client VPN?

Quando si apportano modifiche alle impostazioni di configurazione del gateway VPN da punto a sito, ad esempio se si aggiunge un tipo di tunnel o si modifica un tipo di autenticazione, è necessario generare un nuovo pacchetto di configurazione del profilo per il client VPN. Il nuovo pacchetto include le impostazioni aggiornate necessarie ai client VPN per connettersi correttamente al gateway da punto a sito. Dopo aver generato il pacchetto, usare le impostazioni contenute nei file per aggiornare i client VPN.

Azure supporta VPN IKEv2 con Windows?

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

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:

  1. 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
  2. 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.

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

Il limite dei selettori di traffico per OpenVPN è di 1000 route.

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 ad accedere al 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. Il numero massimo di client SSTP è sempre 128, anche se l'intervallo di indirizzi è maggiore di /24, cosa che determina un numero maggiore di indirizzi disponibili per i client IKEv2. Per intervalli più piccoli, il pool è 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?

Per le VPN da punto a sito Azure supporta Windows, Mac e Linux.

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 di base 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"

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 di base.

Per gli SKU legacy, l'autenticazione RADIUS è supportata negli SKU standard e con prestazioni elevate. Non è supportata nello SKU del gateway di base.

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 per raggiugere il 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?

Il numero massimo di connessioni SSTP supportate in un gateway con l'autenticazione RADIUS non è stato modificato. 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 eseguire l'autenticazione del certificato usando un server RADIUS o usando l'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 supporta l'integrazione del server dei criteri di rete (NPS) per l'autorizzazione a più fattori (MFA)?

Se l'autenticazione a più fattori è basata su testo (SMS, codice di verifica dell'app per dispositivi mobili e così via) e richiede all'utente di immettere un codice o un testo nell'interfaccia utente del client VPN, l'autenticazione non riesce e questo non è uno scenario supportato. Vedere Integrare l'autenticazione RADIUS del gateway VPN di Azure con il server NPS per l'autenticazione a più fattori

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?

Per il protocollo OpenVPN l'autenticazione RADIUS è supportata.

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 tenant di Microsoft Entra?

Sì, le connessioni da rete virtuale a rete virtuale che usano i gateway VPN di Azure passano attraverso i 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.

I tunnel VPN condividono la larghezza di banda?

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.

Come si abilita il routing tra la connessione VPN da sito a sito ed 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 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. Il protocollo BGP non è ancora supportato con le reti virtuali di Azure e i gateway VPN tramite 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 Set VPN Gateway Key o il cmdlet di PowerShell per impostare il valore di chiave che si preferisce. 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 che per 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à.

Il gateway VPN di Azure rispetta l'anteposizione del percorso AS per influenzare le decisioni di routing tra più connessioni ai siti locali?

Sì, il gateway VPN di Azure rispetta l'anteposizione del percorso AS 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 alle connessioni al gateway ExpressRoute. Se si desidera influenzare le decisioni di routing tra più connessioni, è necessario usare il percorso AS anteposto.

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

Sì, è possibile usare le VPN da punto a sito 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 coesistenti ExpressRoute e da sito a sito.

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). Non è consentito specificare criteri parziali.

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

La tabella seguente riporta l'elenco degli algoritmi di crittografia e dei tipi di attendibilità 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 (intero; valore minimo 9/valore massino 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
    • La durata delle associazioni di sicurezza è una specifica locale. Non è necessaria la corrispondenza.
  • Se GCMAES viene usato per l'algoritmo di crittografia IPsec, è necessario selezionare lo stesso algoritmo GCMAES e la stessa lunghezza della chiave per l'integrità IPsec, ad esempio, GCMAES128 per entrambi.

  • Nella tabella Algoritmi e chiavi:

    • IKE corrisponde alla modalità principale o alla fase 1.
    • IPsec corrisponde alla modalità rapida o fase 2.
    • Gruppo DH specifica il gruppo Diffie-Hellman usato nella modalità principale o fase 1.
    • Gruppo PFS specifica il gruppo Diffie-Hellman usato nella modalità rapida o fase 2.
  • Nei gateway VPN di Azure la durata dell'associazione di sicurezza IKE in modalità principale è fissata a 28.800 secondi.

  • "UsePolicyBasedTrafficSelectors" è un parametro facoltativo per la connessione. Impostando UsePolicyBasedTrafficSelectors su $True per una connessione, si configura il gateway VPN di Azure per la connessione al firewall VPN locale basato su criteri. 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à reimpostato in modo più aggressivo, causando un'apparente disconnessione in alcuni casi. 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 riscontrare una perdita di pacchetti. In generale, è consigliabile impostare il timeout da 30 ai 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 di Diffie-Hellman corrispondenti supportati dal criterio personalizzato:

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 tra 9 e 3600 secondi.

Nota

Il valore predefinito è 45 secondi nei gateway VPN di Azure. Se si imposta il timeout su periodi più brevi, IKE verrà reimpostato in modo più aggressivo, causando un'apparente disconnessione in alcuni casi. 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 di collegamento fisico potrebbe riscontrare una perdita di pacchetti. In generale, è consigliabile impostare il timeout 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, viene usato IKEv2 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.

È consentito il transito tra le connessioni IKEv1 e IKEv2?

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 di base non le supporta.

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

No. Una volta creata 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 la reimpostazione delle chiavi sul posto. Quando la modalità principale viene reimpostata, i tunnel IKEv1 si disconnettono e sono necessari 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 la reimpostazione delle chiavi sul posto.

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

Dove è possibile trovare informazioni e procedure 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 di BGP, è necessario specificare uno o più indirizzi IP BGP di APIPA per Azure nel gateway VPN di Azure. Gateway VPN di Azure 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 locale non APIPA. 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 l'indirizzo APIPA per BGP, è necessario specificare uno o più indirizzi IP di BGP APIPA nel gateway VPN di Azure, come descritto in Configurare BGP. Specificare questi indirizzi nel gateway di rete locale corrispondente che rappresenta la posizione.

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 numeri 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. BFD (Bidirectional Forwarding Detection) è un protocollo che può essere usato con BGP per rilevare l'inattività di vicini più rapidamente rispetto ai "keepalive" BGP standard. BFD usa timer di frazioni di secondo progettati per funzionare in ambienti LAN, ma non in connessioni tramite Internet pubblico o reti WAN.

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 inferiori all'intervallo "keepalive" predefinito di 60 secondi o inferiori al timer di blocco predefinito di 180 secondi non sono affidabili. È consigliabile usare i valori predefiniti o maggiori per i timer.

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

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

È possibile configurare il tunneling forzato?

Sì. Vedere Configurare il tunneling forzato.

NAT

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

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

È possibile usare NAT nelle connessioni da rete virtuale a rete virtuale o da punto 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 / nel nome di una 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 che alcune connessioni con NAT funzionino insieme ad altre connessioni senza NAT.

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

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

NAT funziona nei gateway VPN attivo-attivo?

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 attivo-attivo creare una regola NAT separata per ogni istanza del gateway tramite il campo "ID configurazione indirizzo IP".

NAT funziona con le connessioni BGP?

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

  • Selezionare Abilita la conversione 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 successivi a 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 normale non APIPA e si scontra con lo spazio indirizzi della rete virtuale o con altri spazi di rete locali, assicurarsi che la regola IngressSNAT converta l'indirizzo IP del peer BGP in un indirizzo univoco e non sovrapposto e inserisca l'indirizzo successivo a NAT nel campo Indirizzo IP del peer BGP campo 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 conversione per entrambe le direzioni di una rete specifica:

  • Una regola IngressSNAT definisce la conversione degli indirizzi IP di origine che entrano nel gateway VPN di Azure dalla rete locale. Gestisce anche la conversione degli indirizzi IP di destinazione che escono dalla rete virtuale verso la stessa rete locale.

  • Una regola EgressSNAT definisce la conversione degli indirizzi IP di origine della rete virtuale che lasciano il gateway VPN di Azure verso le 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 lo spazio di indirizzi del gateway di rete locale o della rete virtuale ha due o più prefissi? È possibile applicare NAT a tutti? O solo a un subset?

È necessario creare una regola NAT per ogni prefisso a cui è necessario applicare 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 IngressSNAT 1: mappa da 10.0.1.0/24 a 100.0.1.0/24
  • Regola IngressSNAT 2: mappa da 10.0.2.0/25 a 100.0.2.0/25

Le due regole devono corrispondere alle lunghezze dei prefissi degli indirizzi corrispondenti. Lo stesso vale per le regole EgressSNAT per lo spazio 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 verso 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 sono destinate alla stessa rete locale per fornire ridondanza. Non è possibile usare la stessa regola di ingresso se le connessioni sono destinate a reti locali diverse.

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

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

Cosa si sceglie come "ID configurazione indirizzo IP"?

"ID configurazione indirizzo IP" è semplicemente il nome dell'oggetto di configurazione dell'indirizzo IP che si vuole far usare alla 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 il valore "default" di IPconfiguration e l'indirizzo IP secondario viene assegnato il valore "activeActive" di IPconfiguration.

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 sulla macchina virtuale tramite indirizzo IP privato se si esegue la connessione da una posizione esterna alla rete virtuale. Se ad esempio è 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 viene effettuata la connessione. Se l'indirizzo IP è compreso nell'intervallo di indirizzi della rete virtuale a cui ci si connette o nell'intervallo di indirizzi di VPNClientAddressPool, si verifica la cosiddetta sovrapposizione dello spazio indirizzi. 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 aver specificato 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 vengono eseguite 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?

Al momento, è necessario configurare una finestra minima 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.

Ci casi in cui 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 preoccupano 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 del cliente della finestra di manutenzione ed eseguire il push della modifica. Si tratta di eventi rari a cui si fa ricorso solo in casi estremi.

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

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

Tutti gli SKU del gateway (ad eccezione dello SKU di base 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 del 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 stati associati alla risorsa del gateway.

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

Sì. Le risorse del gateway che usano un indirizzo IP pubblico con SKU di base potranno disporre solo degli aggiornamenti del servizio in seguito al programma di manutenzione controllato dal cliente. Per questi gateway, la manutenzione del sistema operativo guest NON segue il programma di manutenzione controllato 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 usano 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.

È stata pianificato una finestra di manutenzione per una data futura per una risorsa. 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 che precede la finestra di manutenzione pianificata. Per i giorni non coperti nel programma di manutenzione, la manutenzione continua come di consueto nella risorsa.

Come è possibile ottenere altre informazioni sulla manutenzione del gateway controllata dal cliente?

Per altre informazioni, vedere l'articolo Manutenzione del gateway controllato dal cliente per il gateway VPN.

Passaggi successivi

"OpenVPN" è un marchio di OpenVPN Inc.