社外からAzure VMにRDP/SSH接続するとき、「VPNをつなぎ直したらIPアドレスが変わって二度と入れない…」という問題は意外とよく起きます。特にMATLABなどの重い計算をAzure上で動かし、リモートデスクトップ越しに操作していると、接続が不安定だと作業に大きな支障が出ます。この記事では、VPNの動的IPに悩まされず、Azure Bastionを使って安定かつセキュアにAzure VMへ接続する方法と、代替構成の選択肢を詳しく解説します。
VPNの動的IPでAzure VMに接続できなくなる原因
まずは「なぜVPNのIPアドレスが変わるとAzure VMに入れなくなるのか」を整理します。今回の前提は次のような構成です。
- Azure VM 上で MATLAB (BYOL) 2025a を実行
- 自宅PC → 会社VPN → インターネット → Azure という経路で接続
- VM作成時、
NSGの受信ルールに「会社VPN経由で見える自分のグローバルIP」を許可として登録 - ところが会社VPNは24時間ごとに切断され、再接続時に別のクライアントIPを割り当てる
AzureのNSGは「送信元IPアドレス」でアクセスを制御します。VPN再接続のたびにグローバルIPが変わると、以前NSGに登録したIPと一致しなくなり、RDP(3389番ポート)やSSH(22番ポート)への接続が遮断されます。
つまり、
- セキュリティのために「自分のIPだけ許可」していた
- しかし、その「自分のIP」がVPNのたびに変わる
この2つが同時に成り立たないことが、今回の根本原因です。
| 項目 | 初期構成 | 問題点 |
|---|---|---|
| 接続元 | 会社VPN経由で見えるグローバルIP | 24時間ごとに別のIPに変わる |
| NSGの設定 | RDP/SSHの送信元を単一IPに制限 | IPが変わると全てブロックされる |
| 影響 | Azure VMのRDP/SSHに接続不可 | MATLAB計算環境にログインできない |
このようにIPアドレスを固定前提でホワイトリスト管理する方式は、在宅勤務＋VPN＋クラウドの世界ではだんだん限界が見えてきます。
解決の方向性：IPアドレスではなく「サービス＋ID」で守る
ではどうするか。答えはシンプルで、
- 「クライアントIPアドレス」で守るのをやめる
- Azureが提供するマネージドな踏み台サービスを挟み、「ID＋ポータル経由」で接続する
この役割を担うのが Azure Bastion です。Azure Bastionは、
- Azureポータルのブラウザ画面からRDP/SSH接続を提供
- 接続先VMはプライベートIPのみでOK（パブリックIP不要）
- 通信はポータルとBastion間の HTTPS(443/TLS) のみ
- ユーザー認証はAzureポータルへのサインイン（Microsoft Entra ID）＋VM側のRDP/SSH認証
という特徴を持つサービスで、VM側のパブリックIPやクライアントIPのホワイトリスト管理を不要にします。
Azure Bastion導入の全体イメージ
Azure Bastionを使うと、ネットワーク構成は次のように変わります。
- VMからパブリックIPを切り離す
- NSGから「クライアントIP許可」のRDP/SSHルールを削除
- 同じVNet内にAzure Bastionをデプロイ
- ユーザーはブラウザでAzureポータルにサインイン → Bastion経由でVMにRDP/SSH
この方式では、Azure側でBastionが踏み台の役割を担うため、VPNの再接続でクライアントIPが変わってもVMへの接続性は維持されます。
| 項目 | 従来構成（パブリックIP＋NSG） | Azure Bastion構成 |
|---|---|---|
| VMのパブリックIP | 必要 | 不要 |
| NSGでのIP制御 | クライアントIPをホワイトリスト | クライアントIPは意識しない |
| 接続方法 | ローカルRDP/SSHから直接接続 | ブラウザからBastion経由、またはBastionネイティブクライアント |
| 攻撃面 | RDP/SSHポートがインターネットに露出 | VMは完全にプライベートIPのみ |
ステップバイステップ：Azure BastionでVPNの動的IP問題を解消する
ここからは、実際に「VPNの動的IPが変わってもAzure VMに安定して接続できる構成」を作る手順を、もう少し具体的に解説します。
前提条件
- Azureサブスクリプションを保有している
- 対象のAzure VM（MATLAB 2025a BYOLをインストール済み）が存在する
- VMが属するVNetとサブネットを把握している
- Azureポータルにサインイン可能なアカウントを持っている
手順1：VMのパブリックIPと古いNSGルールを削除
まずは「インターネットに直接さらされたVM」をやめるところから始めます。
- Azureポータルで対象VMを開く
- 「ネットワーク」ブレードを開き、NICに関連付けられたパブリックIPアドレスを確認
- パブリックIPのリソースを開き、「関連付けの解除」または「削除」を実行
- 同じく「ネットワーク」ブレードでNSGを開き、
- RDP(3389)またはSSH(22)の受信ルール
- 送信元に「自分のIP」や特定IPが指定されているルール
この段階で、VMは外部から直接は接続できなくなりますが、後続の手順でBastion経由の接続手段を用意します。
手順2：Azure Bastionを同じVNetにデプロイ
次に、VMと同じVNetにAzure Bastionを配置します。
- Azureポータルで対象VMを開き、上部の「接続」→「Bastion」を選択
- まだBastionがない場合、「Bastion を設定」画面が表示されるので新規作成を選択
- リソースグループ、VNetはVMと同一のものを指定
- サブネットに
AzureBastionSubnetが存在しなければ、アドレス空間から /26 以上のサイズ（例：10.1.1.0/26）で新規に追加
※Azure Bastionは、最低 /26 の専用サブネットが推奨・要件になっています。 - SKU（Basic / Standard / Premium、またはDeveloper）を選択
- パブリックIP（Bastion用）を新規作成（Standard・静的）
- 確認してデプロイを実行
数分でデプロイが完了し、VNet内にBastionホストが立ち上がります。
手順3：Bastion経由でVMへ接続する
デプロイが完了したら、実際に接続してみます。
- Azureポータルで対象VMを開く
- 上部の「接続」→「Bastion」を再度クリック
- VMのローカルアカウント、もしくはドメインアカウントのユーザー名・パスワード（またはSSH鍵）を入力
- 「接続」を押すと、ブラウザタブ内にRDP/SSHセッションが開く
以後は、
- 自宅IPが変わっても
- 会社VPNのグローバルIPが日替わりでも
Azure Bastionのパブリックエンドポイントさえ到達できれば、VMへの接続が維持されます。
| 手順 | 作業内容 | ポイント |
|---|---|---|
| 1 | VMからパブリックIPを切り離し、RDP/SSHの旧NSGルールを削除 | インターネットからの攻撃面を大幅削減 |
| 2 | 同じVNetにAzure Bastionをデプロイ | 専用サブネットAzureBastionSubnet（/26以上）が必要 |
| 3 | Bastion経由でブラウザからRDP/SSH接続 | クライアントIPを意識せず安定してVMにアクセス可能 |
MATLAB BYOL環境でBastionを使うメリット
今回のケースのように、Azure VM上にMATLAB BYOL（Bring Your Own License）環境を構築している場合、Bastionを採用すると次のようなメリットがあります。
- ライセンス管理上の安心感
VMをパブリックIPで晒さないため、誤ったポート公開や不正アクセスによるライセンスファイル・ライセンスサーバへの攻撃リスクが下がります。 - 長時間ジョブの安定運用
動的IPに依存せず接続できるので、翌日ログインできなくてトラブルシューティングに時間を取られる、といった事態を減らせます。 - ファイル転送もAzure Bastionで完結可能
BastionのStandard以上＋ネイティブクライアント機能を使うと、RDP/SSHクライアント経由でローカルとVM間のファイル転送も可能です。MATLABのスクリプトやデータセットのアップロードに便利です。
研究・検証用途では、VMを頻繁に作り直すことも多いため、「VM側はすべてプライベートIP＋Bastion経由」というパターンを標準にしておくと構成がシンプルになります。
Azure BastionのSKUとコストの考え方
Azure Bastionは時間課金＋データ転送料金で料金が発生します。SKUごとに単価や機能が異なり、Basic / Standard / Premiumに加えて、開発者向けのBastion Developer（無料枠）が提供されています。
主なSKUのイメージ
| SKU | 主な用途 | 特徴 |
|---|---|---|
| Developer | 開発・検証用の少人数利用 | 無料枠。1台のVMへの接続に特化。対象リージョンや機能は制限あり。 |
| Basic | 小規模環境の運用 | 基本的なブラウザRDP/SSH接続を提供。インスタンス数は固定。 |
| Standard | 本番利用・複数VMを扱う環境 | VNetピーアリング、ネイティブクライアント、ホストスケーリングなど拡張機能が利用可能。 |
| Premium | 監査・コンプライアンス重視の大規模環境 | セッション録画などの高度な機能が利用可能。 |
料金は「デプロイしている時間＝常に課金」される点が重要です（接続していない時間も含む）。
- 小規模検証や個人利用：
対象リージョンで利用可能なら、まずはBastion Developerや最小構成での利用を検討 - 本番環境・チーム利用：
複数ユーザー・複数VMへの接続、ネイティブクライアント機能を見越してStandard以上を検討
いずれにせよ、最新の料金は必ず公式の料金ページで確認し、他の選択肢（VPN Gatewayやジャンプボックス）と合わせて月額コストを見積もるのがおすすめです。
Azure Bastion以外の代替案・応用構成
「Bastionは便利だが、コストや要件の面で他の選択肢も比較したい」という場合に検討できる構成をいくつか紹介します。
代替案1：Azure VPN Gateway（Point‑to‑Site）＋NSG
Azure VPN Gatewayの Point‑to‑Site(P2S) を使うと、クライアントPCとAzure VNet間に暗号化された専用トンネルを張ることができます。
- クライアントはAzure VPNクライアントからVNetに接続
- NSGでは「P2Sクライアントに割り当てるアドレスプール」を許可
- ISPや会社VPNのグローバルIPが変わっても、NSGはVNet内部のアドレスを見るため影響を受けにくい
一方で、
- VPN Gateway自体にも月額コストがかかる
- クライアント証明書やEntra ID認証などの設定が必要
- 運用・トラブルシュートのハードルはBastionより高め
という特徴があります。既に他用途でVPN Gatewayを使っている環境なら、追加コストは小さいため有力な選択肢になります。
代替案2：Site‑to‑Site VPNで会社ネットワークとAzureを直結
本社側が固定IPのファイアウォールを持ち、そこからAzureにSite‑to‑Site(S2S) VPNを張れる場合は、
- 自宅PC → 会社VPN → 会社LAN → Azure（S2S VPN）→ Azure VM
という一貫した閉域網ルートを構成できます。
- VM側のNSGでは、S2Sトンネルの対向サブネット（会社LANのアドレス空間）を許可
- クライアントIPではなく、社内アドレスを見て制御できる
ただし、
- ネットワークチームとの調整が必須
- ファイアウォールやVPN装置の設定・監視が必要
など、導入・運用のハードルは上がります。中～大規模な企業で、すでにハイブリッド構成（オンプレ＋Azure）を進めている場合に向いた構成です。
代替案3：ジャンプボックス＋Just‑in‑Time (JIT) アクセス
コストを抑えつつセキュリティも確保したい場合、以下のような構成もあります。
- 同じVNet内にジャンプボックス用VMを1台用意
- このVMだけパブリックIPを持たせ、RDP/SSHポートを閉じた状態にしておく
- 必要時にだけ、Microsoft Defender for CloudのJIT VMアクセス機能で一定時間だけポートを開ける
ただし、JITで開けるNSGルールの送信元IPとして、最終的にはクライアントIP（または広いIPレンジ）を指定する必要があり、今回のようにクライアントIPが頻繁に変わる環境だと運用が煩雑になりがちです。
「パブリックIPコストは許容できるが、Bastionの時間課金は抑えたい」「テスト環境で最低限の防御をしたい」といったケースで検討するとよいでしょう。
代替案4：動的DNS＋NSG自動更新スクリプト
どうしてもIPベースの制御を続けたい場合は、
- クライアント側で動的DNSを設定（例：
home-vpn.example.net） - Azure FunctionsやGitHub Actionsなどから定期的に名前解決してIPを取得
- Azure CLI / PowerShell でNSGルールの送信元IPを自動更新
といったスクリプトで「IPホワイトリストの自動メンテナンス」を行う方法もあります。
しかし、
- 仕組みが壊れたときにVMへアクセスできなくなる
- DNS更新とNSG更新のタイミングずれによる一時的な接続不可
などのリスクもあり、クラウド標準のベストプラクティスとは言えません。どうしてもBastionやVPN Gatewayが使えない事情があるときの最終手段として捉えておくのが良いでしょう。
Azure Bastionを使うときのセキュリティ・運用ベストプラクティス
最後に、Azure Bastionを実際に使うにあたって押さえておきたいポイントをまとめます。
1. Microsoft Entra ID＋多要素認証を必須にする
- Azureポータルへのサインインは、多要素認証(MFA)を必須にする
- 管理者権限のアカウントは極力少なくし、普段はRBACで最小権限を割り当てる
Bastion自体はRDP/SSHを中継するだけなので、「誰がポータルに入れるか」がそのままアクセス制御の要になります。
2. AzureBastionSubnetは/26以上かつ専用用途にする
- サブネット名は必ず
AzureBastionSubnet - サイズは/26以上（/25, /24…）とし、他リソースを置かない専用サブネットにする
後からStandard/PremiumへのSKUアップグレードやホストスケーリングを行う場合、IPアドレスが足りないと拡張できなくなる可能性があります。
3. ネイティブクライアント機能の活用
Standard以上のSKUでは、Azure CLIを経由してネイティブRDP/SSHクライアントからBastionを利用することができます。
az network bastion rdp/az network bastion sshコマンドでトンネルを張り、ローカルのRDP/SSHクライアントから接続- RDP経由のファイル転送、SSHトンネル経由のファイルアップロードなども可能
- MATLABのスクリプトや結果ファイルをGUIでドラッグ＆ドロップで扱えるようになる
ブラウザ内RDPよりも操作性が良くなるため、開発者・研究者には特におすすめです。
4. 使わないBastionは停止ではなく「削除」する
Azure Bastionは、起動・停止の概念はなく、デプロイしている限り時間課金されます。短期検証で使ったBastionを放置すると、気づかないうちに月額コストが膨らむことがあります。
- 検証が終わったら、Bastionリソースそのものを削除する
- 必要になったら、再度数分でデプロイし直す運用を徹底
まとめ：VPNの動的IP問題にはAzure Bastionが最も簡単で安全
VPNの再接続や日替わりIPによってAzure VMのRDP/SSHにアクセスできなくなる問題は、
- クライアントIPを前提にしたNSGホワイトリスト方式
が根本原因です。この前提を捨て、
- VMはプライベートIPのままインターネット非公開
- Azure Bastionを同じVNetに配置し、ブラウザまたはネイティブクライアントで接続
という構成に切り替えることで、
- クライアントIPをホワイトリスト管理する必要がなくなる
- VPNやISPのIP変動に左右されない安定した接続性
- RDP/SSHポートをインターネットに晒さない高いセキュリティ
を同時に実現できます。
Azure VPN GatewayやSite‑to‑Site VPN、ジャンプボックス＋JIT、動的DNS＋NSG自動更新といった代替案も存在しますが、トータルで見ると、「シンプルさ」「セキュリティ」「Azureのベストプラクティスへの沿い方」という観点では、やはりAzure Bastionが第一候補になります。
MATLABのような計算系ワークロードをAzureで運用する方は、これを機に「すべての管理接続はBastion経由」というポリシーを採用し、VPNの動的IP問題から解放された、安定したリモート開発・研究環境を整えてみてください。
コメント