この前の投稿、NSGでWindows Updateを許可する方法を掲載するための検証を行っている際に気付いたのですが、なんとAzureのSite to Site VPNでDDNSが設定可能になっていました！
嬉しくなって一緒に検証をやってしまいました。
#検証するに至った経緯
実際はNSGでWindows Updateを許可する方法では不要なのですが、なんとなく久しぶりにAzureとインターネットVPNを張ってみたくなり2~3か月ぶりにAzureのVPN設定画面を眺めているとなんと
マ、マジか・・・！？
このパラメータを発見したときは、ほんとに漫画の集中線みたいになりました。
漫画ってよく表現されてますよね。
ちょっと集中線が煩すぎるので普通の画面はこちらです。
ちなみにこの設定を[IPアドレス]から[FQDN]に変更してみると
思った通りに設定名が変更されました。
情報ボタンにホバーしてみると
完全に思った通りの説明文ですね。
これはAzure始まりました。
素晴らしいです。
#一体何が素晴らしいのか？
元々Azureはエンタープライズ向けなんですが、そもそもPublic Cloudというのが「手軽にお試しして、良かったら使い続ける」というコンセプトも強いです。
重厚長大なシステムに対する「信頼性」も大事なのですが、同時に一見信頼性と相反するように見える(あくまで見えるだけで実際は違います)「手軽さ」も求められます。
エンタープライズでは「固定IPアドレス」なんてあって当然、何ならレンジで持ってて当たり前ですが、中小零細企業ではそうはいきませんし、エンタープライズでも「とりあえずAzureを試してみたい」という場合に本番環境で利用している固定IPアドレスを1つ払い出してもらうもの結構大げさかなと思います。
そこで検討されるのが一般家庭でも利用されている「動的IPアドレス」だと思いますが、なんせ動的なのでグローバルIPアドレスが任意のタイミングで変わってしまいます。
そうなるとここの設定値が「IPアドレス」(＝固定IPアドレス)だけだとプロバイダ起因かネットワーク機器、網起因かはおいといて、AzureとのSite to Site VPNが切れてしまします。
ネットワークに詳しい担当者、Azureに詳しい担当者ならすぐに復旧できるでしょうが、手動復旧は面倒ですし、一般ユーザや非IT系の部署からすれば「Azureと社内環境との接続は不安定なものである」という認識をAzureと関係ない部分持たれてしまいます。
結果Azureへの信頼性が下がってしまう可能性が十分に考えられます。
私自身、この仕組みが導入されるまではAzureのNetwork WatcherやAzure Automationの機能で動的IPアドレスを監視し、動的IPアドレスの変化を検知してこのローカルゲートウェイの設定を動的に書き換える仕組みを実装します。
正直手間でしかありませんし、この手間は工数としてお客様への請求額にそのまま反映されます。
これは果たして「手軽」でしょうか？
このような手軽とは言いにくい設定を行わなくてもこの[FQDN]の機能が文字通りに動作するのであれば、動的IPアドレスが変更されてもAzureはDDNSに登録されたFQDN宛に通信を行いますので切断されたVPNは自動復旧するはずです。
#機能実装は素晴らしいが、実際に使えるものなのか？
はい。
ここが問題ですね。
検証しましょう。
弊社はYAMAHA、Fortigate、Cisco、Juniper、NECとバリエーション豊かに現役機種の検証機ルータを取り揃えておりますが、とりあえず一般的なCiscoからいってみましょう。
CiscoとAzureとのSite to Site VPNの設定は別の記事に譲り、ここではこの「FQDN」設定が正しく動作するか確認します。
#検証
まずはAzureとCisco間でVPNが張れていることを確認します。
##事前準備
NSGでWindows Updateを許可する方法で作成したWindows 11です。
簡単に状況をまとめると
| マシン | IPアドレス |
|---|---|
| Windows 11 | 172.16.101.5 |
| Cisco 841m | 172.16.4.1 |
となっています。
必要ないかもしれませんが念のため構成図としては
こうなっています。
もっとも単純なインターネットVPN、Site to Site VPNです。
構成図に解説を追加すると
こうなります。
Azure上のリソース、[Connection]と[Local Gateway]はAzure上仮想ネットワークとオンプレミスの物理ネットワーク機器、Cisco 841mとを接続する[概念]のようなものです。
Local GatewayとConnectionの設定は実際のCisco841mに行うVPN設定値と合わせて設定する必要があります。
##切断、再接続検証
ではVPNを切断し、再接続してみましょう。
まずは現在のグローバルIPアドレスを確認します。
赤枠で囲った部分ですね。
QiitaにグローバルIPアドレスを晒すのもどうかと思いましたが、どうしても確認しなければならない部分なので晒します。
次にCiscoのPPPoE接続を切断し、再接続してみましょう。
といってもPPPoEのみを器用に切断するコマンドを知らない(思い出せない？)ので、とりあえずDialerインターフェースをShutdownします。
すると当然VPNも切断されます。
ではCiscoでDialer1を起動します。
グローバルIPアドレスが変わりましたね。
VPNは復旧するでしょうか？
見事復活しました！
PPPoE接続が復旧してからVPN復旧まで少し時間がかかりましたが、目論見通りの動作です。
Azure、はじまりましたね。
素晴らしいです。
今回はここまで。