Domande frequenti sul gateway VPN

  • Articolo

Questo articolo risponde alle domande frequenti sulle connessioni cross-premise di Gateway VPN di Azure, sulle connessioni di configurazione ibrida e sui gateway di rete virtuale. Contiene informazioni complete sulle impostazioni di configurazione da punto a sito (P2S), da sito a sito (S2S) e da rete virtuale a rete virtuale, inclusi i protocolli IPsec (Internet Protocol Security) e IKE (Internet Key Exchange).

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 di Azure o in un'area diversa.

È 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 si specificano uno o più server DNS (Domain Name System) quando si crea la rete virtuale, il gateway VPN (Virtual Private Network) usa tali server DNS. Verificare che i server DNS specificati possano 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?

Gateway VPN di Azure supporta le connessioni gateway cross-premise seguenti:

Per altre informazioni sulle connessioni del gateway VPN, vedere Che cos'è Gateway VPN di Azure?.

Qual è la differenza tra connessioni da sito a sito e connessioni da punto a sito?

  • Le configurazioni da sito a sito (tunnel VPN IPsec/IKE) connettono il percorso locale ad Azure. È possibile connettersi da qualsiasi computer disponibile localmente 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'appliance VPN IPsec (dispositivo hardware o dispositivo temporaneo). L'appliance deve essere distribuita nella rete perimetrale. 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. Usa il client VPN predefinito di Windows.

    Come parte della configurazione da punto a sito, si installano un certificato e un pacchetto di configurazione del client VPN. Il pacchetto contiene le impostazioni che consentono al computer di connettersi a qualsiasi macchina virtuale o istanza del ruolo all'interno della rete virtuale.

    Questa configurazione è utile quando si vuole connettersi a una rete virtuale, ma non si trova in 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.

Una configurazione errata del DNS personalizzato arresta il normale funzionamento del gateway VPN?

Per il normale funzionamento, il gateway VPN deve stabilire una connessione sicura con il piano di controllo di Azure, facilitata tramite indirizzi IP pubblici. Questa connessione si basa sulla risoluzione degli endpoint di comunicazione tramite URL pubblici. Per impostazione predefinita, le reti virtuali di Azure usano il servizio DNS di Azure predefinito (168.63.129.16) per risolvere questi URL pubblici. Questo comportamento predefinito consente di garantire una comunicazione trasparente tra il gateway VPN e il piano di controllo di Azure.

Quando si implementa un DNS personalizzato all'interno di una rete virtuale, è fondamentale configurare un server d'inoltro DNS che punta a DNS di Azure (168.63.129.16). Questa configurazione consente di mantenere una comunicazione continua tra il gateway VPN e il piano di controllo. L'impossibilità di configurare un server d'inoltro DNS nel DNS di Azure può impedire a Microsoft di eseguire operazioni e manutenzione nel gateway VPN, comportando un rischio per la sicurezza.

Per garantire una corretta funzionalità e uno stato integro per il gateway VPN, prendere in considerazione una delle configurazioni DNS seguenti nella rete virtuale:

  • Ripristinare l'impostazione predefinita del DNS di Azure rimuovendo il DNS personalizzato nelle impostazioni della rete virtuale (configurazione consigliata).
  • Nella configurazione DNS personalizzata aggiungere un server d'inoltro DNS che punta al DNS di Azure (168.63.129.16). A seconda delle regole specifiche e della natura del DNS personalizzato, questa configurazione potrebbe non risolvere il problema come previsto.

Due client VPN possono connettersi da punto a sito allo stesso gateway VPN?

No. I client VPN connessi da punto a sito allo stesso gateway VPN non possono comunicare tra loro.

Quando due client VPN sono connessi allo stesso gateway VPN da punto a sito, il gateway può instradare automaticamente il traffico tra di essi determinando l'indirizzo IP assegnato da ogni client dal pool di indirizzi. Tuttavia, se i client VPN sono connessi a gateway VPN differenti, il routing tra i client VPN non è possibile perché ogni gateway VPN non è a conoscenza dell'indirizzo IP assegnato al client dall'altro gateway.

Le connessioni VPN da punto a sito potrebbero essere interessate da una potenziale vulnerabilità nota come "visione tunnel"?

Microsoft è a conoscenza delle segnalazioni relative alla tecnica di rete che ignora l'incapsulamento VPN. Si tratta di un problema a livello di settore che influisce su qualsiasi sistema operativo che implementa un client DHCP (Dynamic Host Configuration Protocol) in base alla specifica RFC e dispone del supporto per le route DHCP opzione 121, incluso Windows.

Come indicato nella ricerca, le mitigazioni includono l'esecuzione della VPN all'interno di una macchina virtuale che ottiene un lease da un server DHCP virtualizzato per impedire che il server DHCP di reti locali installi completamente le route. Altre informazioni su questa vulnerabilità sono disponibili nel database nazionale delle vulnerabilità nazionale di NIST.

Privacy

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 -GatewayType per Vpn. 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 vengono 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 Azure PowerShell o l'interfaccia della riga di comando di Azure per creare i gateway basati su criteri.

In precedenza, i livelli dei prodotti gateway (SKU) 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 un tipo di gateway, è necessario eliminare e ricreare il gateway seguendo questa procedura. 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 la procedura, vedere l'esercitazione relativa alla connessione da sito a sito.

È possibile specificare i selettori di traffico basati su criteri personalizzati?

Sì, è possibile definire i selettori di traffico usando l'attributo trafficSelectorPolicies in una connessione tramite il comando New-AzIpsecTrafficSelectorPolicy di Azure PowerShell. Per rendere effettivo il selettore di traffico specificato, assicurarsi di abilitare i selettori di traffico basati su criteri.

I selettori di traffico configurati in modo personalizzato sono proposti solo quando un gateway VPN 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).

È necessaria una subnet del gateway?

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.

Tutte le subnet del gateway devono essere denominate GatewaySubnet per funzionare correttamente. 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. Assicurarsi che la subnet del gateway contenga una quantità di indirizzi IP sufficiente per supportare la crescita futura e per possibili nuove configurazioni 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. Verificare che la subnet del gateway esistente soddisfi i requisiti della configurazione che si vuole creare.

È 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. 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.

È 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 requisito si applica a tutti gli SKU del gateway tranne lo SKU Basic. Lo SKU Basic attualmente supporta solo gli indirizzi IP pubblici con SKU Basic. Verrà aggiunto il supporto per gli indirizzi IP pubblici con SKU Standard per gli SKU Basic.

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

In che modo il ritiro dello SKU Basic degli indirizzi IP pubblici influisce sui gateway VPN?

È in corso un'azione per garantire il funzionamento continuo dei gateway VPN distribuiti che usano indirizzi IP pubblici sku Basic fino al ritiro dell'indirizzo IP basic nel settembre 2025. Prima del ritiro, verrà fornito ai clienti un percorso di migrazione da Basic a IP Standard.

Tuttavia, gli indirizzi IP pubblici con SKU Basic verranno eliminati gradualmente. In futuro, quando si creerà un nuovo gateway VPN, sarà necessario usare un indirizzo IP pubblico con SKU Standard. È possibile trovare informazioni dettagliate sul ritiro degli indirizzi IP pubblici con SKU Basic nell'annuncio degli aggiornamenti di Azure.

Come viene autenticato il tunnel VPN?

Gateway VPN di Azure usa l'autenticazione con chiave precondivisa (PSK). Quando si crea il tunnel VPN, viene generato una chiave precondivisa. È possibile convertire la chiave precondivisa generata automaticamente in chiave personalizzata usando l'API REST di impostazione della chiave precondivisa o il cmdlet di PowerShell.

È possibile usare l'API REST di impostazione della chiave precondivisa per configurare la VPN del 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?

Per il modello di distribuzione di Azure Resource Manager:

  • Azure PowerShell: usare AddressPrefix per specificare il traffico per il gateway di rete locale.
  • Portale di Azure: passare a Gateway di rete locale>Configurazione>Spazio indirizzi.

Per il modello di distribuzione classica:

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

È possibile usare NAT-T nelle connessioni VPN?

Sì, è supportato lo standard NAT-T (Network Address Translation-Traversal). 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. I certificati di Azure consentono di proteggerle bloccandole. Senza certificati appropriati, le entità esterne, compresi i clienti di questi gateway, non potranno avere alcun impatto su tali endpoint.

Un gateway di rete virtuale è fondamentalmente un dispositivo multihomed. Una scheda di rete è rivolta alla rete privata del cliente e una scheda di rete è rivolta 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. Un controllo di sicurezza di Azure analizza periodicamente gli endpoint pubblici.

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

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

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

Fai riferimento ai seguenti articoli:

Deprecazione di SKU meno recenti

Gli SKU standard e con prestazioni elevate saranno deprecati il 30 settembre 2025. È possibile visualizzare l'annuncio nel sito Aggiornamenti di Azure. 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 gateway che usa uno SKU Standard o HighPerformance dopo l'annuncio di deprecazione il 30 novembre 2023?

No. A partire dal 1° dicembre 2023, non è possibile creare gateway che usano SKU Standard o HighPerformance. È possibile creare nuovi gateway che usano SKU VpnGw1 e VpnGw2 allo stesso prezzo degli SKU Standard e HighPerformance, elencati rispettivamente nella pagina dei prezzi.

Per quanto tempo saranno supportati i gateway esistenti negli SKU Standard/HighPerformance?

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

È necessario eseguire subito la migrazione dei gateway dallo SKU Standard o HighPerformance?

No, non è necessaria alcuna azione in questo momento. È possibile eseguire la migrazione dei gateway 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:

  • Da Standard a VpnGw1
  • Da HighPerformance a VpnGw2

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

Non è possibile eseguire la migrazione dello SKU deprecato a uno SKU AZ. Tuttavia, tutti i gateway che continuano a usare SKU Standard o HighPerformance dopo il 30 settembre 2025 verranno migrati e aggiornati automaticamente agli SKU AZ nel modo seguente:

  • Da Standard a VpnGw1AZ
  • Da HighPerformance a 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. Per i prezzi degli SKU AZ, vedere la pagina dei prezzi. 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, lo SKU VpnGw1 a 650 Mbps offre un miglioramento delle prestazioni di 6,5 volte superiore allo stesso prezzo dello SKU Standard. Lo SKU VpnGw2 a 1 Gbps offre un miglioramento delle prestazioni 5 volte superiore allo stesso prezzo dello SKU HighPerformance. 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 continuano a usare gli SKU Standard o HighPerformance verranno migrati automaticamente e aggiornati agli SKU AZ seguenti:

  • Da Standard a VpnGw1AZ
  • Da HighPerformance a VpnGw2AZ

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

Anche lo SKU Basic del gateway VPN viene ritirato?

No, lo SKU Basic del gateway VPN non verrà ritirato. È possibile creare un gateway VPN usando lo SKU Basic tramite Azure PowerShell o l'interfaccia della riga di comando di Azure.

Attualmente, gli SKU Basic del gateway VPN supportano solo la risorsa dell'indirizzo IP pubblico dello SKU Basic (che verrà presto ritirata). Microsoft si sta impegnando per aggiungere il supporto per lo SKU Standard della risorsa dell'indirizzo IP pubblico allo SKU Basic gateway VPN.

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 Informazioni sui dispositivi VPN.

Tutti i dispositivi appartenenti ai gruppi di dispositivi di cui è indicata la compatibilità nota dovrebbero funzionare con le reti virtuali. Per semplificare 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?

A seconda del dispositivo VPN usato, potrebbe essere possibile scaricare un apposito script di configurazione. 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?

Vedere Esempi di modifica di configurazione dispositivo.

Dove è possibile reperire i parametri IPsec e IKE?

Vedere parametri predefiniti IPsec/IKE.

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

Questo comportamento è previsto per gateway VPN basati su criteri (anche noti 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 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 sul supporto, 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.

Connessioni da punto a sito

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 successive
  • 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:

  • 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: 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: una soluzione VPN IPsec basata su standard che usa le porte UDP 500 e 4500 in uscita e il protocollo IP numero 50. I firewall non aprono sempre queste porte, quindi è possibile che la VPN IKEv2 non possa 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?

DNS dinamico (DDNS) non è attualmente supportato nelle VPN da punto a sito.

È possibile la coesistenza di configurazioni da sito a sito e da punto a sito nella stessa rete virtuale?

Sì. Per il modello di distribuzione Resource Manager, è necessario disporre di un gateway con VPN di tipo RouteBased. Per il modello di distribuzione classica è necessario un gateway dinamico. La configurazione da punto a sito non è supportata per i 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. Ma questo è il caso solo se le reti virtuali a cui ci si connette non hanno spazi indirizzi in conflitto tra di 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 contempo a più reti virtuali?

Sì. Le connessioni client da punto a sito a un gateway VPN distribuito in una rete virtuale con peering con altre reti virtuali possono avere accesso alle altre reti virtuali con peering, purché soddisfino determinati criteri di configurazione. Affinché una connessione da punto a sito abbia accesso a una rete virtuale con peering, la rete virtuale con peering (la rete virtuale senza il gateway) deve essere configurata con l'attributo Usa gateway remoti. La rete virtuale con il gateway VPN deve essere configurata con l'attributo Consenti transito gateway. Per altre informazioni, vedere Informazioni sul routing di VPN 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 può essere limitata anche 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.

Per la connettività da punto a sito è possibile usare qualsiasi client VPN software 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 a Gateway VPN>Configurazione da punto a sito. In Tipo di autenticazione selezionare i tipi di autenticazione che si vuole usare.

Dopo aver modificato il tipo di autenticazione, i client correnti potrebbero non essere in grado di connettersi finché non si genera, scarica e applica un nuovo profilo di configurazione 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 la connessione al gateway da punto a sito. Dopo aver generato il pacchetto, usare le impostazioni nei file per aggiornare i client VPN.

Azure supporta VPN IKEv2 con Windows?

IKEv2 è supportato in Windows 10 e Windows Server 2016. Per poter usare IKEv2 in determinate versioni del sistema operativo, è però necessario installare gli aggiornamenti e impostare localmente 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 Windows 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 la chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD nel Registro di sistema su 1.

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 hanno un limite di selettore di traffico pari a 25.

Il limite dei selettori di traffico in Windows determina il numero massimo di spazi 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 1.000 route.

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

Quando si configura sia SSTP che IKEv2 in un ambiente misto composto da dispositivi Windows e Mac, il client VPN di Windows tenta sempre prima di accedere al tunnel IKEv2. Il client esegue il fallback a SSTP se la connessione IKEv2 non riesce. MacOS si connette 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. Il risultato è 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 blocco CIDR (Classless Inter-Domain Routing) per l'intervallo di indirizzi da punto a sito, ma includere il blocco CIDR per i due intervalli secondari.

Quali piattaforme supporta Azure per VPN da sito a sito?

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

È già stato distribuito un gateway VPN. È possibile attivare una VPN RADIUS o VPN IKEv2 su tale gateway?

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

Perché viene disconnesso dal client VPN di Azure? Cosa posso fare per ridurre la frequenza di disconnessione?

È possibile che venga visualizzato uno dei messaggi seguenti:

  • Nel client VPN di Azure per Windows ver. 3.4.0.0: "L'autenticazione con Microsoft Entra è scaduta. Per acquisire un nuovo token, è necessario eseguire di nuovo l'autenticazione in Entra. Il timeout dell'autenticazione può essere ottimizzato dall'amministratore."
  • Nel client VPN di Azure per macOS ver. 2.7.101: "L'autenticazione con Microsoft Entra è scaduta, quindi è necessario ripetere l'autenticazione per acquisire un nuovo token. Riprovare a connettersi. I criteri di autenticazione e il timeout vengono configurati dall'amministratore nel tenant entra."

La connessione da punto a sito si disconnette perché il token di aggiornamento corrente nel client VPN di Azure, acquisito dall'ID Entra, è scaduto o non è valido. Questo token viene rinnovato circa ogni ora. Gli amministratori tenant entra possono estendere la frequenza di accesso aggiungendo criteri di accesso condizionale. Collaborare con gli amministratori tenant entra per estendere l'intervallo di scadenza del token di aggiornamento.

Per altre informazioni, vedere: Errore del client VPN: Autenticazione con Microsoft Entra scaduta.

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

È possibile rimuovere una configurazione da sito a sito usando i comandi seguenti di Azure PowerShell o dell'interfaccia della riga di comando di Azure:

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

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

Connessioni da punto a sito con autenticazione del certificato

Che cosa è necessario fare se si verifica una mancata corrispondenza del certificato per una connessione da punto a sito tramite autenticazione del certificato?

Deselezionare la casella di controllo Verifica l'identità del server mediante convalida del certificato. In alternativa, aggiungere il nome di dominio completo (FQDN) del server insieme al certificato quando si crea un profilo manualmente. A tale scopo, eseguire rasphone da un prompt dei comandi e selezionare il profilo dall'elenco a discesa.

In generale, non è consigliabile ignorare la convalida dell'identità del server. Con l'autenticazione del certificato di Azure, tuttavia, lo stesso certificato viene usato per la convalida del server nel protocollo di tunneling VPN (IKEv2 o SSTP) e nel protocollo EAP (Extensible Authentication Protocol). Poiché il protocollo di tunneling VPN sta già convalidando il certificato del server e il nome di dominio completo, è ridondante convalidarli nuovamente in EAP.

Screenshot che mostra le proprietà per l'autenticazione da punto a sito.

È possibile usare l'autorità di certificazione radice della PKI interna per generare i certificati per la connettività da punto a sito?

Sì. In precedenza, era possibile usare 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?

Per i formati di file con estensione .cer e .pfx, vedere:

Per il formato di file .pem, vedere:

Connessioni da punto a sito con autenticazione RADIUS

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 precedenti, l'autenticazione RADIUS è supportata negli SKU Standard e HighPerformance.

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

No.

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ì.

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 verso un server RADIUS locale (dal gateway VPN) 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 Informazioni sugli SKU del gateway.

Qual è la differenza tra eseguire l'autenticazione del certificato tramite un server RADIUS ed eseguire l'autenticazione del certificato nativo di Azure tramite il caricamento di un certificato attendibile?

Nell'autenticazione del certificato RADIUS la richiesta di autenticazione viene inoltrata a un server RADIUS che gestisce la convalida 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 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 per l'autenticazione a più fattori?

Se l'autenticazione a più fattori è basata su testo, ad esempio SMS o codice di verifica dell'app per dispositivi mobili, 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 VPN IKEv2 che con VPN SSTP?

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

L'autenticazione RADIUS funziona con il client OpenVPN?

Per il protocollo OpenVPN l'autenticazione RADIUS è supportata.

Connessioni da VNet a VNet e multi-sito

Le informazioni sulle connessioni da rete virtuale a rete virtuale in questa sezione si applicano alle connessioni del 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 Prezzi di Gateway VPN di Azure. Se si connettono le reti virtuali tramite peering di reti virtuali e non con un gateway VPN, vedere la pagina Prezzi di Rete virtuale di Microsoft Azure.

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 passano attraverso i tenant di Microsoft Entra.

Il traffico tra reti virtuali è sicuro?

La crittografia IPsec e IKE consente di proteggere il traffico da rete virtuale a rete virtuale.

È 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 Microsoft Entra?

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ì. È possibile usare la connettività di rete virtuale 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à da rete virtuale a rete virtuale e multisito richiede la presenza di gateway VPN 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, in precedenza noto come 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 e lo stesso contratto di servizio per i tempi di attività del gateway VPN 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 Azure.

È possibile usare un gateway VPN 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 e routing.

  • Modello di distribuzione classica

    Con il modello di distribuzione classica il transito del traffico attraverso il gateway VPN è possibile, ma si basa su spazi indirizzi definiti in modo statico nel file di configurazione di rete. Il protocollo BGP (Border Gateway Protocol) non è attualmente supportato con le reti virtuali di Azure e i gateway VPN tramite il modello di distribuzione classica. Senza BGP la definizione manuale degli spazi 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, Azure genera chiavi precondivise differenti per connessioni VPN differenti. È tuttavia possibile usare la nuova API REST di impostazione della chiave del gateway VPN 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 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à.

Gateway VPN di Azure rispetta l'anteposizione del percorso del sistema autonomo per influenzare le decisioni di routing tra più connessioni ai siti locali?

Sì, Gateway VPN di Azure rispetta l'anteposizione del percorso del sistema autonomo per prendere decisioni di routing quando BGP è abilitato. Un percorso del sistema autonomo 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 vuole influenzare le decisioni di routing tra più connessioni, è necessario usare il percorso del sistema autonomo anteposto.

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

Sì. È possibile usare VPN da punto a sito con i gateway VPN che si connettono a più siti locali e altre reti virtuali.

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

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

Criteri IPsec/IKE

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

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

Quanti criteri è possibile specificare per una connessione?

È possibile specificare una sola combinazione di criteri per una connessione.

È possibile specificare un criterio parziale in una connessione, 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 supportano i 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 dell'associazione di sicurezza in modalità rapida (Facoltativo; valori predefiniti se non specificati)
Secondi (intero; minimo 300, valore predefinito 27.000)
Kilobyte (numero intero; minimo 1.024, valore predefinito 10.2400.000)
Selettore di traffico UsePolicyBasedTrafficSelectors ($True o $False, ma facoltativo; valore predefinito $False se non specificato)
Timeout DPD Secondi (intero; minimo 9, massimo 3.600, valore predefinito 45)

  • 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 si usa UsePolicyBasedTrafficSelectors)
    • Durate delle associazioni di sicurezza (specifiche locali che non devono corrispondere)

  • Se si usa GCMAES per l'algoritmo di crittografia IPsec, è necessario selezionare lo stesso algoritmo e la stessa lunghezza della chiave GCMAES per l'integrità IPsec. Ad esempio, usare GCMAES128 per entrambi.

  • Nella tabella degli algoritmi e delle 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 nella connessione. Se si imposta UsePolicyBasedTrafficSelectors su $True in una connessione, configura il gateway VPN per connettersi a un firewall VPN PolicyBased locale.

    Se si abilita UsePolicyBasedTrafficSelectors, è 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 o verso i prefissi della rete virtuale di Azure, anziché any-to-any. Il gateway VPN accetta qualsiasi selettore di traffico proposto dal gateway VPN remoto indipendentemente dalla configurazione del gateway VPN.

    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 un gateway VPN a più dispositivi VPN locali basati su criteri.

  • Se si imposta il timeout su periodi più brevi, IKE viene reimpostato in modo più aggressivo. La connessione può quindi risultare disconnessa in alcune istanze. Questa situazione potrebbe non essere auspicabile 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 genere è consigliabile impostare il timeout su valori compresi tra 30 e 45 secondi.

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

Quali gruppi Diffie-Hellman supportano i criteri personalizzati?

La tabella seguente elenca i gruppi di Diffie-Hellman corrispondenti supportati dal criterio personalizzato:

Diffie-Hellman Group 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?

Sì. Dopo aver specificato un criterio personalizzato in una connessione, Gateway VPN di Azure usa solo tale criterio 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, i criteri IPsec/IKE contribuiscono comunque a proteggere la connessione. Dopo la rimozione dei criteri personalizzati da una connessione, il gateway VPN 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 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ì. Un criteri0 personalizzato viene applicato 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 nelle connessioni 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. Assicurarsi 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 nei gateway VPN. È possibile specificare un valore di timeout DPD diverso per ogni connessione IPsec o da rete virtuale a rete virtuale tra 9 e 3.600 secondi.

Nota

Se si imposta il timeout su periodi più brevi, IKE viene reimpostato in modo più aggressivo. La connessione può quindi risultare disconnessa in alcune istanze. Questa situazione potrebbe non essere auspicabile 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 genere è consigliabile impostare il timeout su valori compresi tra 30 e 45 secondi.

Un criterio IPsec/IKE personalizzato funziona in una connessione ExpressRoute?

No. Un criterio IPsec/IKE funziona solo in connessioni VPN da sito a sito e da rete virtuale a rete virtuale tramite i gateway VPN.

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 precedenti.

È 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 Azure PowerShell.

Per informazioni sui tipi di SKU e sul supporto per IKEv1 e IKEv2, vedere Connettere un gateway VPN a più dispositivi VPN locali basati su criteri.

È consentito il transito tra le connessioni IKEv1 e IKEv2?

Sì.

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

No. Lo SKU Basic non supporta questa configurazione.

È 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 e 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 RouteBased 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 altre informazioni e i passaggi per la configurazione?

Fai riferimento ai seguenti articoli:

BGP e routing

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

BGP è supportato in tutti gli SKU di Gateway VPN di Azure 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 ASN è possibile usare?

È possibile usare i propri ASN (Autonomous System Number, numero del sistema autonomo) pubblici o quelli privati sia per le reti locali che per le reti virtuali di Azure.

Non è possibile usare i seguenti ASN riservati:

  • Riservati da Azure:

    • ASN pubblici: 8074, 8075, 12076
    • ASN privati: 65515, 65517, 65518, 65519, 65520

  • Riservati da IANA:

    • 23456, 64496-64511, 65535-65551, 429496729

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

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

Sì, Gateway VPN di Azure ora supporta ASN a 32 bit (4 byte). Per configurare l'uso di ASN in formato decimale, usare Azure 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

Né IANA né Azure riservano questi ASN, quindi è possibile assegnarli al gateway VPN.

Quale indirizzo viene usato da Gateway VPN di Azure per l'indirizzo IP del peer BGP?

Per impostazione predefinita, Gateway VPN di Azure 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 trovare l'indirizzo IP BGP allocato usando Azure PowerShell o il portale di Azure. In PowerShell, usare Get-AzVirtualNetworkGatewaye 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 (Automatic Private IP Addressing) (169.254.x.x) come indirizzi IP BGP, è necessario specificare uno o più indirizzi IP BGP di APIPA per Azure nel gateway VPN. 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 per Gateway VPN di Azure.

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 BGP APIPA nel gateway VPN, come descritto in Configurare BGP per Gateway VPN di Azure. 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.

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, perché è ridondante. Se si usa un indirizzo APIPA come indirizzo IP 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 su 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. È necessario assegnare i numeri ASN locali ai gateway di rete locali di Azure corrispondenti.

Quali prefissi di indirizzo vengono segnalati all'utente da Gateway VPN di Azure?

I gateway annunciano le route seguenti ai dispositivi BGP locali:

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

Quanti prefissi è possibile annunciare al gateway VPN di Azure?

Gateway VPN di Azure supporta fino a 4.000 prefissi. La sessione BGP viene eliminata se il numero di prefissi supera il limite.

È possibile annunciare la route predefinita (0.0.0.0/0) ai gateway VPN?

Sì. Tenere presente che l'annuncio della route predefinita forza tutto il traffico in uscita della rete virtuale verso il sito locale. Si impedisce inoltre alle macchine virtuali della rete virtuale di accettare comunicazioni pubbliche provenienti direttamente da Internet, come RDP (Remote Desktop Protocol) o SSH (Secure Shell) da Internet alle macchine virtuali.

È possibile annunciare gli stessi prefissi della propria rete virtuale?

No. Azure blocca o filtra l'annuncio degli stessi prefissi degli indirizzi della rete virtuale. È tuttavia possibile annunciare un prefisso che rappresenta un superset di quello interno alla rete virtuale.

Ad esempio, se la rete virtuale usa lo spazio 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 non annunciano le route predefinite ad altri peer BGP. Per abilitare il routing di transito tra più gateway VPN, è necessario abilitare BGP in tutte le connessioni intermedie tra reti virtuali. Per altre informazioni, vedere Informazioni su BGP e gateway VPN.

È possibile stabilire più di un tunnel tra un gateway VPN 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. Tutti questi tunnel verranno conteggiati rispetto al numero totale di tunnel per Gateway VPN di Azure ed è necessario abilitare BGP in tutti.

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

È 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 indirizzi vicini più rapidamente rispetto agli intervalli "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à Questa instabilità potrebbe causare la mitigazione delle route BGP.

In alternativa, è possibile configurare il dispositivo locale con timer di durata inferiore all'intervallo "keepalive" predefinito di 60 secondi o inferiore al timer di attesa di 180 secondi. Questa configurazione comporta un tempo di convergenza più rapido. Tuttavia, i timer inferiori all'intervallo "keepalive" predefinito di 60 secondi o inferiori al timer di attesa predefinito di 180 secondi non sono affidabili. È consigliabile mantenere i timer su valori corrispondenti o superiore ai valori predefiniti.

I gateway VPN avviano sessioni o connessioni di peering BGP?

Il gateway VPN 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. Questo processo 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 indirizzo 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 nelle connessioni da VpnGw2 a VpnGw25 e da VpnGw2AZ a VpnGw5AZ.

È 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 una barra (/) 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 supportano i gateway VPN?

I gateway VPN supportano solo NAT statico 1:1 e NAT dinamico. Non supportano NAT64.

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 IP configuration ID.

NAT funziona con le connessioni BGP?

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

  • 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, selezionare Abilita la conversione route BGP nella pagina di configurazione delle regole NAT. È necessario assicurarsi che i router BGP locali annuncino i prefissi esatti, come definito nelle regole IngressSNAT.

  • Se il router VPN locale usa un indirizzo normale non APIPA ed è in conflitto 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. Inserire l'indirizzo successivo a NAT nel campo Indirizzo IP del 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 regola SNAT (Source Network Address Translation) definisce la conversione per entrambe le direzioni di una determinata rete:

  • Una regola IngressSNAT definisce la conversione degli indirizzi IP di origine che entrano nel gateway VPN 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 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 è necessario usare regole DNAT (Destination Network Address Translation).

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 i prefissi o solo a un subset?

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

  • Regola di ingressoSNAT 1: eseguire il mapping da 10.0.1.0/24 a 192.168.1.0/24.
  • Regola di ingressoSNAT 2: eseguire il mapping da 10.0.2.0/25 a 192.168.2.0/25.

Le due regole devono corrispondere alle lunghezze dei prefissi degli indirizzi corrispondenti. Le stesse linee guida si applicano alle 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 per le reti locali?

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ì. In genere si usa la stessa regola IngressSNAT 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 sia di ingresso e che di 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?

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 di rete virtuale passa 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. In alternativa, se si usa il tunneling forzato, il traffico viene inviato attraverso il gateway VPN.

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 macchina virtuale 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 risorse nelle reti virtuali di Azure.

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 del pool di indirizzi client della VPN, 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 di Azure.
  • Gateway ExpressRoute nel servizio Rete WAN virtuale

Quale manutenzione supporta la 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. La manutenzione controllata dal cliente non copre gli aggiornamenti host (oltre gli aggiornamenti host per Power, ad esempio) e gli aggiornamenti critici della sicurezza.

È possibile ricevere una notifica avanzata della manutenzione?

Al momento non è possibile ricevere notifiche avanzate 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 sono 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 interessano i clienti. Alcuni altri tipi di aggiornamenti, inclusi gli aggiornamenti host, non rientrano nell'ambito della manutenzione controllata dal cliente.

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. Queste modifiche sono rare occorrenze usate solo in casi estremi.

Le risorse di configurazione della 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 di Gateway VPN di Azure (ad eccezione dello SKU Basic) 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 Basic?

Sì. La manutenzione controllata dal cliente non funziona per le risorse che usano indirizzi IP pubblici dello SKU Basic, tranne nel caso degli aggiornamenti dei servizi. 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 distinte. Questo approccio garantisce che la manutenzione non influisca contemporaneamente sulle risorse di backup.

Per una risorsa è stata pianificata una finestra di manutenzione per una data futura. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?

No, le attività di manutenzione non vengono 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 Configurare la manutenzione controllata dal cliente per il gateway VPN.

Contenuto correlato

"OpenVPN" è un marchio di OpenVPN Inc.