Azure SQL Database ゲートウェイの IP アドレスが増えたことにより、Azure 仮想マシンなどのリソースから、Azure SQL Database への接続ができないという現象が発生しているという話を聞くことがあります。
そのため、今回は、Azure SQL Database に接続できない現象の対象方法について、自分の整理も兼ねて、まとめてみようと思います。
※ 今回、接続元の Azure 仮想マシンに紐づく仮想ネットワークでは「Azure SQL Database」へのサービスエンドポイントが有効になっており、Azure SQL Database の「ファイアウォールと仮想ネットワーク」で Azure 仮想マシンに紐づく仮想ネットワークが許可され、「Azure サービスおよびリソースにこのサーバーへのアクセスを許可する」が「いいえ」に設定されている環境を想定しています。
[Azure SQL Database ファイアウォールと仮想ネットワーク 設定例]
- ■ Azure 内環境 から Azure SQL Database への接続アーキテクチャ (既定 : Redirect)
- ■ Azure 仮想マシンに紐づくネットワーク セキュリティ グループ (NSG) でファイアウォールの送信側(Outbound) を制限している場合の対処方法
■ Azure 内環境 から Azure SQL Database への接続アーキテクチャ (既定 : Redirect)
① クライアントから Azure SQL Database ゲートウェイ (*****.database.windows.net:1433) へのセッションを確立し、 実際にデータベースが配置されているクラスタノード情報を取得。
② Azure SQL Database ゲートウェイを経由せず、①で取得したクラスタノードへのセッションを直接確立 (TCP 11000から11999の範囲のポートを使用) し、 該当のデータベースに接続。
上記の構成の場合、まず初めにクライアントから Azure SQL Database ゲートウェイ(*****.database.windows.net:1433) へのセッションを確立後、実際にデータベースが配置されているクラスタノード情報を取得し、取得した情報をもとに、クライアントから直接、クラスタノードへのセッションを確立 (TCP 11000から11999の範囲のポートを使用) が行われます。
Azure 仮想マシンからネットワークキャプチャを取った場合、 以下の例では、10.0.0.5 (Azure 仮想マシンのプライベート IP アドレス) から 13.78.61.196 (東日本の Azure SQL Database ゲートウェイの IP アドレス：TCP 1433 ポート) に対してセッションを確立後、 10.0.0.5 から 40.79.192.8 (データベースが配置されているノード : TCP 11079) に対してセッションが確立されていることが確認できます。
※ 東日本リージョンの Azure SQL Database ゲートウェイIPアドレス (2020年8月時点)
■ Azure 仮想マシンに紐づくネットワーク セキュリティ グループ (NSG) でファイアウォールの送信側(Outbound) を制限している場合の対処方法
Azure 仮想マシンに紐づくネットワーク セキュリティ グループ (NSG) でファイアウォールの送信側(Outbound) を制限している場合、宛先に「サービスタグ」 (東日本の Azure SQL Databaseの場合「Sql.JapanEast」、ソース「任意」および 以下のポートを許可することで、Azure SQL Database ゲートウェイの IP アドレスが増減したとしても、影響を及ぼすことなく、Azure SQL Database に接続することが可能になります。
[許可するポート]
TCP : 1433 (Azure SQL Database ゲートウェイへの接続に使用)
TCP : 11000-11999 (クライアントからデータベースが配置されているクラスタノードへの接続時に使用)
TCP : 1434, 14000-14999 (DAC(データベース管理者用の診断接続)による接続時に使用)
[NSG 設定例]
参考 URL
