Informazioni sulla migrazione di un indirizzo IP pubblico SKU Basic allo SKU Standard

Questo articolo illustra il processo di migrazione da un indirizzo IP pubblico SKU Basic a un indirizzo IP pubblico dello SKU Standard per le distribuzioni Gateway VPN. Vi sono sequenze temporali di migrazione separate, a seconda dello SKU del Gateway VPN attualmente configurato per l'uso.

Importante

Per le sequenze temporali di migrazione previste, vedere l'articolo Gateway VPN - Novità.

Considerazioni sulla migrazione

Per eseguire la migrazione del gateway, è prima necessario verificare se la risorsa è in grado di eseguire la migrazione. Ecco alcune situazioni comuni di cui tenere conto:

  • Per SKU del gateway Basic di Gateway VPN:

  • Per gli SKU del gateway VPN VpnGw1-5 e gli SKU Legacy (SKU High-Performance e Standard):

    • Prima di avviare la migrazione per il gateway VPN, verificare che la subnet del gateway disponga di almeno tre indirizzi IP disponibili nel prefisso corrente.

    • Quando si configura un terzo indirizzo VIP in modalità Active-Active per la connessione da punto a sito (P2S), è necessario usare un indirizzo IP pubblico non di zona.

    • Lo strumento di migrazione richiede che la subnet del gateway abbia almeno uno spazio indirizzi /27. Se la subnet del gateway è attualmente /28 o minore, la migrazione ha esito negativo e restituisce un errore. Prima di iniziare la migrazione, espandere la subnet del gateway a /27 o superiore. Per aggiungere più prefissi per una subnet, vedere Aggiungere più prefissi per la subnet.

    • Se si dispone di ExpressRoute e VPN coesistenti: è consigliabile prima eseguire la migrazione delle risorse IP di base all'indirizzo IP Standard nella VPN .

Domande frequenti

A seconda dello SKU del gateway VPN corrente, potrebbero essere presenti domande diverse sul processo di migrazione. Ecco alcune domande frequenti che consentono di comprendere meglio la migrazione.

SKU del gateway VPN VpnGw1-5

Quanto tempo richiede in genere la migrazione end-to-end?

L'intero processo di migrazione richiede in genere fino a 2 ore, a seconda delle dimensioni e della configurazione della distribuzione.

Quanto tempo richiede ogni passaggio della migrazione?

Le durate dei passaggi di migrazione possono variare in base alla complessità dell'ambiente. Mediamente:

  • Preparazione: in genere fino a 40 minuti, con un massimo di 1 ora.
  • Esecuzione: richiede circa 5-10 minuti. Questo è l'unico passaggio in cui è previsto un breve tempo di inattività.
  • Commit: in genere fino a 30 minuti, con un massimo di 1 ora.

Quanto tempo è possibile attendere prima di eseguire il commit delle modifiche alla migrazione?

La convalida della migrazione viene in genere completata entro un breve intervallo di tempo. I clienti sono invitati a completare la convalida e a eseguire il commit delle modifiche alla migrazione entro pochi giorni, perché non è consigliabile lasciare le migrazioni in sospeso per periodi prolungati. La durata effettiva varia in base alle esigenze di ambiente e convalida.

In che modo sarà interessato lo SKU del gateway dopo la migrazione dell'indirizzo IP pubblico dello SKU Basic?

Dopo aver eseguito l'aggiornamento da un indirizzo IP pubblico SKU Basic a un indirizzo IP pubblico dello SKU Standard, la SKU del gateway VPN VPNGW1-5 verrà migrata a VPNGW1AZ-5. Di conseguenza, lo SKU potrebbe essere modificato da non AZ ad AZ. Per altre informazioni sull'impatto dello SKU, vedere l'articolo Migrazione dello SKU del gateway .

L'indirizzo IP del gateway VPN cambierà dopo la migrazione dell'indirizzo IP pubblico?

  • Se si usa l'esperienza di migrazione fornita dal Microsoft, l'indirizzo IP del gateway non cambierà.
  • Se si elimina manualmente il gateway VPN corrente con un indirizzo IP pubblico con SKU Basic e si crea un nuovo gateway VPN usando un indirizzo IP pubblico con SKU Standard, l'indirizzo IP del gateway cambia.

Ci saranno tempi di inattività?

È previsto fino a 10 minuti di tempo di inattività durante l'esperienza di migrazione fornita dalla Microsoft.

È necessario eseguire azioni per eseguire la migrazione?

L'esperienza di migrazione fornita dal Microsoft è una migrazione avviata dal cliente. Sarà necessario avviare il processo di migrazione. Il processo di migrazione richiederà fino a 10 minuti.

Esistono prerequisiti per la migrazione?

Assicurarsi che la subnet del gateway abbia le dimensioni corrette dello spazio degli indirizzi IP e della subnet. Prima di eseguire la migrazione, sono necessari almeno tre indirizzi IP disponibili nel prefisso corrente.

È possibile passare manualmente a un indirizzo IP pubblico SKU Standard?

Sì, è possibile. Se si sceglie di eseguire questa operazione manualmente, è necessario eliminare il gateway precedente e quindi creare un nuovo gateway nella rete virtuale. Quando si crea un nuovo gateway, il gateway userà automaticamente un indirizzo IP pubblico con SKU Standard. Tuttavia, se si sceglie di usare questo processo, si verifica un tempo di inattività mentre il gateway precedente viene eliminato e viene creato il nuovo gateway.

Se si elimina e si ricrea il gateway, l'indirizzo IP cambia?

Sì, l'indirizzo IP cambia con questo approccio. Ciò significa che è necessario assicurarsi che il nuovo indirizzo IP venga aggiornato in tutti gli strumenti interni in base alle esigenze.

La migrazione del gateway VPN influirà sul traffico ExpressRoute in una configurazione coesistente?

No. Quando si segue l'ordine di migrazione consigliato, la migrazione iniziale del gateway VPN non migra, non interrompe e non influenza il traffico di ExpressRoute. La connettività ExpressRoute rimane invariata durante la migrazione del gateway VPN. I clienti non dovrebbero aspettarsi problemi di connettività di ExpressRoute durante la migrazione del gateway VPN.

È possibile abilitare la protezione DDoS durante la migrazione del gateway?

No. Mentre il gateway è in fase di migrazione (tra Esegui e Commit), non apportare modifiche all'indirizzo IP pubblico, al gateway o alle connessioni. L'abilitazione della protezione DDoS o di altre funzionalità avanzate durante questa fase può bloccare la migrazione o impedire il rollback. Abilitare tali funzionalità solo dopo il completamento della migrazione (dopo il commit).

È possibile modificare l'indirizzo IP, Gateway VPN, la subnet o le connessioni durante la migrazione?

No. Mentre il Gateway VPN è in fase di migrazione (tra Esegui e Commit), non è necessario apportare alcuna modifica ai seguenti elementi:

Connessioni del subnet del gateway di configurazione del gateway VPN Indirizzo IP pubblico

Le modifiche apportate durante questa fase possono impostare il gateway in uno stato non supportato o bloccato, perché il flusso di lavoro di migrazione non gestisce gli aggiornamenti simultanei.

Cosa accade se si apportano modifiche durante la migrazione e il gateway si blocca?

Se il gateway entra in uno stato di migrazione bloccato o irreversibile a causa delle modifiche apportate durante la migrazione:

Il sistema potrebbe non essere in grado di completare o eseguire il rollback della migrazione. In questi casi, l'unica opzione di ripristino può essere quella di eliminare e ricreare il gateway.

SKU di gateway Active-Active VpnGw1–5

Perché il gateway VPN Active-Active con Point-to-Site (P2S) richiede un terzo indirizzo IP pubblico?

Per i gateway VPN Active-Active con P2S abilitata, è necessario un terzo indirizzo IP pubblico per supportare l'endpoint P2S, oltre ai due indirizzi IP usati per le istanze Active-Active.

La documentazione indica che il terzo indirizzo IP pubblico deve essere non di zona. È ancora necessario?

Yes.
In questo scenario, il terzo indirizzo IP pubblico deve essere configurato senza zone (non zonale) per garantire la compatibilità con la configurazione del gateway VPN e le future operazioni di aggiornamento.

Quando è necessario creare il terzo indirizzo IP pubblico durante la migrazione?

Il terzo indirizzo IP pubblico deve essere creato e collegato al Gateway VPN per avviare la migrazione (IP standard di base →).

In questo modo si garantisce quanto segue:

  • La configurazione del gateway è stata completata prima della migrazione
  • Il processo di migrazione continua senza problemi di convalida o aggiornamento

Come si crea l'indirizzo IP pubblico non di zona richiesto?

Nelle regioni in cui gli IP con ridondanza della zona sono l'impostazione predefinita, è necessario creare il terzo indirizzo IP pubblico usando interfaccia della riga di comando di Azure o PowerShell oppure l'API REST versione 2020-08-01 o successiva, che imposti un IP pubblico non zonale / senza zona, assicurandosi che non venga specificata alcuna zona di disponibilità.

Ciò consente di creare l'indirizzo IP pubblico in una configurazione non a livello di zona, necessaria per questo scenario.

È possibile usare un indirizzo IP pubblico con ridondanza della zona anziché un indirizzo IP non di zona per il terzo indirizzo IP da P2S?

No.

Tutti gli indirizzi IP pubblici associati a un Gateway VPN devono usare una configurazione consistente. L'uso di un indirizzo IP pubblico con ridondanza della zona per il terzo indirizzo IP può causare errori di distribuzione o aggiornamento.

Questo comportamento influisce su tutte le migrazioni Gateway VPN?

No.

Questo requisito si applica in modo specifico a:

  • Gateway VPN di tipo attivo/attivo
  • Con la funzionalità da punto a sito (P2S) abilitata

Come si comporta la migrazione per un gateway VPN attivo-attivo usando un indirizzo IP pubblico di base? Causa un'interruzione completa del gateway?

No. Durante la migrazione da un indirizzo IP pubblico di base a un indirizzo IP pubblico standard, il gateway VPN viene sottoposto a transizione come unità e ristabilire la connettività come parte del processo di migrazione. La migrazione non sposta il traffico da un'istanza del gateway a un'altra istanza e non comporta un'interruzione completa del gateway. Durante la migrazione potrebbero verificarsi interruzioni di connettività brevi, ma il gateway non viene portato completamente offline.

Durante la migrazione, solo i tunnel su un'istanza specifica del gateway sono soggetti a interruzioni mentre l'altra istanza rimane attiva?

No. È previsto che i tunnel VPN vengano ricreati come parte del processo di migrazione, ma non vengono migrati o sottoposti a failover per ogni istanza. I tunnel non devono fluttuare per la migrazione di singole istanze del gateway, e la migrazione non è limitata a istanze specifiche all'interno di un gateway Active-Active.

Come deve essere descritto il tempo di inattività per la migrazione del gateway VPN attivo-attivo?

La migrazione è un'operazione di interruzione e potrebbe causare brevi interruzioni della connettività mentre la configurazione del gateway VPN viene aggiornata e le connessioni vengono ristabilite. Queste interruzioni sono in genere diversi minuti di durata e nella maggior parte dei casi vengono completate entro circa 10 minuti, anche se gli intervalli esatti non sono garantiti e possono variare in base alle condizioni di configurazione e di rete. I clienti devono pianificare l'esecuzione della migrazione durante una finestra di manutenzione e assicurarsi che le applicazioni siano resilienti a brevi interruzioni della connettività.

Dopo la migrazione viene visualizzato il cambiamento dell'indirizzo IP del peer BGP. È necessario aggiornare gli indirizzi IP peer BGP dopo la migrazione di un Gateway VPN attivo-attivo a un indirizzo IP standard?

No. Anche se il portale di Azure visualizza nuovi indirizzi IP peer BGP dopo la migrazione, le configurazioni BGP locali esistenti continuano a funzionare senza modifiche. Azure reindirizza automaticamente il traffico dagli indirizzi IP peer BGP originali agli indirizzi IP peer BGP, mantenendo la connettività e le sessioni BGP.

Route e servizi di bilanciamento del carico creati dal cliente durante la migrazione del gateway VPN

È necessario esaminare una configurazione di rete personalizzata prima della migrazione?

Yes. Esaminare tutte le tabelle di route create dal cliente ,i servizi di bilanciamento del carico, i firewall o le appliance virtuali di rete che possono fare riferimento ad indirizzi IP privati dell'istanza Gateway VPN (CA del gateway). E la propagazione della route BGP viene trasformata prima della migrazione. Se l'ambiente usa il peering reti virtuali, verificare che il peering reti virtuali di sincronizzazione sia abilitato durante la migrazione.

Quando è necessario aggiornare queste configurazioni?

Dopo il passaggio Esegui aggiornare le route create dal cliente, i servizi di bilanciamento del carico, le regole del firewall o le configurazioni dell'appliance virtuale di rete che fanno riferimento agli indirizzi IP dell'istanza del gateway precedente.

VPN Basic del Gateway VPN

È possibile creare un gateway VPN di tipo SKU Basic con un indirizzo IP pubblico di tipo SKU Basic?

No, non è possibile creare un gateway VPN SKU Basic con un indirizzo IP pubblico SKU Basic. I nuovi gateway VPN SKU Basic richiedono uno SKU di indirizzo IP pubblico Standard.

È necessario eseguire la migrazione se si dispone di un gateway VPN SKU Basic?

I gateway VPN con SKU Basic che attualmente sono mostrati con l'uso di un indirizzo IP pubblico con SKU Basic non utilizzano il processo di migrazione per passare a un indirizzo IP pubblico con SKU Standard. L'unica azione da eseguire consiste nel rimuovere il riferimento IP pubblico dello SKU Basic dal gateway.

Per i passaggi per rimuovere il riferimento all'IP pubblico dello SKU Basic, vedere Rimuovere il riferimento all'IP pubblico dello SKU Basic da un gateway VPN Basic SKU. Il gateway continua a usare lo stesso indirizzo IP pubblico. Solo il riferimento alla risorsa IP pubblico SKU Basic viene rimosso dal gateway.

Migrazione back-end

Quando Microsoft eseguirà la migrazione del back-end del gateway VPN?

A partire da agosto 2026, Microsoft esegue automaticamente la migrazione dei gateway VPN idonei non già migrati tramite self-service. Poiché questa operazione è Microsoft gestita, non si riceverà una notifica di migrazione per gateway prima che si verifichi la migrazione. Microsoft esegue la migrazione durante gli orari di minore attività in base all'ora locale locale del gateway per ridurre al minimo l'impatto sui clienti.

L'indirizzo IP pubblico del gateway VPN cambierà durante la migrazione?

No. La migrazione aggiorna la risorsa IP pubblica dallo SKU Basic allo SKU Standard, ma viene mantenuto l'indirizzo IP pubblico esistente. Non è necessario eseguire alcuna azione per l'aggiornamento dell'indirizzo IP pubblico.

La migrazione causerà tempi di inattività o interruzioni del traffico?

Yes. La migrazione causa una breve interruzione della connettività fino a 10 minuti mentre il gateway passa alla nuova infrastruttura back-end. Tuttavia, alcune configurazioni del gateway, ad esempio selettori di traffico personalizzati, Active-Active P2S, P2S basato su CloudApp, RADIUS remoto e altri casi perimetrali identificati, potrebbero richiedere un'azione del cliente e potrebbero avere un impatto sulla connettività se non sono state corrette in anticipo.

È necessario eseguire qualsiasi azione prima della migrazione back-end?

Yes. Completare la migrazione self-service (attivata dal cliente) prima dell'inizio della migrazione back-end. Questo processo consente di convalidare modelli di traffico, applicazioni e topologie di rete specifici, che Microsoft non possono testare completamente per conto dell'utente. Se non si esegue la migrazione self-service, Microsoft potrebbe eseguire automaticamente la migrazione dei gateway idonei durante la migrazione back-end. Questa migrazione non è reversibile. Microsoft potrebbero anche eseguire test di urlo su alcuni gateway. I gateway determinati per essere inattivi potrebbero essere eliminati come parte del processo di ritiro. Esaminare e correggere anche eventuali configurazioni interessate note, ad esempio selettori di traffico personalizzati, Active-Active P2S, P2S basato su CloudApp e RADIUS remoto, prima della migrazione per evitare potenziali problemi di connettività.

Cosa accade se la migrazione non viene completata entro il 30 giugno 2026?

La migrazione avviata dal cliente è terminata il 30 giugno 2026. È previsto il completamento della migrazione entro questa data. Se si rimane sulla piattaforma legacy dopo il 30 giugno 2026, il contratto di servizio Gateway VPN non copre più fino al completamento della migrazione. Le richieste di estensione fino al 31 luglio 2026 vengono approvate automaticamente e non richiedono la revisione individuale. A partire da agosto 2026, Microsoft prevede di eseguire la migrazione dei gateway VPN idonei rimanenti non migrati. Microsoft esegue migrazioni back-end a livello di area durante gli orari di minore attività e potrebbero causare una breve interruzione della connettività simile all'esperienza di migrazione avviata dal cliente.

Passaggi successivi

  • Last updated on