Virtual WAN の FAQ
Azure Virtual WAN は GA ですか。
はい。Azure Virtual WAN は一般提供 (GA) の状態にあります。 ただし、Virtual WAN はいくつかの機能とシナリオから構成されています。 Microsoft がプレビュー タグを適用する機能またはシナリオが Virtual WAN 内にあります。 その場合、特定の機能またはシナリオ自体がプレビューになります。 特定のプレビュー機能を使用しない場合、通常の GA サポートが適用されます。 プレビュー サポートについて詳しくは、「Microsoft Azure プレビューの追加使用条件」を参照してください。
利用可能な場所とリージョンはどれですか?
詳細については、「 利用可能な場所とリージョン」を参照してください。
ユーザーは、Azure Virtual WAN を使用するために、SD-WAN/VPN デバイスを利用したハブとスポークを用意する必要がありますか。
Virtual WAN では、サイト/サイト間 VPN 接続、ユーザー/P2S 接続、ExpressRoute 接続、仮想ネットワーク接続、VPN ExpressRoute 相互接続、VNet 間の推移的な接続、一元化されたルーティング、Azure Firewall、Firewall Manager のセキュリティ、監視、ExpressRoute 暗号化など、数多くの機能が 1 つの画面に組み込まれています。 Virtual WAN の利用を開始するために、これらのすべてのユース ケースを用意する必要はありません。 1 つのユース ケースのみで利用を開始できます。
Virtual WAN アーキテクチャは、スケールとパフォーマンスが組み込まれたハブ アンド スポーク アーキテクチャで、ブランチ (VPN または SD-WAN デバイス)、ユーザー (Azure VPN クライアント、openVPN、または IKEv2 クライアント)、ExpressRoute 回線、仮想ネットワークが仮想ハブのスポークとして機能します。 Standard Virtual WAN ではすべてのハブがフル メッシュで接続されるため、ユーザーは Any-to-Any (任意のスポーク) 接続に Microsoft バックボーンを簡単に使用できます。 SD-WAN/VPN デバイスを利用したハブとスポークの場合、ユーザーは Azure Virtual WAN ポータル内で手動で設定するか、Virtual WAN パートナーのCPE (SD-WAN/VPN) を使用して Azure への接続を設定することができます。
Virtual WAN パートナーによって、デバイス情報を Azure にエクスポートし、Azure 構成をダウンロードして、Azure Virtual WAN ハブへの接続を確立できる、接続の自動化が提供されます。 ポイント対サイト (ユーザー VPN) 接続の場合、Azure VPN クライアント、OpenVPN、または IKEv2 クライアントがサポートされています。
Virtual WAN でフル メッシュ ハブを無効にすることはできますか。
Virtual WAN には、次の 2 種類があります。Basic と Standard です。 Basic Virtual WAN では、ハブはメッシュされません。 Standard Virtual WAN では、ハブはメッシュされ、仮想 WAN が最初に設定されるときに自動的に接続されます。 ユーザーは特に何もする必要はありません。 また、ユーザーはフル メッシュ ハブを取得する機能を無効または有効にする必要もありません。 Virtual WAN には、任意のスポーク (VNet、VPN、または ExpressRoute) 間のトラフィックを操作するためのルーティング オプションが多数用意されています。 これにより、フル メッシュ ハブを簡単に利用でき、ニーズに応じてトラフィックをルーティングする柔軟性も得られます。
Virtual WAN では Availability Zones と回復性はどのように処理されますか。
Virtual WAN は、ハブ内で使用可能になったハブとサービスのコレクションです。 ユーザーは、必要な数だけ Virtual WAN を利用できます。 Virtual WAN ハブには、VPN や ExpressRoute などの複数のサービスがあります。リージョンで Availability Zones がサポートされている場合、これらのサービス (Azure Firewall を除く) はそれぞれ自動的に Availability Zones にまたがってデプロイされます。 ハブでの初期デプロイ後にリージョンが可用性ゾーンになった場合、ユーザーはゲートウェイを再作成できます。これにより、可用性ゾーンのデプロイがトリガーされます。 すべてのゲートウェイがアクティブ/アクティブとしてハブにプロビジョニングされます。これは、ハブ内に回復性が組み込まれていることを意味します。 ユーザーは、複数のリージョンにわたって回復性が必要な場合、複数のハブに接続できます。
Availability Zones をサポートするために、現在、Azure Firewall Manager Portal、PowerShell、または CLI を使用して Azure Firewall をデプロイできます。 現在、既存のファイアウォールが可用性ゾーンにまたがってデプロイされるように構成する方法はありません。 Azure Firewall を削除してから再デプロイする必要があります。
Virtual WAN の概念はグローバルですが、実際の Virtual WAN リソースは Resource Manager ベースであり、リージョンでデプロイされます。 仮想 WAN リージョン自体に問題がある場合、その仮想 WAN 内のすべてのハブは引き続きそのまま機能しますが、ユーザーは、仮想 WAN リージョンが使用可能になるまで新しいハブを作成することはできません。
保護されたハブ内のファイアウォールを他のハブと共有できますか?
いいえ、できません。各 Azure Virtual Hub には独自のファイアウォールが必要です。 別のセキュリティで保護されたハブのファイアウォールを指すカスタム ルートのデプロイは失敗し、正常に完了しません。 これらのハブを、独自のファイアウォールでセキュリティで保護されたハブに変換することを検討してください。
Azure Virtual WAN ユーザー VPN (ポイント対サイト) ではどのクライアントがサポートされていますか?
Virtual WAN では Azure VPN クライアント、OpenVPN クライアント、または任意の IKEv2 クライアントがサポートされています。 Azure VPN クライアントでは、Microsoft Entra 認証がサポートされています。最小要件の Windows 10 クライアント OS バージョン 17763.0 以降が必要です。 OpenVPN クライアントでは、証明書ベースの認証をサポートできます。 ゲートウェイで証明書ベースの認証が選択されると、ご利用のデバイスにダウンロードできる .ovpn* ファイルが表示されます。 IKEv2 では、証明書と RADIUS の両方の認証がサポートされます。
ユーザー VPN (ポイント対サイト) の場合、P2S クライアント プールが 2 つのルートに分割されるのはなぜですか?
各ゲートウェイには 2 つのインスタンスがあります。 接続されたクライアントに対して各ゲートウェイ インスタンスが個別にクライアント IP を割り当てることができ、仮想ネットワークからのトラフィックを適切なゲート ウェイ インスタンスに戻るようルーティングしてゲートウェイ インスタンス間のホップを避けるために分割が行われます。
P2S クライアント用の DNS サーバーを追加するにはどうすればよいですか。
P2S クライアント用の DNS サーバーを追加するには、2つのオプションがあります。 クライアントではなく、ゲートウェイにカスタム DNS サーバーを追加する場合は、最初の方法が優先されます。
次の PowerShell スクリプトを使用して、カスタム DNS サーバーを追加します。 ご利用の環境に合わせて値を置き換えてください。
// Define variables $rgName = "testRG1" $virtualHubName = "virtualHub1" $P2SvpnGatewayName = "testP2SVpnGateway1" $vpnClientAddressSpaces = $vpnServerConfiguration1Name = "vpnServerConfig1" $vpnClientAddressSpaces = New-Object string[] 2 $vpnClientAddressSpaces[0] = "192.168.2.0/24" $vpnClientAddressSpaces[1] = "192.168.3.0/24" $customDnsServers = New-Object string[] 2 $customDnsServers[0] = "7.7.7.7" $customDnsServers[1] = "8.8.8.8" $virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName $vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name // Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers // Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway $P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName $updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers // Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns serversまたは、Windows 10 向けに Azure VPN クライアントを使用している場合は、ダウンロードしたプロファイル XML ファイルを変更して、<dnsservers><dnsserver></dnsserver></dnsservers> タグを追加してからインポートできます。
<azvpnprofile> <clientconfig> <dnsservers> <dnsserver>x.x.x.x</dnsserver> <dnsserver>y.y.y.y</dnsserver> </dnsservers> </clientconfig> </azvpnprofile>
ユーザー VPN (ポイント対サイト) の場合、サポートされているクライアントの数はいくつですか?
異なるスケール ユニットでサポートされるポイント対サイト VPN ゲートウェイのコンカレント接続数と合計スループットを以下の表に示します。
| スケーリング ユニット | ゲートウェイ インスタンス | サポートされるコンカレント接続数 | 合計スループット |
|---|---|---|---|
| 1 | 2 | 500 | 0.5 Gbps |
| 2 | 2 | 500 | 1 Gbps |
| 3 | 2 | 500 | 1.5 Gbps |
| 4 | 2 | 1000 | 2 Gbps |
| 5 | 2 | 1000 | 2.5 Gbps |
| 6 | 2 | 1000 | 3 Gbps |
| 7 | 2 | 5000 | 3.5 Gbps |
| 8 | 2 | 5000 | 4 Gbps |
| 9 | 2 | 5000 | 4.5 Gbps |
| 10 | 2 | 5000 | 5 Gbps |
| 11 | 2 | 10000 | 5.5 Gbps |
| 12 | 2 | 10000 | 6 Gbps |
| 13 | 2 | 10000 | 6.5 Gbps |
| 14 | 2 | 10000 | 7 Gbps |
| 15 | 2 | 10000 | 7.5 Gbps |
| 16 | 2 | 10000 | 8 Gbps |
| 17 | 2 | 10000 | 8.5 Gbps |
| 18 | 2 | 10000 | 9 Gbps |
| 19 | 2 | 10000 | 9.5 Gbps |
| 20 | 2 | 10000 | 10 Gbps |
| 40 | 4 | 20000 | 20 Gbps |
| 60 | 6 | 30000 | 30 Gbps |
| 80 | 8 | 40000 | 40 Gbps |
| 100 | 10 | 50000 | 50 Gbps |
| 120 | 12 | 60000 | 60 Gbps |
| 140 | 14 | 70000 | 70 Gbps |
| 160 | 16 | 80000 | 80 Gbps |
| 180 | 18 | 90000 | 90 Gbps |
| 200 | 20 | 100000 | 100 Gbps |
たとえば、ユーザーが 1 スケール ユニットを選択したとします。 各スケール ユニットはデプロイされた 1 つのアクティブ/アクティブ ゲートウェイを意味し、(この例では 2 つある) インスタンスのそれぞれで最大 500 接続がサポートされます。 ゲートウェイあたり 500 接続 * 2 を取得できますが、このスケール ユニットで 500 ではなく、1,000 を計画することを意味するわけではありません。 推奨される接続数を超えた場合は、余分な 500 の接続が中断される可能性があるため、インスタンスの処理が必要になることがあります。
スケール ユニットが 20 を超えるゲートウェイの場合、追加の高可用性ゲートウェイ インスタンスのペアがデプロイされ、ユーザーを接続するための追加の容量が提供されます。 インスタンスの各ペアは、最大 10,000 人の追加ユーザーをサポートします。 たとえば、100 スケール ユニットのゲートウェイをデプロイすると、5 つのゲートウェイ ペア (合計インスタンス 10 個) がデプロイされ、最大 50,000 人 (10,000 人のユーザー x 5 ゲートウェイ ペア) の同時ユーザーが接続できます。
また、スケール ユニットをスケールアップまたはスケールダウンする場合や、VPN ゲートウェイのポイント対サイト構成を変更する場合に備えて、必ずダウンタイムを計画してください。
Azure Virtual WAN ゲートウェイ スケール ユニットとは何ですか。
スケール ユニットは、仮想ハブにおけるゲートウェイの総スループットを選択するために定義された単位です。 VPN の 1 スケール ユニットは 500 Mbps です。 ExpressRoute の 1 スケール ユニットは 2 Gbps です。 例: VPN の 10 スケール ユニットは 5 Gbps (= 500 Mbps * 10) を意味します。
Azure 仮想ネットワーク ゲートウェイ (VPN ゲートウェイ) と Azure Virtual WAN VPN ゲートウェイの違いは何ですか。
Virtual WAN は、大規模なサイト間接続を提供し、スループット、スケーラビリティ、使いやすさを考慮して構築されています。 Virtual WAN の VPN ゲートウェイにサイトを接続するとき、そのゲートウェイは、"サイト間 VPN" 型のゲートウェイを使用する通常の仮想ネットワーク ゲートウェイとは異なります。 リモート ユーザーを Azure Virtual WAN に接続する場合は、ゲートウェイ タイプ "ポイント対サイト VPN" を使用します。 ポイント対サイト VPN ゲートウェイとサイト間 VPN ゲートウェイは、Azure Virtual WAN ハブ内の別個のエンティティであり、個別にデプロイする必要があります。 同様に、ExpressRoute 回線を Virtual WAN ハブに接続するとき、ExpressRoute ゲートウェイには、"ExpressRoute" タイプのゲートウェイを使用する通常の仮想ネットワーク ゲートウェイとは異なるリソースが使用されます。
Virtual WAN は、VPN と ExpressRoute のどちらについても、最大 20 Gbps の総スループットをサポートします。 また、CPE 支店デバイス パートナーのエコシステムとの接続に関して、Virtual WAN は自動化に対応しています。 CPE 支店デバイスには、自動的にプロビジョニングして Azure Virtual WAN に接続する自動化機能が組み込まれています。 これらのデバイスは、拡大を続ける SD-WAN および VPN パートナーのエコシステムから利用できます。 推奨されるパートナー リストを参照してください。
Virtual WAN と Azure 仮想ネットワーク ゲートウェイは、どんな点が違いますか。
仮想ネットワーク ゲートウェイの VPN は、100 のトンネルに制限されています。 大規模な VPN の場合、接続するには、Virtual WAN を使用する必要があります。 仮想ハブにつき最大 1,000 個の支店接続を、ハブあたり合計 20 Gbps で接続できます。 接続は、オンプレミス VPN デバイスから仮想ハブへのアクティブ/アクティブ型トンネルです。 リージョンにつき複数の仮想ハブを使用することもできます。つまり、1 つの Azure リージョンに複数の Azure Virtual WAN ハブをデプロイし、それぞれに独自のサイト間 VPN ゲートウェイを配置することで、1000 個を超えるブランチを 1 つの Azure リージョンに接続できます。
Virtual WAN ハブ内での推奨されるアルゴリズムと、サイト間インスタンスあたりの毎秒のパケット数はどうなっていますか? インスタンスごとにサポートされるトンネルの数はどれくらいですか? 1 つのトンネルでサポートされる最大スループットはどうなっていますか?
Virtual WAN は、仮想ハブ内の 2 つのアクティブなサイト間 VPN ゲートウェイ インスタンスをサポートします。 つまり、仮想ハブには 2 つの VPN ゲートウェイ インスタンスのアクティブ/アクティブ セットがあります。 メンテナンス操作中は、ユーザーが VPN ゲートウェイの合計スループットの短時間低下を経験する可能性があるという理由で、各インスタンスが 1 つ 1 つアップグレードされます。
VPN Virtual WAN では多くのアルゴリズムをサポートしていますが、最適なパフォーマンスを実現するには、IPSEC 暗号化と整合性の両方のために GCMAES256 をお勧めしています。 AES256 と SHA256 はパフォーマンスが低いと見なされるため、同様のアルゴリズムの種類では、待ち時間やパケット ドロップなどのパフォーマンスの低下が予想されます。
1 秒あたりのパケット数 (PPS) は、インスタンスごとにサポートされるパケットの総数とスループットの要因になります。 これは例を使用すると理解しやすくなります。 たとえば、1 スケール ユニット 500 Mbps のサイト間 VPN ゲートウェイ インスタンスが仮想 WAN ハブにデプロイされているとします。 パケット サイズが 1400 の場合、その VPN ゲートウェイ インスタンスの PPS は "最大で" [(500 Mbps * 1024 * 1024) /8/1400] から 47000 と想定されます。
Virtual WAN には、VPN 接続、リンク接続、トンネルの概念があります。 1 つの VPN 接続は、リンク接続で構成されます。 Virtual WAN では、1 つの VPN 接続に最大 4 つのリンク接続がサポートされます。 各リンク接続は、仮想ハブにデプロイされたアクティブ/アクティブ VPN ゲートウェイの 2 つのインスタンスで終了する 2 つの IPsec トンネルで構成されます。 1 つのアクティブなインスタンスで終了できるトンネルの総数は 1,000 です。これは、そのインスタンスに接続しているすべてのトンネルで 1 つのインスタンスのスループットを集計して使用できることも意味します。 各トンネルには、特定のスループット値もあります。 小さい値のスケール ユニット ゲートウェイに複数のトンネルが接続されている場合は、トンネルごとのニーズを評価し、VPN インスタンスで終了するすべてのトンネルのスループットの集計値である VPN ゲートウェイを計画することをお勧めします。
Virtual WAN でサポートされているさまざまなスケール ユニットの値
| スケール ユニット | トンネルあたりの最大スループット (Mbps) | トンネルあたりの最大 PPS | インスタンスあたりの最大スループット (Mbps) | インスタンスあたりの最大 PPS |
|---|---|---|---|---|
| 1 | 500 | 47K | 500 | 47K |
| 2 | 1000 | 94K | 1000 | 94K |
| 3 | 1500 | 140K | 1500 | 140K |
| 4 | 1500 | 140K | 2000 | 187K |
| 5 | 1500 | 140K | 2500 | 234K |
| 6 | 1500 | 140K | 3000 | 281K |
| 7 | 2300 | 215K | 3500 | 328K |
| 8 | 2300 | 215K | 4000 | 374K |
| 9 | 2300 | 215K | 4500 | 421K |
| 10 | 2300 | 215K | 5000 | 468K |
| 11 | 2300 | 215K | 5500 | 515K |
| 12 | 2300 | 215K | 6000 | 562K |
| 13 | 2300 | 215K | 6500 | 609K |
| 14 | 2300 | 215K | 7000 | 655K |
| 15 | 2300 | 215K | 7500 | 702K |
| 16 | 2300 | 215K | 8000 | 749K |
| 17 | 2300 | 215K | 8500 | 796K |
| 18 | 2300 | 215K | 9000 | 843K |
| 19 | 2300 | 215K | 9500 | 889K |
| 20 | 2300 | 215K | 10000 | 936K |
注意
すべての数値は GCM アルゴリズムに基づいています。
どのデバイス プロバイダー (Virtual WAN パートナー) がサポートされていますか。
現時点で、多くのパートナーが、完全に自動化された Virtual WAN エクスペリエンスをサポートしています。 詳細については、Virtual WAN パートナーに関するページを参照してください。
Virtual WAN パートナーの自動化手順はどのようになっていますか。
パートナーの自動化手順については、Virtual WAN パートナーの自動化に関するページを参照してください。
推奨パートナー デバイスを使用する必要がありますか。
いいえ。 Azure の IKEv2/IKEv1 IPsec サポートのための要件に準拠する、任意の VPN 対応デバイスを使用できます。 また、Virtual WAN には、Azure Virtual WAN への接続を自動化して大規模な IPsec VPN 接続の設定を容易にする、CPE パートナー ソリューションがあります。
Virtual WAN パートナーはどのように Azure Virtual WAN との接続を自動化しますか。
通常、ソフトウェア定義の接続ソリューションでは、コントローラーまたはデバイス プロビジョニング センターを使用してブランチ デバイスを管理します。 コントローラーは、Azure API を使用して、Azure Virtual WAN への接続を自動化できます。 自動化には、支店情報のアップロードや、Azure の構成のダウンロード、Azure 仮想ハブに対する IPsec トンネルの設定、支店デバイスから Azure Virtual WAN への接続の自動設定が含まれます。 何百もの支店が存在する場合は、Virtual WAN CPE パートナーを使用して接続するのが簡単です。オンボーディング エクスペリエンスにより、大規模な IPsec 接続の設定、構成、管理が不要となるためです。 詳細については、「Virtual WAN partner automation」 (Virtual WAN パートナーの自動化) を参照してください。
使用しているデバイスが Virtual WAN パートナー リストにない場合はどうなりますか? Azure Virtual WAN VPN に引き続き接続することはできますか。
はい。デバイスで IPsec IKEv1 または IKEv2 がサポートされている限り接続できます。 Virtual WAN パートナーによって、デバイスから Azure VPN エンドポイントへの接続が自動化されます。 これは、"ブランチ情報のアップロード"、"IPsec と構成"、"接続" などの手順が自動化されることを意味します。 ご利用のデバイスが Virtual WAN パートナーのエコシステムからのものでない場合、手動で Azure の構成を取得し、デバイスを更新して IPsec 接続を設定するなどの面倒な作業が必要になります。
ローンチ パートナー リストに記載されていない新しいパートナーがリストに記載されるには、どうすればよいですか?
すべての仮想 WAN API は OpenAPI です。 Virtual WAN パートナーの自動化に関するドキュメントを参照して、技術的実現可能性を評価することができます。 理想的なパートナーは、IKEv1 または IKEv2 IPsec 接続用にプロビジョニングできるデバイスを持つパートナーです。 前述の自動化ガイドラインに基づいて、会社での CPE デバイスの自動化作業が完了したら、azurevirtualwan@microsoft.com にご連絡いただき、こちら (「azurevirtualwan@microsoft.com」) に一覧表示されるようにしてください。 特定の会社のソリューションが Virtual WAN パートナーとして一覧表示されるようにしたいとお考えのお客様は、azurevirtualwan@microsoft.com に電子メールを送信し、会社の連絡先を Virtual WAN にしてください。
Virtual WAN では SD-WAN デバイスがどのようにサポートされますか。
Virtual WAN パートナーによって、Azure VPN エンドポイントへの IPsec 接続が自動化されます。 Virtual WAN パートナーが SD-WAN プロバイダーである場合、SD-WAN コントローラーで Azure VPN エンドポイントに対する自動化および IPsec 接続が管理されることを意味します。 SD-WAN デバイスに、専用の SD-WAN 機能の Azure VPN ではなく、独自のエンドポイントが必要である場合、SD-WAN エンドポイントを Azure 仮想ネットワークにデプロイし、Azure Virtual WAN と共存させることができます。
Virtual WAN は BGP ピアリングをサポートしていて、NVA を仮想 WAN ハブにデプロイする機能もあります。
1 つのハブにはいくつの VPN デバイスを接続できますか。
1 つの仮想ハブにつき、最大で 1,000 件の接続がサポートされます。 各接続は 4 つのリンクから成り、各リンク接続は、アクティブ/アクティブ構成の 2 つのトンネルをサポートします。 トンネルは、Azure 仮想ハブの VPN ゲートウェイで終了します。 リンクは、ブランチまたは VPN デバイスの物理的な ISP リンクを表します。
Azure Virtual WAN への支店接続とは
ブランチまたは VPN デバイスから Azure Virtual WAN への接続は、仮想ハブ内の VPN サイトと Azure VPN ゲートウェイ を仮想的に接続する VPN 接続です。
オンプレミスの VPN デバイスに Azure Virtual WAN VPN ゲートウェイへのトンネルが 1 つしかない場合はどうなりますか。
Azure Virtual WAN 接続は、2 つのトンネルから成ります。 Virtual WAN VPN ゲートウェイは、アクティブ/アクティブ モードで仮想ハブにデプロイされます。つまり、オンプレミス デバイスから各インスタンスを終点とするトンネルが別々に存在します。 これは、すべてのユーザーに推奨されます。 ただし、Virtual WAN VPN ゲートウェイ インスタンス 1 つに対してユーザーがトンネルを 1 つしか確保していない場合、なんらかの理由 (メンテナンス、パッチなど) でゲートウェイ インスタンスがオフラインになると、トンネルはセカンダリ アクティブ インスタンスに移動され、再接続が生じることがあります。 BGP セッションは、インスタンス間を移動しません。
Virtual WAN VPN ゲートウェイではゲートウェイのリセットで何が行われますか?
オンプレミスのデバイスがすべて想定どおり動作しているにもかかわらず、Azure のサイト間 VPN 接続が切断状態である場合は、[ゲートウェイのリセット] ボタンを使用する必要があります。 Virtual WAN VPN ゲートウェイは常に、高可用性を確保するためにアクティブ/アクティブ状態でデプロイします。 これは、常に、複数のインスタンスが 1 つの VPN ゲートウェイにデプロイされていることを意味します。 [ゲートウェイのリセット] ボタンを使用すると、VPN ゲートウェイ内のインスタンスが順番に再起動されるので、接続は中断されません。 接続が 1 つのインスタンスから別のインスタンスに移るときに短時間のギャップが生じますが、このギャップは 1 分にも満たないものです。 また、ゲートウェイをリセットしても、パブリック IP は変更されないことに注意してください。
このシナリオは、サイト間接続にのみあてはまります。
オンプレミスの VPN デバイスを複数のハブに接続できますか。
はい。 開始時のトラフィック フローは、オンプレミス デバイスから、最も近い Microsoft ネットワーク エッジへ、次に仮想ハブへとなります。
Virtual WAN 用に使用できる新しい Resource Manager リソースはありますか。
はい。Virtual WAN には新しい Resource Manager リソースがあります。 詳細については、概要に関するページを参照してください。
Azure Virtual WAN で (NVA 仮想ネットワーク内に) 好みのネットワーク仮想アプライアンスをデプロイして使用できますか?
はい、お好みのネットワーク仮想アプライアンス (NVA) の仮想ネットワークを Azure Virtual WAN に接続できます。
仮想ハブ内にネットワーク仮想アプライアンスを作成することはできますか。
ネットワーク仮想アプライアンス (NVA) を仮想ハブ内にデプロイできます。 手順については、「Virtual WAN ハブの NVA について」を参照してください。
スポーク VNet に仮想ネットワーク ゲートウェイを配置することはできますか。
いいえ。 仮想ハブに接続されている場合、スポーク VNet に仮想ネットワーク ゲートウェイを配置することはできません。
スポーク仮想ネットワークに Azure Route Server を配置できますか?
不正解です。 仮想 WAN ハブに接続されている場合、スポーク仮想ネットワークに Azure Route Server を配置することはできません。
VPN 接続で BGP はサポートされていますか。
はい。BGP はサポートされています。 VPN サイトを作成するときに、BGP パラメーターをそこに指定することができます。 これは、そのサイトの Azure で作成されたすべての接続が BGP に対して有効になることを意味します。
Virtual WAN のライセンス情報や価格情報はありますか。
はい。 価格に関するページを参照してください。
Resource Manager テンプレートを使用して Azure Virtual WAN を構築することはできますか。
1 つのハブを持つ 1 つの Virtual WAN と、1 つの vpnsite から成るシンプルな構成は、クイックスタート テンプレートを使用して作成できます。 Virtual WAN は、主として REST またはポータルによって駆動されるサービスです。
仮想ハブに接続されているスポーク VNet は相互に通信 (V2V 転送) できますか。
はい。 Standard Virtual WAN では、VNet が接続されている Virtual WAN ハブを介して、VNet 間の推移的な接続がサポートされています。 Virtual WAN の用語では、これらのパスを、VNet が単一のリージョン内の Virtual WAN ハブに接続されている場合は "ローカル Virtual WAN VNet 転送" と呼び、VNet が 2 つ以上のリージョンにまたがる複数の Virtual WAN ハブを通じて接続されている場合は "グローバル Virtual WAN VNet 転送" と呼びます。
一部のシナリオでは、ローカルまたはグローバルの Virtual WAN VNet 転送に加えて、仮想ネットワーク ピアリングを使用して、スポーク VNet を相互に直接ピアリングすることもできます。 この場合、VNet ピアリングは、Virtual WAN ハブを介した推移的な接続よりも優先されます。
Virtual WAN では、支店間接続を行うことができますか?
はい。Virtual WAN では、支店間接続が利用可能です。 ブランチは、概念的には VPN サイト、ExpressRoute 回線、またはポイント対サイト (ユーザー VPN) ユーザーに適用されます。 ブランチ間の有効化は既定で有効になっており、WAN の [構成] 設定で確認できます。 これにより、VPN ブランチまたはユーザーが他の VPN ブランチに接続できるようになります。また、VPN および ExpressRoute ユーザーの間での転送接続性が有効になります。
支店間トラフィックは、Azure Virtual WAN を横断しますか。
はい。 支店間トラフィックは、Azure Virtual WAN を横断します。
Virtual WAN では、各サイトからの ExpressRoute が必要ですか。
いいえ。 この Virtual WAN では、各サイトからの ExpressRoute は不要です。 サイトは、ExpressRoute 回線を使ってプロバイダーのネットワークに接続される場合があります。 仮想ハブへの ExpressRoute および同じハブへの IPsec VPN を使用して接続されているサイトの場合、仮想ハブで VPN および ExpressRoute ユーザー間の転送接続性が提供されます。
Azure Virtual WAN を使用する場合、ネットワーク スループットまたは接続に制限はありますか。
ネットワーク スループットは、仮想 WAN ハブのサービスごとにあります。 各ハブでは、VPN の総スループットは最大 20 Gbps、ExpressRoute の総スループットは最大 20 Gbps、ユーザー VPN (ポイント対サイト) VPN の総スループットは最大 200 Gbps となります。 仮想ハブのルーターでは、VNet 対 VNet のトラフィック フローに対して最大 50 Gbps がサポートされ、単一の仮想ハブに接続されているすべての VNet で合計 2,000 の VM ワークロードが想定されます。
より多くのスループットが必要なときに仮想ハブがスケールアウトするのを待たずに、前もって容量を確保するために、最小容量を設定するか、必要に応じて変更することができます。 「仮想ハブの設定について - ハブ容量」を参照してください。 コストへの影響については、Azure Virtual WAN の価格に関するページの「ルーティング インフラストラクチャ ユニット」のコストを参照してください。
VPN サイトでは、ハブに接続するときに、複数の接続を使用します。 Virtual WAN では、仮想ハブあたり最大 1,000 の接続または 2,000 の IPsec トンネルがサポートされます。 リモート ユーザーは、仮想ハブに接続するときに、P2S VPN ゲートウェイに接続します。これにより、仮想ハブの P2S VPN ゲートウェイに対して選択されたスケール ユニット (帯域幅) に応じて、最大 100,000 のユーザーがサポートされます。
VPN 接続で NAT-T を使用できますか。
はい。NAT トラバーサル (NAT-T) がサポートされています。 Virtual WAN VPN ゲートウェイでは、NAT に類似する機能が IPsec トンネルとの間の内部パケットに対して実行されることはありません。 この構成では、オンプレミスのデバイスによって IPsec トンネルが開始されるようにします。
20 Gbps などの特定の設定に合わせてスケール ユニットを構成するにはどうすればよいですか?
ポータルでハブ内の VPN ゲートウェイに移動し、スケール ユニットをクリックして適切な設定に変更します。
Virtual WAN では、オンプレミス デバイスで複数の ISP を並行して利用できますか、それとも常に単一の VPN トンネルとなりますか。
オンプレミスのデバイス ソリューションでは、トラフィック ポリシーを適用して、Azure Virtual WAN ハブ (仮想ハブの VPN ゲートウェイ) への複数のトンネルにまたがるトラフィックを操作できます。
グローバル トランジット アーキテクチャとは何ですか。
詳細については、「グローバル トランジット ネットワーク アーキテクチャと Virtual WAN」を参照してください。
Azure バックボーン上では、トラフィックはどのようにルーティングされますか。
トラフィックは、支店のデバイス -> ISP -> Microsoft ネットワーク エッジ -> Microsoft DC (ハブ VNet) -> Microsoft ネットワーク エッジ -> ISP -> 支店のデバイスというパターンに従います
このモデルでは、各サイトでどのようなものが必要ですか。 インターネット接続は必要ですか。
はい。 IPsec をサポートするインターネット接続および物理デバイスが必要です。統合 Virtual WAN パートナーが提供するものをお勧めします。 必要に応じて、好みのデバイスから、構成と Azure への接続を手動で管理できます。
接続 (VPN、ExpressRoute、または VNet) の既定のルート (0.0.0.0/0) を有効にするにはどうすればよいですか?
仮想ハブは、仮想ネットワーク、サイト間 VPN、または ExpressRoute 接続に対し、学習した既定のルートを伝達することができます (対応するフラグが、その接続で "有効" になっている場合)。 このフラグは、ユーザーが仮想ネットワーク接続、VPN 接続、または ExpressRoute 接続を編集するときに表示されます。 サイトまたは ExpressRoute 回線がハブに接続されると、このフラグは既定で無効になります。 VNet を仮想ハブに接続するための仮想ネットワーク接続が追加されたときは、既定で有効になります。
既定のルートの起点は Virtual WAN ハブではありません。Virtual WAN ハブにファイアウォールをデプロイした結果としてそのハブが既定のルートを既に学習している場合、または接続されている別のサイトで強制トンネリングが有効な場合に、既定のルートが伝達されます。 既定のルートはハブ間 (inter-hub) で伝達されません。
同じリージョンで複数の仮想 WAN ハブを作成できますか。
はい。 お客様は同じ Azure Virtual WAN に対して、同じリージョンで複数のハブを作成できるようになりました。
仮想 WAN 内の仮想ハブは、どのようにして複数のハブからのルートに最適なパスを選択するのですか。
詳細については、「仮想ハブのルーティング設定の」を参照してください。
Virtual WAN ハブで ExpressRoute 回線間の接続性は許可されますか。
ER 間の転送は常に Global Reach 経由で行われます。 仮想ハブ ゲートウェイは、DC または Azure リージョンにデプロイされます。 2 つの ExpressRoute 回線が Global Reach 経由で接続されている場合、トラフィックがエッジ ルーターから仮想ハブ DC まで到達する必要はありません。
Azure Virtual WAN ExpressRoute 回線または VPN 接続に重みの概念はありますか。
複数の ExpressRoute 回線が仮想ハブに接続されている場合、接続のルーティングの重みによって、仮想ハブ内の ExpressRoute で一方の回線をもう一方より優先するメカニズムが提供されます。 VPN 接続に重みを設定するメカニズムはありません。 Azure では常に、1 つのハブ内の VPN 接続より ExpressRoute 接続が優先されます。
Virtual WAN では、Azure から送信されるトラフィックに対して、VPN より ExpressRoute が優先されますか。
はい。 Virtual WAN では、Azure から送信されるトラフィックに対して、VPN より ExpressRoute が優先されます。 ただし、仮想ハブのルーティングの優先順位を構成して、既定の優先順位を変更できます。 手順については、「仮想ハブのルーティングの優先順位を構成する」を参照してください。
Virtual WAN ハブに ExpressRoute 回線と VPN サイトが接続されている場合、VPN 接続ルートが ExpressRoute より優先される原因は何ですか?
ExpressRoute 回線が仮想ハブに接続されている場合、Microsoft Edge ルーターは、オンプレミスと Azure の間の通信での最初のノードになります。 これらのエッジ ルーターは、Virtual WAN ExpressRoute ゲートウェイと通信します。次に、Virtual WAN のあらゆるゲートウェイの間のルートをすべて制御する仮想ハブ ルーターからルートを学習します。 Microsoft Edge ルーターは、オンプレミスから学習したルートより高い優先順位である仮想ハブ ExpressRoute ルートを処理します。
なんらかの理由により、仮想ハブがルートを学習するためのプライマリ メディアに VPN 接続がなった場合は (ExpressRoute と VPN の間のフェールオーバー シナリオなど)、VPN サイトの AS パスが長い場合を除き、仮想ハブは引き続き ExpressRoute ゲートウェイと VPN 学習ルートを共有します。 これにより、Microsoft Edge ルーターでは、オンプレミス ルートより VPN ルートが優先されます。
2 つのハブ (ハブ 1 と 2) が接続されていて、両方のハブに対して (蝶ネクタイのような形で) 接続されている ExpressRoute 回線がある場合、ハブ 2 に接続されている VNet に到達するために、ハブ 1 に接続されている VNet のパスはどのようなものですか?
現在の動作では、VNet 対 VNet 接続の場合、ハブ間よりも ExpressRoute 回線パスが優先されます。 しかし、これは Azure Virtual WAN セットアップではお勧めできません。 これを解決するには、次の 2 つのいずれかを行うことができます。
複数の ExpressRoute 回線 (異なるプロバイダー) を 1 つのハブに接続するように構成し、リージョン間のトラフィック フローに対して Azure Virtual WAN によって提供されるハブ間接続を使用します。
仮想ハブのハブ ルーティング設定としてAS-Path を構成します。 これにより、2 つのハブ間のトラフィックは各ハブ内の Virtual hub ルーターを通過し、ExpressRoute パスではなくハブからハブへのパスを使用するようになります (これは、Microsoft Edge ルーターを通過します)。 詳細については、「仮想ハブのルーティングの優先順位を構成する」を参照してください。
Virtual WAN ハブとスタンドアロン VNet に蝶ネクタイ状に接続されている ExpressRoute 回線がある場合、スタンドアロン VNet が Virtual WAN ハブに到達するためのパスは何ですか?
新しいデプロイの場合、この接続は既定でブロックされます。 この接続を許可するには、ポータルの [仮想ハブの編集] ブレードと [仮想ネットワーク ゲートウェイ] ブレードで、これらの ExpressRoute ゲートウェイのトグルを有効にします。 ただし、これらのトグルを無効のままにし、代わりにスタンドアロン VNet を Virtual WAN ハブに直接接続する仮想ネットワーク接続を作成することをお勧めします。 その後、VNet から VNet へのトラフィックは Virtual WAN ハブ ルーターを経由します。これにより、ExpressRoute パスよりもパフォーマンスが向上します。 ExpressRoute パスには、ハブ ルーターよりも帯域幅制限が低い ExpressRoute ゲートウェイと、データパスの追加ホップである Microsoft Enterprise Edge ルーター/MSEE が含まれます。
次の図では、これらのトグルの両方が有効になっている場合、スタンドアロン VNet 4 と、ハブ 2 に直接接続されている VNet (VNet 2 と VNet 3) の間で接続が許可されます。仮想ネットワーク ゲートウェイのリモート Virtual WAN ネットワークからのトラフィックを許可し、仮想ハブの ExpressRoute ゲートウェイに対し非 Virtual WAN ネットワークからのトラフィックを許可します。 Azure Route Server がスタンドアロン VNet 4 にデプロイされ、Route Server で [ブランチ間] が有効になっている場合、VNet 1 とスタンドアロン VNet 4 の間の接続はブロックされます。
トグルを有効または無効にすると、Virtual WAN ハブと ExpressRoute 回線経由のスタンドアロン VNet の間を流れるトラフィックのトラフィック フローにのみ影響します。 トグルを有効または無効にしても、他のすべてのトラフィック フローにダウンタイムは発生しません (たとえば、オンプレミスのサイトからスポーク VNet 2 は影響を受けません。VNet 2 から VNet 3 への影響はありません)。
ハブは、Virtual WAN 内の別のリソース グループに作成できますか。
はい。 このオプションは、現在、PowerShell を介してのみ使用可能です。 Virtual WAN ポータルでは、ハブが仮想 WAN リソース自体と同じリソース グループに含まれている必要があります。
ハブの作成時に推奨されるハブのアドレス空間は何ですか。
推奨される Virtual WAN ハブのアドレス空間は /23 です。 Azure Virtual WAN ハブは、さまざまなゲートウェイ (ExpressRoute、サイト間 VPN、ポイント対サイト VPN、Azure Firewall、仮想ハブ ルーター) にサブネットを割り当てます。 NVA が仮想ハブ内にデプロイされているシナリオでは、通常、NVA インスタンスに対して /28 が分割されます。 ただし、ユーザーが複数の NVA をプロビジョニングする場合は、/27 サブネットが割り当てられる可能性があります。 そのため、将来のアーキテクチャを念頭に置いて、Virtual WAN ハブのデプロイには /24 の最小サイズが使用されていますが、作成時にユーザーが入力するハブのアドレス空間の推奨値は /23 です。
Virtual WAN に IPv6 のサポートはありますか。
IPv6 は、Virtual WAN ハブとそのゲートウェイではサポートされていません。 IPv4 および IPv6 をサポートする VNet があり、その VNet を Virtual WAN に接続する必要がある場合、このシナリオは現在サポートされていません。
Azure Firewall 経由のインターネット ブレークアウトを使用したポイント対サイトのユーザー VPN シナリオでは、おそらく、仮想 WAN ハブに対してトラフィックを強制するために、クライアント デバイスの IPv6 接続性を無効にする必要があります。 最近のデバイスでは、IPv6 アドレスが既定で使用されるためです。
さまざまな Virtual WAN 機能を自動化するスクリプトで使用される、推奨される API バージョンは何ですか。
最小バージョンとして 05-01-2022 (2022 年 5 月 1 日) が必要です。
Virtual WAN には制限がありますか。
サブスクリプションとサービスの制限に関するページの「Virtual WAN の制限」のセクションを参照してください。
Basic タイプの Virtual WAN と Standard タイプの Virtual WAN の違いは何ですか。
「Basic および Standard の仮想 WAN」を参照してください。 価格については、価格ページを参照してください。
Virtual WAN に顧客データは格納されますか?
いいえ。 Virtual WAN にお客様のデータは一切格納されません。
ユーザーに代わって Virtual WAN をサービスとして管理できるマネージド サービス プロバイダーはありますか?
はい。 Azure Marketplace から利用できるマネージド サービス プロバイダー (MSP) ソリューションの一覧については、「Azure ネットワーク MSP パートナーによる Azure Marketplace のオファー」を参照してください。
Azure Virtual WAN ハブのルーティングは、VNet の Azure Route Server とどう違うのですか?
Azure Virtual WAN ハブと Azure Route Server はどちらも、NVA (ネットワーク仮想アプライアンス) が NVA からユーザーの Azure 仮想ネットワークに IP アドレスを公開するために利用できる Border Gateway Protocol (BGP) ピアリング機能を提供します。 デプロイ オプションは、Azure Route Server が通常、自己管理型の顧客ハブ VNet によってデプロイされるという点で異なります。一方、Azure Virtual WAN では、顧客がさまざまなスポークのエンド ポイント (Azure VNet、サイト間 VPN または SDWAN を使用するオンプレミス ブランチ、ポイント対サイト/リモート ユーザー VPN と ExpressRoute によるプライベート接続を使用するリモート ユーザー) を接続するゼロタッチの完全メッシュ ハブ サービスが提供されます。後者はさらに、スポーク VNet にデプロイされた NVA の BGP ピアリングのほか、VNet 間のトランジット接続、VPN と ExpressRoute 間のトランジット接続、カスタム/高度なルーティング、カスタム ルートの関連付けと伝達、手間のかからないリージョン間のセキュリティのためのルーティングの意図/ポリシー、Secure Hub/Azure ファイアウォールなどの vWAN 機能も提供します。Virtual WAN BGP ピアリングの詳細については、BGP と仮想ハブをピアリングする方法に関するページを参照してください。
サード パーティのセキュリティ プロバイダー (Zscaler、iBoss、または Checkpoint) を使用してインターネット トラフィックをセキュリティで保護している場合、Azure portal でサード パーティのセキュリティ プロバイダーに関連付けられている VPN サイトが表示されないのはなぜですか?
ユーザーのインターネット アクセスを保護するためにセキュリティ パートナー プロバイダーをデプロイすることを選択すると、サードパーティのセキュリティ プロバイダーによって、ユーザーに代わって VPN サイトが作成されます。 サードパーティのセキュリティ プロバイダーはプロバイダーによって自動的に作成され、ユーザーが作成した VPN サイトではないため、この VPN サイトは Azure portal に表示されません。
使用可能なオプションのサードパーティのセキュリティ プロバイダーとその設定方法の詳細については、「セキュリティ パートナー プロバイダーのデプロイ」を参照してください。
オンプレミスで生成された BGP コミュニティは Virtual WAN で保持されますか?
はい、オンプレミスで生成された BGP コミュニティは Virtual WAN で保持されます。 オンプレミスのネットワークに対して独自のパブリック ASN 番号またはプライベート ASN 番号を使用できます。 Azure または IANA によって予約されている範囲は使用できません。
- Azure によって予約済みの ASN:
- パブリック ASN: 8074, 8075, 12076
- プライベート ASN: 65515、65517、65518、65519、65520
- IANA によって予約済みの ASN: 23456、64496-64511、65535-65551
VPN Gateway の ASN を変更する方法はありますか?
いいえ。 Virtual WAN では、VPN ゲートウェイの ASN の変更はサポートされていません。
Virtual WAN では、ExpressRoute ゲートウェイ SKU の推定パフォーマンスはどれだけですか?
| スケール ユニット | 1 秒あたりの接続数 | 1 秒あたりのメガビット数 | 1 秒あたりのパケット数 |
|---|---|---|---|
| 1 スケール ユニット |
14,000 | 2,000 | 200,000 |
| 2 スケール ユニット |
28,000 | 4,000 | 400,000 |
| 3 スケール ユニット |
42,000 | 6,000 | 600,000 |
| 4 スケール ユニット |
56,000 | 8,000 | 800,000 |
| 5 スケール ユニット |
70,000 | 10,000 | 1,000,000 |
| 6 スケール ユニット |
84,000 | 12,000 | 1,200,000 |
| 7 スケール ユニット |
98,000 | 14,000 | 1,400,000 |
| 8 スケール ユニット |
112,000 | 16,000 | 1,600,000 |
| 9 スケール ユニット |
126,000 | 18,000 | 1,800,000 |
| 10 スケール ユニット |
140,000 | 20,000 | 2,000,000 |
スケール ユニット 2 から 10 では、メンテナンス操作中、合計スループットを維持します。 ただし、スケール ユニット 1 では、メンテナンス操作中、スループットの数値に若干のばらつきがある場合があります。
ExpressRoute ローカル回線を Virtual WAN ハブに接続した場合、アクセスできるのはローカル回線と同じ都市圏の場所にあるリージョンだけですか?
ローカル回線は、対応する Azure リージョンにある ExpressRoute ゲートウェイにのみ接続できます。 ただし、他のリージョンにあるスポーク仮想ネットワークへのトラフィックのルーティングに関する制限はありません。
ポータルに "Update router to latest software version" (ルーターを最新のソフトウェア バージョンに更新する) というメッセージとボタンがポータルに表示されるのはなぜですか?
Note
2024 年 1 月の時点で、Virtual WAN チームは仮想ハブの最新バージョンへのアップグレードを開始しています。 ハブをアップグレードしなかったが、ハブのルーター バージョンに "最新" と表示された場合、お使いのハブは Virtual WAN チームによってアップグレードされました。
Azure 全体の Cloud Services ベースのインフラストラクチャは非推奨となっています。 その結果、Virtual WAN チームは、仮想ルーターを現在の Cloud Services インフラストラクチャから Virtual Machine Scale Sets ベースのデプロイにアップグレードする作業を行っています。 新しく作成されたすべての仮想ハブは、最新の Virtual Machine Scale Sets ベースのインフラストラクチャに自動的にデプロイされます。 Virtual WAN ハブ リソースに移動して、このメッセージとボタンが表示される場合は、ボタンをクリックしてルーターを最新バージョンにアップグレードできます。 ハブとの BGP ピアリングなど、新しい仮想 WAN 機能を利用する場合は、Azure portal を使用して仮想ハブ ルーターを更新する必要があります。 ボタンが表示されない場合は、サポート ケースを開いてください。
ハブ内のすべてのリソース (ゲートウェイ/ルート テーブル/VNet 接続) が成功状態である場合にのみ、仮想ハブ ルーターを更新できます。 すべてのスポーク仮想ネットワークがアクティブまたは有効なサブスクリプションにあり、スポーク仮想ネットワークが削除されていないことを確認してください。 さらに、この操作では新しい仮想マシン スケール セット ベースの仮想ハブ ルーターのデプロイが必要になるので、同じハブ経由の VNet 間トラフィックでは 1 分から 2 分、ハブを経由する他のすべてのトラフィック フローでは 5 分から 7 分のダウンタイムが予想されます。 1 つの Virtual WAN 内では、複数のハブを同時に更新するのではなく、ハブを一度に 1 つずつ更新する必要があります。 ルーターのバージョンが "最新" と表示されている場合、ハブの更新は完了です。 この更新後にルーティングの動作変更が行われることはありません。
仮想ハブ ルーターのアップグレードには注意すべき点がいくつかあります。
Virtual WAN ハブとスポーク VNet 内の NVA の間で BGP ピアリングを既に構成している場合は、BGP ピアを削除してから再作成する必要があります。 アップグレード後に仮想ハブ ルーターの IP アドレスが変更されるため、仮想ハブ ルーターの新しい IP アドレスとピアリングするように NVA を再構成する必要もあります。 これらの IP アドレスは、仮想ハブのリソース JSON の "virtualRouterIps" フィールドとして表されます。
仮想ハブにネットワーク仮想アプライアンス (NVA) がある場合、NVA パートナーと協力し、Virtual WAN ハブをアップグレードする方法の手順を確認する必要があります。
仮想ハブが 15 を超えるルーティング インフラストラクチャ ユニットで構成されている場合は、アップグレードを試みる前に、仮想ハブを 2 つのルーティング インフラストラクチャ ユニットにスケールインしてください。 ハブをアップグレードした後に、ハブを 15 を超えるルーティング インフラストラクチャ ユニットにスケールアウトし直すことができます。
何らかの理由で更新に失敗した場合、ハブは古いバージョンに自動的に回復され、動作中のセットアップが存在することが保証されます。
その他の注意事項:
ハブ ルーターのバージョンの正確な状態を確認するには、ユーザーに所有者ロールまたは共同作成者ロールが必要です。 Virtual WAN リソースとサブスクリプションに対する閲覧者ロールがユーザーに割り当てられている場合、Azure portal は、ハブが既に最新バージョンになっている場合でも、ハブ ルーターを最新バージョンにアップグレードする必要があることをユーザーに表示します。
スポーク仮想ネットワークのサブスクリプションの状態を無効から有効に変更してから仮想ハブをアップグレードする場合は、仮想ハブのアップグレード後に仮想ネットワーク接続を更新する必要があります (たとえば、仮想ネットワーク接続をダミー ラベルに伝達するように構成できます)。
ハブが多数 (60 以上) のスポーク仮想ネットワークに接続されている場合、アップグレード後に 1 つ以上のスポーク VNet ピアリングが失敗状態になることに気付くかもしれません。 アップグレード後に、これらの VNet ピアリングを正常な状態に復元するには、ダミー ラベルに伝達するように仮想ネットワーク接続を構成するか、これらのそれぞれの VNet 接続を削除して再作成することができます。
Azure P2S VPN ゲートウェイに接続している OpenVPN クライアントにはルートの制限はありますか?
OpenVPN クライアントのルート制限は 1,000 です。
Virtual WAN SLA はどのように計算されますか?
Azure Virtual WAN は、99.95% の SLA を持つサービスとしてのネットワーク プラットフォームです。 ただし、Azure Virtual WAN では、Azure Firewall、サイト間 VPN、ExpressRoute、ポイント対サイト VPN、Virtual WAN ハブ/統合ネットワーク仮想アプライアンスなど、さまざまなコンポーネントが組み合わせられます。
各コンポーネントの SLA は個別に計算されます。 たとえば、ExpressRoute に 10 分のダウンタイムがある場合、ExpressRoute の可用性は、(最大利用可能時間 (分) - ダウンタイム) / 最大利用可能時間 (分) * 100 として計算されます。
ハブに接続されているスポーク VNet の VNet アドレス空間を変更できますか?
はい。これは、ピアリング接続の更新やリセットを必要とせず、自動的に行うことができます。 VNet アドレス空間を変更する方法の詳細については、こちらを参照してください。
Virtual WAN の顧客が管理するゲートウェイのメンテナンス
ネットワーク ゲートウェイのメンテナンス構成スコープ内に含まれるサービスはどれですか?
Virtual WAN では、サイト間 VPN ゲートウェイと ExpressRoute ゲートウェイのメンテナンス期間を構成できます。
顧客が管理するメンテナンスでサポートされている、またはサポートされていないメンテナンスはどれですか?
Azure サービスでは、機能、信頼性、パフォーマンス、セキュリティを向上させるために、定期的なメンテナンス更新が行われます。 ご利用のリソースにメンテナンス期間を構成すると、その期間中にゲスト OS とサービスのメンテナンスが実行されます。 これらの更新は、顧客が懸念するメンテナンス項目の大部分を占めています。
基になるホスト ハードウェアとデータセンター インフラストラクチャの更新プログラムは、顧客が管理するメンテナンスの対象になりません。 さらに、顧客に危険を及ぼす可能性がある重要度の高いセキュリティの問題が発生している場合、Azure では、メンテナンス期間中の顧客による管理のオーバーライドと、変更のロール アウトが必要となることがあります。 これらはまれな状況であり、極端なケースでのみ使用されます。
メンテナンスの事前通知を受け取ることはできますか?
現時点では、ネットワーク ゲートウェイ リソースのメンテナンスに対して、事前通知を有効にすることはできません。
メンテナンス期間を 5 時間未満で構成することはできますか?
現時点では、優先タイム ゾーン内で最低 5 時間の時間枠を構成する必要があります。
毎日繰り返されないメンテナンス スケジュールを構成できますか?
現時点では、日単位のメンテナンス期間を構成する必要があります。
メンテナンス構成リソースは、ゲートウェイ リソースと同じリージョン内に存在する必要がありますか?
正解です。
お客様が管理するメンテナンスの対象となる最小ゲートウェイ スケール ユニットをデプロイする必要がありますか?
不正解です。
メンテナンス構成ポリシーがゲートウェイ リソースに割り当てられた後、そのメンテナンス構成ポリシーが有効になるまでにどれくらいの時間がかかりますか?
メンテナンス ポリシーがゲートウェイ リソースに関連付けられた後、ネットワーク ゲートウェイがそのメンテナンス スケジュールに従うのに、最大で 24 時間かかる場合があります。
VPN と ExpressRoute を共存シナリオで使用する場合、メンテナンス期間を計画するにはどうすればよいですか?
VPN と ExpressRoute を共存シナリオで使用する場合、またはバックアップとして機能するリソースがある場合は常に、個別のメンテナンス期間を設定することをお勧めします。 このアプローチにより、メンテナンスがご利用のバックアップ リソースへ同時に影響を与えないことが保証されます。
複数あるリソースの 1 つに対して、将来日付のメンテナンス期間をスケジュールしました。 それまで、このリソース上のメンテナンス アクティビティは一時停止されますか?
いいえ。スケジュールされたメンテナンス期間の前の期間中、ご利用のリソース上のメンテナンス アクティビティは一時停止されません。 ご利用のメンテナンス スケジュール内に含まれていない日々には、そのリソースに対して通常どおりメンテナンスが続行されます。
次のステップ
Virtual WAN の詳細については、Virtual WAN の概要に関するページを参照してください。