ExpressRoute 接続済み既存IPv4環境を IPv4/IPv6 併用環境へ移行
こちらは Microsoft Azure Tech Advent Calendar 2024 1日目 の記事です。
IPv4/IPv6 併用環境への移行
クラウド活用が進み、複数の拠点/システム/マルチクラウドが接続されてくると、アドレス空間の確保が IPv4 のみでは苦しい、という場合も出てきます。
もちろん、IPv4 アドレス空間が重複しないように綺麗に再設計などができればベストかもしれませんが、難しい…そんな時、もしかすると IPv6 を活用するとうまく相互の接続ができる状況を作れるかもしれません。
ということで ExpressRoute でオンプレミス - Azure が接続済みとなっている既存 IPv4 な環境を、 IPv4/IPv6 を併用する(デュアルスタック)環境へと移行する手順を検証してみました!
IPv6 に対応しているサービスについて
Azure には、VNet 内でのプライベートな IPv6 利用に対応しているサービス/現状まだ対応していないサービスがあります。IPv6 に対応しているものについては、以下のドキュメントにまとめられています。
なお、こちらはあくまでも Azure VNet のドキュメントであるため、例えば Azure Front Door などの、IPv6 に対応しているが Azure VNet 内にデプロイされないものについては、言及されていません。
検証環境の概要
今回、以下のように オンプレミス と Azure が既に接続された環境がある想定で、IPv4/IPv6 併用環境への移行を試してみます。検証環境用意の都合上 オンプレミス環境 は実機ではなく Azure 上に用意をしてしまっていますが、模擬オンプレミス環境 と Azure環境 の間は、 ExpressRoute のみで接続してあり、通信は ExpressRoute 経由となるようにしてあります。
当初の状態は、模擬オンプレミス環境 と Azure 環境 の間の通信は、IPv4 のみでの通信となっています。
ここから Azure 環境 に、新たに IPv6 の割り当てを行って、従来の IPv4 と新たに追加した IPv6 を併用する、デュアルスタックの環境へ移行します。移行中、ダウンタイムが生じるのかなども確認していきます。
移行の流れ と 影響
それでは大まかな流れと影響を確認していきます。
Step 1 と 2 は、どちらが先でも良いですが、Step 3 は、Step 1 と 2 が完了している必要があります。
-
VNet に IPv6 を追加する
影響など:特になし -
ExpressRoute 回線に IPv6 プライベート ピアリングを追加
影響など:特になし -
ExpressRoute Gateway を IPv6 対応に更新する
影響など:既存 ExpressRoute Gateway の状況によっては Gateway 再作成 か SKU Migration が必要。SKU Migration する場合でも、30秒程度停止の可能性。(参考→ ExpressRoute Gateway を SKU Migration する流れと通信影響) -
必要な各 VM に IPv6 も付与する
影響など:VMの停止/起動が必要
Step 1: VNet に IPv6 を追加する
まずは既存VNet に IPv6 を追加します。ExpressRoute の Gateway と、IPv6 で通信させたい VM が存在する VNet に、IPv6 を追加する必要があります。
Azure ポータルから、VNet を開き、アドレス空間 として、新たなアドレス空間を追加できます。IPv6 を追加します。
VNet のアドレス空間を IPv4/IPv6 に拡張したら、サブネットにも IPv6 を追加します。
この追加を行っても、既存 VM の通信が切れたりなどの影響はありません。念のため、オンプレ想定 VM と Azure VM 間で常時 Ping した状態でアドレス空間を追加しましたが、まったく Ping 抜けなどもありません。
Step 2: ExpressRoute 回線に IPv6 プライベート ピアリングを追加
ExpressRoute 回線に、IPv6 プライベート ピアリングを追加します。 この手順は、 [Step 3. ERGateway を IPv6 対応にする] よりも先に行っておく必要があります。
ExpressRoute 回線の設定を開き、既存の プライベート ピアリング を確認します。サブネットの選択が IPv4 のみになっている場合、[両方] を選択します。誤って [IPv6] を選択した場合には既存の IPv4 通信が不可になるので注意が必要です。
[両方] を選択して、新たに表示された [IPv6] 欄に、プライベート ピアリングを追加します。Ipv4 のプライベートピアリングを構成する際と同様に、仮想ネットワーク では利用していない [/126] のサブネットを 2つ 割り当てます。
図では、fd:1:2:15ff::/126
と fd:1:2:15ff::4/126
を割り当てていますので、
-
fd:1:2:15ff::1
とfd:1:2:15ff::5
を オンプレミス側ルーター -
fd:1:2:15ff::2
とfd:1:2:15ff::6
を Azure 側 (MSEE)
で利用することになります。
Step 3: ExpressRoute Gateway を IPv6 対応にする
ExpressRoute Gateway を IPv6 対応させます。この手順を実行すると、ExpressRoute Gateway が Azure 側 IPv6 アドレス空間を学習し、オンプレミス側にも広報されるようになります。また、オンプレミス側からの IPv6 経路を学習するようにもなります。
ExpressRoute Gateway IPv6 対応 の 制限事項
実施に先立ち、公開ドキュメントを確認します。制限事項には、気になる記載があります。
いつを基準に "既存" はダメで "新しく" は OK なのかですが、調べた限り、この記載は 2021年10月 には記載されていました。つまりこれ以降、2022年以降に作成された Standard パブリック IP アドレス を持つ ExpressRoute Gateway であれば大丈夫そうです。なお、ゾーン冗長かどうか、という記載もありますが、現時点で新規に作った ExpressRoute Gateway であればゾーン冗長ではなくとも IPv6 で利用可能です。
いちおう整理すると以下のような形です。
既存のゲートウェイの状況 | なにか対処が必要か | 備考 |
---|---|---|
利用している Public IP アドレス が Basic の ER Gateway | 必要 | 再作成 or Migration |
利用している Public IP アドレス が Standard の ER Gateway (2022年以降作成) | 特に不要 | |
利用している Public IP アドレス が Standard の ゾーン冗長 ER Gateway (2021年以前作成) | 特に不要 | |
利用している Public IP アドレス が Standard の 非ゾーン冗長 ER Gateway (2021年以前作成) | 怪しい | 再作成 or Migration |
ExpressRoute Gateway を IPv6 対応に更新する
さて、制限を確認したうえで、あらためて手順です。
手順自体は、Step1 と 2 が済んでいれば、Azure PowerShell で、対象の ExpressRoute Gateway を取得して、そのまま ExpressRoute Gateway を更新するだけです。
AzurePortal から Cloud Shell で Azure PowerShell を起動して実行します。
$gw = Get-AzVirtualNetworkGateway -Name "GatewayName" -ResourceGroupName "ExpressRouteResourceGroup"
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw
公開ドキュメントでは、変更が反映されるまで最大で 1 時間かかる可能性がある、と記載されていますが、検証では 30分程度で完了しました。また、この操作の間も、通信に特段の影響はありませんでした。
ExpressRoute の更新後、 ExpressRoute 回線のルートテーブルを確認すると、Azure 側 IPv6 アドレス空間が経路として広報されていることが確認できます。
Step 4: 必要な各VMに IPv6 も付与する
最後に、IPv6 を利用したい Azure VM に IPv6 を付与します!
Azure ポータルから、対象の VM のネットワーク設定を開き、ネットワークインターフェイスを確認します。
ネットワークインターフェースの IP 構成に、 +追加 で、IPv6 を追加します。
追加されました! VM を再起動し、反映します。
通信確認
では、確認します!
設定した IPv6 宛に ping や RDP ができることを確認しました(tracert ace:daa:daaa:deaa::4 -> ace:daa:daaa:deac::4) 。また、デュアルスタック構成ですので、これまで利用していた IPv4 での通信も問題なく継続できています。(tracet 10.100.0.4 -> 10.4.0.4 の結果)
なお、経路上 NSG があれば、IPv6 用の NSG ルールも忘れず追加しておきます。
まとめ
以上で、ExpressRoute 接続済み既存IPv4環境を IPv4/IPv6 併用環境へ移行する手順を確認しました。
特に、ExpressRoute Gateway の IPv6 対応については、制限事項があるため、注意が必要ですが、手順自体はそれほど難しくありません。また、検証した結果では、影響は限定的で、オンプレミス側 VM <-> Azure VM 間の毎秒常時pingも、特に落ちるタイミングはありませんでした。
ExpressRoute の IPv6 関係の制限
ルート アドバタイズの制限
制限 | 値 |
---|---|
オンプレミスから Azure プライベート ピアリングにアドバタイズされる IPv6 ルートの最大数 | 100 |
Azure プライベート ピアリングからアドバタイズされる VNet アドレス空間から ExpressRoute 仮想ネットワーク ゲートウェイへの IPv6 ルートの最大数 | 100 |
オンプレミスから Microsoft ピアリングにアドバタイズされる IPv6 ルートの最大数 | 200 |
GlobalReach
- ExpressRoute Global Reach 接続経由で IPv6 トラフィックを送信できますか? -> パブリックプレビュー
その他、ExpressRoute と併用されがちなサービスの制限
- VPN Gateway で利用できるトラフィックは IPv4 のみ(デュアルスタック VNet にデプロイはOK)
- Azure Firewall で利用できるトラフィックは IPv4 のみ
- Azure Route Server で利用できるトラフィックは IPv4 のみ
- Virtual WAN で利用できるトラフィックは IPv4 のみ
Discussion