Azure ズッコケ集　~こんな動きするんですね~

内苑利映

2020年04月15日

皆さん、こんにちは！内苑です！
この記事では、最近 Azure を操作している中で、思わぬ動作仕様でつまずいた体験談をおまとめしてみました。今回取り上げる事例はレアケースかもしれませんが、「へぇ～。そんな動きするんだぁ～。」と参考にしていただければ幸いです。

本記事は以下の２本立てでお送りします。

ExpressRoute ゲートウェイの古い SKU 利用における弊害
皆さんは使ってますか？Azure Portal App

1. ExpressRoute ゲートウェイの古い SKU 利用における弊害

とある環境で、ExpressRoute 回線を旧環境から新環境に切り替える必要があり、Microsoft 社にて公開されているこちらの記事を参考に、切り替えを試みました。概要としては以下のようなイメージです。既存の接続構成 (赤点線の経路) を削除し、新規の接続構成 (青線の経路) を作成して新回線経由での通信が可能になるよう設定を実施しました。

切り替えが完了し、オンプレミスのクライアントから Azure 上の仮想マシンに疎通確認を行おうとしたところ、切り替え前と全く違うあさってのルートに旅立ってしまったので、突然の出来事に混乱を隠せませんでした。しかし、この時の私はまだ能天気に「しょうがねえ。旧回線に切り戻すか (　＾ω＾) ・・・」と安易に通信が回復することを期待し、新回線への接続構成を削除、旧回線への接続構成を作り直しました。

戻らない (　＾ω＾) ・・・
なぜ元の構成に戻しても通信が復旧しないのか、原因は明白でした。
ER Gateway の SKU の値が空っぽでした ( ˘ω˘)ｽﾔｧ

ポータルで見るとこんな感じでした。

ER Gateway の Basic レベルは 2017/10/15 にサポート提供が終了していましたが、そのままでも動作はするようなので、こんな動きをしていたと思われます。

[設定当初]
ER Gateway をデフォルトのプラン (Basic) で作成。接続リソース構成時、ER Gateway にリンクしている仮想ネットワークアドレス空間への経路が BGP に広報される。

[切り替え時]
旧接続リソースを削除することにより、設定当初広報されていた経路情報が BGP から削除される。新しい接続リソースを作成する際、ER Gateway の SKU が Basic のため、BGP に経路を広報する動作が正常に実行されず、BGP に経路情報がないままになる。

[切り戻し時]
切り替え時同様、ER Gateway の SKU が Basic のため、BGP に経路を広報する動作が正常に実行されず、オンプレミス DC ⇒ Azure VNet 上の VM への通信が迷子になり、筆者がパニックになる。

結局、SKU を Standard に変更することにより無事通信が復旧しました。
回線を切り替えるのが目的で、ゲートウェイはそのまま使えるだろうという見通しで作業していましたが、SKU がレガシーであるというところは完全に盲点だったため、確認ポイントから漏れてしまっておりました。
ExpressRoute の Private Peering をご利用中で、回線の切り替えなどを検討している方は、必ず切り替え前に ER Gateway の SKU を確認しましょう！
以下の PowerShell コマンドを実行し、SKU の Name の値を見れば、SKU のレベルが何に設定されているかを確認できます。

【コマンド】
Get-AzVirtualNetworkGateway -Name "＜ゲートウェイ名＞" -ResourceGroupName "＜リソースグループ名＞"

【実行結果 (一部抜粋) 】
Sku : {
"Capacity": 2,
"Name": "******", ⇐ ここの値が Basic または Default の場合変更が必要
"Tier": "******"
}

SKU の変更時は Gateway インスタンスが再作成されるため、切り替わりに数十分の時間を要しますので、切り替え計画をしっかり立てて実行してください。 (筆者が変更したときは 20分前後かかりました)

2. 皆さんは使ってますか？Azure Portal App

皆さん、ご存じでしょうか。1年くらい前から Azure Portal に Internet Explore でアクセスしようとすると、こんなページが表示されるようになってます。

ここで、［Azure portal アプリのダウンロード］を選択すると、PC にこんなアプリケーションがダウンロードされます。

Azure Portal App は、Azure の管理に使用する Windows マシンで「Microsoft Edge」や「Google Chrome」「Mozilla Firefox」「Apple Safari」といったモダンブラウザを利用できない環境向けに、Web ブラウザなしで Azure ポータルと同等のエクスペリエンスを提供することを目的としている、とのことです。現状はプレビューのようなのですが、筆者はいつからかこのアプリケーションを普段使いするようになっていました。
筆者の業務は基本的に、動作検証、技術検証で Azure を利用することが多いため、プレビューであることは全く意に介さず社内での認知度がおよそ皆無なこのアプリを使っていましたが、思わぬ動作設定に落とし穴がありました。

異なるサブスクリプション間の VNet Peering を設定する際、接続元から対向 VNet のリソース ID を入力し、対象リソースが所属するサブスクリプションに認証をする必要があるのですが、ここがうまくいきませんでした。

以下イメージのように、［認証］というボタンが表示されるのはどちらのポータルも同じなのですが、Azure Portal App の場合ここを押しても何のアクションも起きません。