サービスエンドポイントを使用して特定のサブネットからストレージアカウントまで Azureバックボーンネットワークで行ってみよう!
突然ですが 『 サービスエンドポイント 』 ご存じでしょうか?
VNet 内から PaaSサービスのグローバルIPアドレスに向かって、インターネットからのアクセスではなく Azureバックボーンネットワークを経由して通信するための接続オプションです。
ちなみに、似たような接続オプションとして「プライベートエンドポイント」なるものも存在します。
後者は VNet と統合したオンプレミスネットワーク ( VPN / ER ) からでも PaaSサービスの「プライベートIPアドレス」に向かって通信できます。
ですが今回は前者についてです。
サービスエンドポイントを通り Azureバックボーンネットワークを経由する通信にて Azureファイル共有のフォルダをマウントしてみたいと思います。
環境を準備する
以前に書いたこちらの記事の環境に少し手を加えます。
作成する環境のイメージとしては以下の図になります。
サービスエンドポイント
対象となるサブネットに対して「ストレージエンドポイント」という種類のサービスエンドポイントを構成します。
Bicepファイルにおけるシンボリック名でいうと
subnet1 ➡ パブリックサブネット
subnet2 ➡ プライベートサブネット
subnet3 ➡ Bastionホスト専用サブネット
という役割の違う三つのサブネットを作成するのですが、今回対象となるのは subnet2 です。
subnet2 ( プライベートサブネット ) についてはそもそもインターネットにも接続できないようにするわけですが、この状態ではストレージアカウントにもたどり着けません。
そこでサービスエンドポイントを作成することでたどり着けるようにします。
なおサービスエンドポイントは、サービスごと、サブネットごとに有効になります。
今回の場合のサービスとは ストレージアカウントなので 💡 のように記述します。
var subnet2 = {
name: 'privateSubnet'
properties: {
addressPrefix: '${addressPrefix}1.0/24'
serviceEndpoints: [ //👈
{
service: 'Microsoft.Storage' //💡
locations: [
'japaneast'
'japanwest'
]
}
]
networkSecurityGroup: {
id: subnet2nsg.id
}
}
}
実際にこれを使ってデプロイしたものは以下となります。
ネットワークセキュリティグループ ( NSG )
プライベートサブネットに紐づける NSG に送信セキュリティ規則を一つ追記します。
これでサブネット( 厳密には VNet )からのストレージアカウントへのアクセスは許可するようにできます。
{
name: 'Allow-Storage-All'
properties: {
direction: 'Outbound'
protocol: '*'
access: 'Allow'
priority: 1000
sourceAddressPrefix: 'VirtualNetwork'
sourcePortRange: '*'
destinationAddressPrefix: 'Storage'
destinationPortRange: '*'
}
}
実際にこれを使ってデプロイしたものは以下となります。
ストレージアカウント
新しく、独立したモジュールファイル 「 storageAccount.bicep 」 を追加しました。
デプロイするリソースは、
ストレージアカウント ( 1️⃣ )
ファイル共有 ( 2️⃣ )
の二つです。
💡 については、subnet2 ( プライベートサブネット ) のリソースID の出力値を入れ込みます。
そして 1️⃣ でこのサブネットからのアクセスだけは許可するとします。
param location string
param subnetId string //💡
var storageAccountName = 'sta'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-08-01' = { // 1️⃣
name: '${storageAccountName}${uniqueString(subscription().id)}'
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
networkAcls: {
defaultAction: 'Deny'
virtualNetworkRules: [
{
action: 'Allow'
id: subnetId
}
]
}
}
}
resource fileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2021-09-01' = { // 2️⃣
name: '${storageAccount.name}/default/forprivate'
}
実際にこれを使ってデプロイしたものは以下となります。
ストレージアカウント ( 1️⃣ ) の properties ( networkAcls )
ファイル共有 ( 2️⃣ )
Azure VM ( Windows Server )
今回は 2台の VM を使用します。
subnet1 ( パブリックサブネット ) と subnet2 ( プライベートサブネット ) に 1台ずつ Windows Server をデプロイします。
試してみる
ファイル共有への Z ドライブのマッピングを作成してみる
ありがたいことに、Azure portal で案内してくれる PowerShell スクリプトを Azure VM ( Windows Server ) から実行すると作成できます。
⇩
⇩ 下にスクロール
何やらコマンドが表示されていますのでコピーします。
Azureファイル共有をマウント
それぞれの Windows Server に作成した管理者ユーザーでサインインして PowerShell を起動して先ほどコピーしたコマンドを実行してみます。
詳細が気になる方は以下の公式ドキュメントもご参考ください。
🟡パブリックサブネットの Windows Server の場合
何やら赤字でイヤな感じの応答が返ってきていますね。
New-PSDrive : Access is denied
はい、狙い通りアクセスが拒否されています。
当然ですがエクスプローラーを見ても Zドライブはありませんね。
🟢プライベートサブネットの Windows Server の場合
CMDKEY: Credential added successfully.
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
Z 0.00 5120.00 FileSystem \\staavsgjemr76bak.file.core.win...
こちらはマウントがうまくいったようです。
エクスプローラーを見ると Zドライブが現れました。
狙い通りですね。
インターネットへのアクセス
PowerShell ( Test-NetConnection コマンドレット ) と Webブラウザで note.com にアクセスしてどのような応答が返ってきたか確認します。
🟡パブリックサブネットの Windows Server の場合
PS C:\Users\azureuser> Test-NetConnection -ComputerName note.com -Port 80
ComputerName : note.com
RemoteAddress : 13.32.50.5
RemotePort : 80
InterfaceAlias : Ethernet
SourceAddress : 10.10.0.4
TcpTestSucceeded : True
はい、特に問題なくネットワークの疎通が確認できました。
ブラウザの場合はどうかというと
こちらも特に問題ありません。
🟢プライベートサブネットの Windows Server の場合
PS C:\Users\azureuser> Test-NetConnection -ComputerName note.com -Port 80
WARNING: TCP connect to (18.65.202.117 : 80) failed
WARNING: TCP connect to (18.65.202.37 : 80) failed
WARNING: TCP connect to (18.65.202.34 : 80) failed
WARNING: TCP connect to (18.65.202.111 : 80) failed
WARNING: Ping to 18.65.202.117 failed with status: TimedOut
WARNING: Ping to 18.65.202.37 failed with status: TimedOut
WARNING: Ping to 18.65.202.34 failed with status: TimedOut
WARNING: Ping to 18.65.202.111 failed with status: TimedOut
ComputerName : note.com
RemoteAddress : 18.65.202.117
RemotePort : 80
InterfaceAlias : Ethernet
SourceAddress : 10.10.1.4
PingSucceeded : False
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False
はい、先ほどとは異なり疎通に問題ありです。
ブラウザの場合はどうかというと
はい、こちらも当然ながら表示できません。
🟠 さいごに 🔚
ということで、狙い通りの環境がデプロイできました。
ざっくり言えばプライベートエンドポイントの方が優秀といった感じですが、万能ではありませんし要件によってはこのようなサービスエンドポイントが必要になるかもしれません。
そんな時にはぜひ使ってみてください。
今後も Azure に関する技術情報やその他の資格試験に関する記事を書いていこうと思いますので、よろしければフォローをお願いします🔆
また、この記事が少しでもタメになった、面白かったという方がいらっしゃいましたら、ぜひ 「 スキ 」 ボタンのクリックをお願いします😋
最後までお読みいただきありがとうございました 😊