Azure Bastion Developer の通信要件

はじめに

Azure Bastion には、Developer という新しい SKU があります。

参考：Azure Bastion とは

従来の Basic や Standard は、お客様仮想ネットワークの中に お客様専用の Azure Bastion を構成するインスタンスが起動します。一方で Developer は、お客様仮想ネットワークの外に存在する共有のインスタンスを利用します。

構成が変われば通信要件も変わります。というわけで、気が付いた違いをまとめました。

アクセス先の FQDN

Azure Bastion を利用する際にクライアントがアクセスする FQDN が違います。Standard と Basic の場合、アクセス先の FQDN はリソース個別の「bst-<GUID>.bastion.azure.com」になります。この FQDN を名前解決すると、Azure Bastion に関連付けたパブリック IP アドレスが返ってきます。

一方の Developer の場合、アクセス先は共有の「omnibrain.<region>.bastionglobal.azure.com」と「cdn.bastionglobal.azure.com」になります。

したがって、ファイアウォールやプロキシサーバなどでアクセス先を厳密に制限している場合には、Bastion を利用する上で許可すべき FQDN が違います。Standard と Basic の場合には「*.bastion.azure.com」を許可、Developer の場合には「*.bastionglobal.azure.com」を許可するのが良さそうです。

仮想マシンの Network Security Group

Bastion を利用してアクセスする仮想マシンの NSG で許可すべき通信も異なります。Standard と Basic の場合、AzureBastionSubnet のアドレス帯から仮想マシンに対してSSH または RDP の通信を許可します。仮想ネットワーク内の AzureBastionSubnet 上に存在する Azure Bastion 用のインスタンスが SSH や RDP の送信元になるので、AzureBastionSubnet のアドレス帯から仮想マシンへの通信を許可する必要があります。

参考：VM および VM のサブネットの NSG の受信セキュリティ規則

Developer の場合、お客様仮想ネットワークの外にインスタンスが存在しています。そのため、SSH や RDP の送信元は仮想ネットワーク内のアドレスにはなりません。Developer の場合、SSH や RDP の送信元 IP アドレスは 168.63.129.16 になります。実際に Developer を利用してアクセスした Ubuntu のアクセスログを見てみると、168.63.129.16 からアクセスされていることがわかります。

Apr 18 12:24:52 basdev sshd[4737]: Accepted password for ymatsumoto from 168.63.129.16 port 57074 ssh2
Apr 18 12:24:52 basdev sshd[4737]: pam_unix(sshd:session): session opened for user <USER-NAME> by (uid=0)

したがって、NSG の優先度65001 の「サービスタグ AzureLoadbalancer からの全通信を許可」のルールで Developer の通信は許可されます。もし既定の NSG のルールを高い優先度で打ち消す運用を行っている場合には、明示的にサービスタグ AzureLoadbalancer からの SSH や RDP を許可する必要があります。

必要な通信が許可されていない場合、例えば以下のように意図的に 168.63.192.16 からの SSH を拒否しているような場合には、Developer での接続が失敗します。

まとめ

Azure Bastion Developer の通信要件の違いをまとめました。同じ Azure Bastion という名前ながら、Developer だけは通信要件が大きく異なります。利用する前に、アクセス元クライアントとアクセス先仮想マシンのネットワーク設定を確認・整備するのをお忘れなく。