既存Azure VPN Gatewayをデュアルスタック化する手順｜IPv4を維持してIPv6内部通信を通す

既存のAzure VPN Gatewayは、Standard SKUのPublic IPを使用する本番SKUであれば、現在のIPv4通信を維持しながらIPv6内部トラフィックを同じVPNトンネルへ追加できます。Microsoftの一般提供発表では、新規だけでなく既存のVPN Gatewayも対象です。一方、Basic gateway SKUはIPv6に対応していません。(Microsoft Developer)

ここで重要なのは、VPN Gatewayの公開エンドポイントをIPv6化するわけではない点です。オンプレミスとAzureの間では、従来どおり公開IPv4アドレスを使ってIKEv2/IPsecトンネルを確立し、そのトンネル内部にIPv4とIPv6の両方を流します。つまり、既存のIPv4トンネルを残したまま、IPv6ワークロード用の経路を追加する構成です。(Microsoft Learn)

以下では、既存のSite-to-Site VPNを対象に、VNet、GatewaySubnet、Local Network Gateway、オンプレミスVPN装置、NSG、UDRを順番に変更する手順を解説します。

Azure VPN Gatewayのデュアルスタック化で変わる範囲

デュアルスタック化する対象は、VPN Gatewayの公開IPではなく、VPNトンネル内部とAzure仮想ネットワークです。

構成要素	デュアルスタック化後	既存IPv4の扱い
VPNトンネル外側	公開IPv4でIKEv2/IPsec接続	原則として変更しない
VPNトンネル内側	IPv4とIPv6を通す	IPv4を残したままIPv6を追加
Azure VNet	IPv4とIPv6のアドレス空間	既存IPv4プレフィックスを保持
GatewaySubnet	IPv4サブネットとIPv6 /64	既存IPv4サブネットを保持
ワークロードサブネット	IPv4とIPv6 /64	段階的にIPv6を追加可能
Local Network Gateway	オンプレミス側のIPv4・IPv6プレフィックス	更新時にIPv4を削除しない
オンプレミスVPN装置	IPv6の暗号化対象と経路を追加	既存IPv4ポリシーを維持
NSG・UDR	IPv6用ルールと経路を追加	IPv4ルールとは別に管理

Azure VPN GatewayのIPv6対応は内部トラフィックに限定されており、外側のVPNトンネルにIPv6アドレスを使用する構成ではありません。したがって、VPN Gateway用のIPv6 Public IPを新規作成する必要はありません。(Microsoft Learn)

デュアルスタック化の対象条件

作業前に、既存環境が次の条件を満たしているか確認します。

確認項目	必要な状態	条件を満たさない場合
Gateway SKU	Basic以外の本番SKU	SKU移行またはゲートウェイ再構築を検討
Public IP SKU	Standard	BasicからStandardへ移行
VPNタイプ	Route-based	Policy-basedからはゲートウェイ再作成が必要
S2S接続プロトコル	IKEv2	IKEv1接続を削除してIKEv2で再作成
Azure IPv6サブネット	/64	/64で再設計
アドレス重複	Azureとオンプレミスで重複なし	IPアドレス計画を修正
オンプレミスVPN装置	IPv6内部通信とIKEv2に対応	ファームウェア更新や装置交換を検討
Active-active構成	両方のAzure公開IPへ接続	2本目のトンネルを追加

Site-to-Site VPNでIPv6内部通信を利用するには、Route-based VPN GatewayとIKEv2が必要です。IKEv1とIKEv2は接続作成後に切り替えられないため、IKEv1を使用している場合は接続リソースを削除し、IKEv2で作り直します。ゲートウェイ全体を作り直す必要があるとは限りませんが、接続の再作成中は通信が中断します。(Microsoft Learn)

Basic Public IPを使用している場合は、先にStandard Public IPへの移行が必要です。Microsoftの案内では、VPN GatewayのPublic IP移行時に最大10分程度のダウンタイムが発生する可能性があります。すでにStandard Public IPであれば、この移行作業は不要です。(Microsoft Learn)

対象SKUに関する注意

一般提供の発表では、Standard Public IPを使うすべての本番SKUが対象とされています。一方、Microsoft Learnの構成ページには、執筆時点で「VpnGw1AZからVpnGw5AZ」という一般提供前の記載が残っています。実際の変更前には、対象サブスクリプションとリージョンでポータルまたはAzure CLIの入力検証を行い、最新の一般提供条件を優先して判断してください。(Microsoft Developer)

IPv6アドレスを先に設計する

IPv6はアドレス数が非常に多いため、IPv4のように小さく切り詰める必要はありません。Microsoftは、VNetに/56、各サブネットに/64を割り当てる構成を推奨しています。AzureのIPv6サブネットは必ず/64で作成します。(Microsoft Learn)

次は、既存環境へ追加する場合の設計例です。

用途	IPv4の例	IPv6の例
Azure VNet	`10.10.0.0/16`	`fd12:3456:789a:1200::/56`
GatewaySubnet	`10.10.255.0/27`	`fd12:3456:789a:12ff::/64`
アプリ用サブネット	`10.10.10.0/24`	`fd12:3456:789a:1201::/64`
管理用サブネット	`10.10.20.0/24`	`fd12:3456:789a:1202::/64`
オンプレミスネットワーク	`172.20.0.0/16`	`fd12:3456:abcd::/48`

このIPv6アドレスは説明用です。そのまま本番環境へコピーせず、組織のIPAMやアドレス管理台帳に基づいて割り当ててください。

インターネットへ公開しない内部通信では、fc00::/7のUnique Local Addressを使用できます。ただし、別組織や将来統合するネットワークと重複すると接続が難しくなるため、Azure、拠点、データセンターごとに重複しないプレフィックスを計画します。(Microsoft Learn)

既存Azure VPN Gatewayをデュアルスタック化する手順

現在のVPN Gateway設定を確認する

最初に、Gateway SKU、VPNタイプ、Active-activeの有無、接続プロトコル、VNetアドレス空間、GatewaySubnet、Local Network Gatewayのプレフィックスを記録します。

Azure Cloud ShellのBashでは、次のように確認できます。

RG="rg-hub-prod"
VNET="vnet-hub-prod"
GW="vng-hub-prod"
LNG="lng-onprem-prod"
CONN="conn-onprem-prod"

az network vnet-gateway show \
  --resource-group "$RG" \
  --name "$GW" \
  --query "{
    sku:sku.name,
    vpnType:vpnType,
    activeActive:activeActive,
    provisioningState:provisioningState
  }" \
  --output json

az network vpn-connection show \
  --resource-group "$RG" \
  --name "$CONN" \
  --query "{
    connectionProtocol:connectionProtocol,
    connectionStatus:connectionStatus,
    provisioningState:provisioningState
  }" \
  --output json

az network vnet show \
  --resource-group "$RG" \
  --name "$VNET" \
  --query "addressSpace.addressPrefixes" \
  --output json

az network vnet subnet show \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --name "GatewaySubnet" \
  --query "addressPrefixes" \
  --output json

az network local-gateway show \
  --resource-group "$RG" \
  --name "$LNG" \
  --query "localNetworkAddressSpace.addressPrefixes" \
  --output json

VPN Gatewayに関連付けられているPublic IPのSKUも確認します。

for id in $(az network vnet-gateway show \
  --resource-group "$RG" \
  --name "$GW" \
  --query "ipConfigurations[].publicIPAddress.id" \
  --output tsv); do

  az network public-ip show \
    --ids "$id" \
    --query "{
      name:name,
      sku:sku.name,
      ipAddress:ipAddress,
      ipVersion:publicIPAddressVersion
    }" \
    --output table
done

変更前の出力はファイルや作業記録へ保存しておきます。特に、VNet、サブネット、Local Network Gatewayに複数のプレフィックスが登録されている環境では、すべての値を控えてください。

IKEv1接続はIKEv2で再作成する

接続のconnectionProtocolがIKEv1の場合、そのままではIPv6内部トラフィックを通せません。

IKEv1からIKEv2への変更はインプレースでは実行できないため、次の情報を保存したうえで接続リソースを再作成します。

共有キー
カスタムIPsec/IKEポリシー
BGPの有無
Policy-based traffic selectorの有無
接続モード
ルーティングウェイト
Local Network Gatewayとの関連付け

再作成時はIKEv2を明示し、Azure側とオンプレミスVPN装置側の暗号化アルゴリズム、DHグループ、PFSグループ、SA有効期間を一致させます。(Microsoft Learn)

VNetへIPv6アドレス空間を追加する

Azureポータルでは、対象VNetを開き、次の順番で設定します。

設定からアドレス空間を開く
IPv6のVNetアドレス空間を追加する
保存する
サブネットを開く
GatewaySubnetを選択する
IPv6アドレス空間として/64を追加する
既存IPv4プレフィックスを残したまま保存する

Azure CLIでは次のように変更できます。

VNET_V4="10.10.0.0/16"
VNET_V6="fd12:3456:789a:1200::/56"

GATEWAY_SUBNET_V4="10.10.255.0/27"
GATEWAY_SUBNET_V6="fd12:3456:789a:12ff::/64"

az network vnet update \
  --resource-group "$RG" \
  --name "$VNET" \
  --address-prefixes \
    "$VNET_V4" \
    "$VNET_V6"

az network vnet subnet update \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --name "GatewaySubnet" \
  --address-prefixes \
    "$GATEWAY_SUBNET_V4" \
    "$GATEWAY_SUBNET_V6"

この例ではVNetのIPv4プレフィックスが1個だけですが、実環境に複数のアドレス空間がある場合は、現在使用しているすべてのIPv4・IPv6プレフィックスを指定してください。IPv6だけを指定すると、既存のアドレス空間を意図せず置き換える可能性があります。

既存環境へのIPv6追加では、VPN Gateway用のIPv6 Public IPを作成する操作はありません。GatewaySubnetをIPv4・IPv6のデュアルスタックにし、内部経路を追加することが中心です。既存VNetへIPv6アドレス空間と/64サブネットを追加する手順は、AzureポータルとAzure CLIの両方で提供されています。(Microsoft Learn)

ワークロードサブネットとNICへIPv6を追加する

GatewaySubnetだけをデュアルスタック化しても、通信先のVMやアプリケーションにIPv6アドレスがなければ通信できません。

アプリ用サブネットへIPv6を追加します。

WORKLOAD_SUBNET="snet-app"
WORKLOAD_SUBNET_V4="10.10.10.0/24"
WORKLOAD_SUBNET_V6="fd12:3456:789a:1201::/64"

az network vnet subnet update \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --name "$WORKLOAD_SUBNET" \
  --address-prefixes \
    "$WORKLOAD_SUBNET_V4" \
    "$WORKLOAD_SUBNET_V6"

続いて、既存VMのNICへIPv6のIP構成を追加します。

NIC="nic-app01"

az network nic ip-config create \
  --resource-group "$RG" \
  --nic-name "$NIC" \
  --name "ipconfig-v6" \
  --private-ip-address-version IPv6 \
  --vnet-name "$VNET" \
  --subnet "$WORKLOAD_SUBNET"

VPN内部通信だけが目的であれば、VMにIPv6 Public IPを割り当てる必要はありません。必要なのは、サブネットとNICに設定されたプライベートIPv6アドレスです。

NICへIPv6を追加した後は、OSとアプリケーションでも次を確認します。

OS上にIPv6アドレスが認識されている
アプリケーションがIPv6アドレスまたは::で待ち受けている
Windows Defender FirewallやLinuxのホストファイアウォールがIPv6通信を許可している
IPv4アドレスでの待ち受け設定が維持されている

既存VMでは、IPv4のIP構成を残したまま、同じNICへIPv6のIP構成を追加できます。(Microsoft Learn)

Local Network GatewayへオンプレミスIPv6プレフィックスを追加する

静的ルーティング構成では、Azureがオンプレミスへ送信すべきIPv6プレフィックスをLocal Network Gatewayへ追加します。

最初に現在のプレフィックスを確認します。

az network local-gateway show \
  --resource-group "$RG" \
  --name "$LNG" \
  --query "localNetworkAddressSpace.addressPrefixes" \
  --output json

既存IPv4プレフィックスを含めた完全な一覧で更新します。

ONPREM_V4="172.20.0.0/16"
ONPREM_V6="fd12:3456:abcd::/48"

az network local-gateway update \
  --resource-group "$RG" \
  --name "$LNG" \
  --local-address-prefixes \
    "$ONPREM_V4" \
    "$ONPREM_V6"

--local-address-prefixesは、既存プレフィックスへ単純に追記するオプションではありません。指定した一覧で現在のプレフィックスを置き換えます。複数拠点や複数セグメントがある場合は、残すべきIPv4とIPv6のプレフィックスをすべて指定してください。(Microsoft Learn)

Active-active構成や複数拠点構成でLocal Network Gatewayが複数ある場合は、該当するすべてのLocal Network Gatewayを確認します。

BGPを使用している環境では、Local Network Gatewayのアドレス空間へ静的プレフィックスを追加する前に、既存のBGP設計を確認してください。Local Network Gatewayのアドレス空間に登録したプレフィックスは、BGPで学習した経路とは別に静的経路として追加されます。BGP構成では、Azure側とオンプレミス側の両方でIPv6経路が広告・学習されていることを有効なルートで確認します。(Microsoft Learn)

オンプレミスVPN装置へIPv6設定を追加する

オンプレミスVPN装置では、既存の公開IPv4ピアを変更せず、VPNトンネル内部で扱うIPv6ネットワークを追加します。

主な変更項目は次のとおりです。

VPNプロトコルをIKEv2にする
Azure VNetのIPv6プレフィックスをVPN経由の宛先に追加する
オンプレミス側IPv6プレフィックスをVPNの送信元として追加する
IPv6プレフィックスの経路をIPsecトンネルへ向ける
カスタムTraffic Selectorを使用している場合はIPv6プレフィックスを追加する
IPv6用のファイアウォールポリシーを追加する
Active-active構成ではAzure側の両方の公開IPv4アドレスへ接続する

装置によって設定名称は異なります。一般的には「Encryption Domain」「Proxy ID」「Local/Remote Network」「Traffic Selector」「Protected Network」などの名称で、IPv6プレフィックスを登録します。

Route-based VPN装置では、トンネルインターフェイスに対するIPv6経路とファイアウォールポリシーの追加が中心です。Policy-based traffic selectorを有効にしている接続では、Azure側の接続設定にもIPv6プレフィックスを追加する必要があります。

Azure VPN Gatewayの外側は引き続きIPv4であり、IPv6はIKEv2トンネルの内側だけを通ります。Active-active構成では、両方のゲートウェイインスタンスへトンネルを確立することで冗長性を確保します。(Microsoft Learn)

NSG、UDR、VNetピアリングをIPv6対応にする

VPN GatewayがIPv6を通せる状態でも、途中のNSGやUDRがIPv4専用のままでは通信できません。

対象	確認内容
NSG	オンプレミスIPv6プレフィックスから必要なポートを許可する
UDR	オンプレミスIPv6宛ての経路や`::/0`の転送先を確認する
BGP伝播	ルートテーブルでBGPルート伝播を無効化していないか確認する
NVA・ファイアウォール	IPv6転送とステートフル検査に対応しているか確認する
VNetピアリング	追加したIPv6アドレス空間を同期する
DNS	通信確認後に必要なAAAAレコードを追加する

IPv4の0.0.0.0/0ルートはIPv6の通信には適用されません。IPv6でも強制トンネリングを行う場合は、設計に応じて::/0の経路が必要です。ただし、次ホップとなるNVAやファイアウォールがIPv6に対応していなければ、IPv6通信はそこで停止します。

Azure Virtual Networkは、IPv6用のNSGルールとユーザー定義ルートに対応しています。Hub-and-Spoke構成では、Hubだけでなく、通信対象となるSpoke VNet、サブネット、NICにもIPv6を追加し、IPv6用UDRを確認します。(Microsoft Learn)

VNetにIPv6アドレス空間を追加した場合、既存のVNetピアリングを同期します。

az network vnet peering sync \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --name "peer-hub-to-spoke01"

接続している各VNet側でも、ピアリングが新しいIPv6アドレス空間を認識しているか確認します。アドレス空間の追加後にピアリングを同期しないと、新しいIPv6プレフィックスへのルートが反映されないことがあります。(Microsoft Learn)

IPv6内部トラフィックが通ることを確認する

Azure側の接続状態を確認する

VPN接続がConnected、プロビジョニング状態がSucceededであることを確認します。

az network vpn-connection show \
  --resource-group "$RG" \
  --name "$CONN" \
  --query "{
    connectionStatus:connectionStatus,
    provisioningState:provisioningState,
    ingressBytes:ingressBytesTransferred,
    egressBytes:egressBytesTransferred
  }" \
  --output json

正常な例は次の状態です。

{
  "connectionStatus": "Connected",
  "provisioningState": "Succeeded"
}

ただし、Connectedは外側のIKE/IPsecトンネルが確立していることを示すだけです。IPv6のLocal Network Gateway、経路、NSG、OS、アプリケーションまで正しいことを保証するものではありません。(Microsoft Learn)

NICにIPv6が割り当てられているか確認する

az network nic ip-config list \
  --resource-group "$RG" \
  --nic-name "$NIC" \
  --query "[].{
    name:name,
    ipVersion:privateIPAddressVersion,
    privateIp:privateIPAddress
  }" \
  --output table

IPv4とIPv6の両方のIP構成が表示されることを確認します。

有効なルートを確認する

az network nic show-effective-route-table \
  --resource-group "$RG" \
  --name "$NIC" \
  --output table

次の内容を確認します。

オンプレミスIPv6プレフィックスが表示される
期待した次ホップが選択されている
不要なUDRがIPv6経路を上書きしていない
BGP構成ではIPv6経路が学習されている
Hub-and-SpokeではVNetピアリングのIPv6プレフィックスが反映されている

UDRはシステムルートやピアリングルートを上書きできるため、経路が存在するかだけでなく、実際に選択されている次ホップを確認することが重要です。(Microsoft Learn)

WindowsからIPv6通信を確認する

ping -6 fd12:3456:789a:1201::10

tracert -6 fd12:3456:789a:1201::10

Test-NetConnection `
  -ComputerName "fd12:3456:789a:1201::10" `
  -Port 443

LinuxからIPv6通信を確認する

ping -6 -c 4 fd12:3456:789a:1201::10

tracepath6 fd12:3456:789a:1201::10

curl -6 --connect-timeout 5 https://app01.internal.example/

最初はDNSを使わず、IPv6アドレスを直接指定して疎通を確認します。ネットワークとアプリケーションポートの通信を確認できた後、内部DNSへAAAAレコードを登録すると、DNS障害とネットワーク障害を切り分けやすくなります。

本番移行前には、少なくとも次の4パターンを確認します。

オンプレミスからAzureへのIPv6通信
AzureからオンプレミスへのIPv6通信
オンプレミスとAzure間の既存IPv4通信
Active-active構成における片系停止時の通信

デュアルスタック化で発生しやすい問題

症状	主な原因	対処
VPNはConnectedだがIPv6だけ通らない	Local Network GatewayにIPv6がない	オンプレミスIPv6プレフィックスを追加
Azureからオンプレミスへ片方向だけ通らない	オンプレミス側の戻り経路がない	Azure IPv6プレフィックスの経路を追加
CLI実行後にIPv4通信が止まった	更新時に既存IPv4プレフィックスを省略した	完全なプレフィックス一覧で再更新
IPv6の設定を保存できない	Basic SKUまたはBasic Public IP	対応SKUとStandard Public IPへ移行
IKEトンネルは確立するがIPv6が流れない	IKEv1を使用している	接続をIKEv2で再作成
Spoke上のVMだけ通信できない	ピアリング未同期、SpokeにIPv6がない	Spokeをデュアルスタック化してピアリングを同期
NVA経由で通信が停止する	NVAまたはUDRがIPv6未対応	IPv6対応と対称ルーティングを確認
TCP通信だけ失敗する	NSG、ホストFW、アプリ待受の不足	IPv6ルールと待受アドレスを確認
Active-activeの片系しか使われない	片方のAzure公開IPしか登録していない	両方のVPNトンネルを設定
名前では接続できない	AAAAレコードがない	疎通確認後に内部DNSへAAAAを追加

最も多い失敗は、IPv6だけを追加したつもりで、Azure CLIの更新コマンドから既存IPv4プレフィックスを省略してしまうケースです。VNet、サブネット、Local Network Gatewayを更新するときは、変更後に残したいプレフィックスの完全な一覧を指定します。(Microsoft Learn)

ロールバックを前提に段階導入する

Microsoft Learnでは、IPv6デュアルスタックとして展開したVPN Gatewayを、IPv4のみの構成へ戻すことはできないとされています。そのため、単純なオン・オフ機能として扱わず、変更前に段階的な導入計画を作成する必要があります。(Microsoft Learn)

安全に進める場合は、次の順序が適しています。

VNetとGatewaySubnetへIPv6を追加する
1つの検証用サブネットとVMだけをデュアルスタック化する
Local Network Gatewayとオンプレミス装置へ検証用IPv6経路を追加する
NSGとUDRを限定的に追加する
IPv4とIPv6を同時に監視する
問題がなければ対象サブネットを段階的に増やす
最後にAAAAレコードや本番アプリケーションを切り替える

問題が発生した場合は、GatewaySubnetからIPv6を削除しようとするのではなく、次の順番でIPv6通信の利用を停止します。

AAAAレコードやIPv6向けのサービス公開を停止する
オンプレミス側のIPv6経路広告を停止する
Local Network GatewayからIPv6プレフィックスを外す
ワークロードのIPv6待ち受けを停止する
不要になったNICのIPv6 IP構成を削除する

この方法なら、既存のIPv4トンネルとIPv4ワークロードを残したまま、IPv6の利用範囲だけを縮小できます。完全にIPv4-onlyのゲートウェイリソースへ戻す必要がある場合は、ゲートウェイの再作成が必要になる可能性があるため、事前にMicrosoftサポートへ確認するのが安全です。

既存IPv4を守るための最終チェック

本番環境へ反映する前に、次の状態を確認してください。

VPN GatewayがBasic以外の本番SKUである
VPN GatewayのPublic IPがStandard SKUである
VPNタイプがRoute-basedである
S2S接続がIKEv2である
VNetに既存IPv4と新しいIPv6アドレス空間がある
GatewaySubnetに既存IPv4とIPv6 /64がある
Local Network Gatewayに既存IPv4とオンプレミスIPv6がある
AzureとオンプレミスのIPv6プレフィックスが重複していない
オンプレミスVPN装置にAzure IPv6経路がある
NSG、UDR、NVA、ホストFWがIPv6に対応している
VNetピアリングを同期済みである
IPv4とIPv6を別々に疎通確認している
Active-active構成では両方のトンネルを確認している

既存Azure VPN Gatewayのデュアルスタック化では、ゲートウェイだけを変更してもIPv6通信は完成しません。VNet、GatewaySubnet、ワークロード、Local Network Gateway、オンプレミスVPN装置、セキュリティルール、ルーティングを一つの経路として確認することが重要です。

まずは現在のGateway SKU、Public IP SKU、VPNタイプ、IKEバージョンを確認し、IPv6 /56と各サブネットの/64を設計してください。その後、検証用ワークロードから段階的にIPv6を有効化すれば、既存IPv4を維持しながら安全にデュアルスタックへ移行できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

既存Azure VPN Gatewayをデュアルスタック化する手順｜IPv4を維持してIPv6内部通信を通す

Azure VPN Gatewayのデュアルスタック化で変わる範囲

デュアルスタック化の対象条件

IPv6アドレスを先に設計する

既存Azure VPN Gatewayをデュアルスタック化する手順

現在のVPN Gateway設定を確認する

IKEv1接続はIKEv2で再作成する

VNetへIPv6アドレス空間を追加する

ワークロードサブネットとNICへIPv6を追加する

Local Network GatewayへオンプレミスIPv6プレフィックスを追加する

オンプレミスVPN装置へIPv6設定を追加する

NSG、UDR、VNetピアリングをIPv6対応にする

IPv6内部トラフィックが通ることを確認する

Azure側の接続状態を確認する

NICにIPv6が割り当てられているか確認する

有効なルートを確認する

WindowsからIPv6通信を確認する

LinuxからIPv6通信を確認する

デュアルスタック化で発生しやすい問題

ロールバックを前提に段階導入する

既存IPv4を守るための最終チェック

この記事を書いた人

コメント

コメントするコメントをキャンセル

既存Azure VPN Gatewayをデュアルスタック化する手順｜IPv4を維持してIPv6内部通信を通す

Azure VPN Gatewayのデュアルスタック化で変わる範囲

デュアルスタック化の対象条件

IPv6アドレスを先に設計する

既存Azure VPN Gatewayをデュアルスタック化する手順

現在のVPN Gateway設定を確認する

IKEv1接続はIKEv2で再作成する

VNetへIPv6アドレス空間を追加する

ワークロードサブネットとNICへIPv6を追加する

Local Network GatewayへオンプレミスIPv6プレフィックスを追加する

オンプレミスVPN装置へIPv6設定を追加する

NSG、UDR、VNetピアリングをIPv6対応にする

IPv6内部トラフィックが通ることを確認する

Azure側の接続状態を確認する

NICにIPv6が割り当てられているか確認する

有効なルートを確認する

WindowsからIPv6通信を確認する

LinuxからIPv6通信を確認する

デュアルスタック化で発生しやすい問題

ロールバックを前提に段階導入する

既存IPv4を守るための最終チェック

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル