MENU

Azure Data Factoryの自己ホスト型IRからSQLマネージドインスタンスに接続できない原因と解決策

Azure

Azure Data Factory の自己ホスト型統合ランタイム（SHIR）から SQL マネージド インスタンス（MI）へつなごうとすると「Pre-Login ハンドシェイクのタイムアウト」や「SQL Database に接続できません（firewall を確認してください）」と怒られることがあります。一方で同じリンク サービスを AutoResolve 統合ランタイムに切り替えるとあっさり通る……この「SHIR だけダメ問題」を、ネットワーク目線で根本原因から整理し、具体的な解決手順・確認方法をまとめます。

目次

自己ホスト型 IR から SQL マネージド インスタンスに接続できないときの状況整理

今回の前提となる構成は次のようなイメージです。

  • Azure Data Factory（ADF）から SQL マネージド インスタンス（MI）のデータベースへ接続したい
  • 統合ランタイムとして、オンプレミスまたは Azure VM 上にインストールした 自己ホスト型統合ランタイム（SHIR） を使用している
  • リンク サービスの接続テストで、次のようなエラーが発生する
    • 「SQL Database に接続できません。… firewall を確認してください」
    • 「Pre-Login ハンドシェイクの応答待ちでタイムアウト」
    • 接続先サーバー：<mi-public-endpoint>.database.windows.net,3342
  • 同じリンク サービスを AutoResolve（マイクロソフト管理 IR） に切り替えると接続成功する

この時点で分かることは、「資格情報や接続文字列そのものはおおむね正しい」「MI 側も完全に閉じているわけではない」ということです。
問題は、SHIR から MI（正確には Azure SQL ゲートウェイ）までのネットワーク経路のどこかでブロックや介入が起きている可能性が高い、という切り分けになります。

なぜ AutoResolve では成功して SHIR では失敗するのか

まずは、2 つの統合ランタイムの違いを押さえておきましょう。

統合ランタイム実行される場所発信元 IP / ネットワークネットワーク制御の主体
AutoResolve（マネージド IR）マイクロソフト管理の Azure 環境Azure データセンター内の IPマイクロソフト（ユーザーは変更不可）
自己ホスト型 IR（SHIR）オンプレサーバー or Azure VM など、ユーザー環境社外向け NAT IP / VM のグローバル IPユーザー（ファイアウォール、プロキシ、NSG などを自前で設定）

AutoResolve は Azure 内部から Azure SQL へ接続するため、Azure SQL 側の経路はあらかじめ考慮済みです。一方 SHIR は、社内ネットワークや Azure VM 上からインターネット越しに接続します。そのため、

  • オンプレミスやクラウド側の ファイアウォール / プロキシ / UTM / NSG
  • DNS などの 名前解決設定
  • TLS/SSL インスペクション（HTTPS 以外を含む暗号化通信の中身検査）

など、ユーザー側のネットワークポリシーの影響を強く受けます。
つまり、「AutoResolve では繋がるが、SHIR では繋がらない」＝ SHIR 側のネットワーク経路だけがブロック／介入されている という非常に強いシグナルです。

結論：原因の 9 割は「ネットワーク到達性 or TLS インスペクション」

今回のようなエラーが出るときの代表的な原因は次の通りです。

  • MI の公開エンドポイントが無効、またはファイアウォールに SHIR のグローバル IP が登録されていない
  • SHIR 側のネットワークで *.database.windows.net:3342 への アウトバウンド通信が拒否 されている
  • TLS/SSL インスペクション が介入し、Pre-Login ハンドシェイクが破綻している
  • 透過型プロキシが 3342/TCP を誤って中継・改変している
  • DNS のスプリット ブレインなどにより、<mi-public-endpoint>.database.windows.net が誤った IP アドレスに解決されている

中でも Pre-Login ハンドシェイクでのタイムアウト は、TLS インスペクションやプロキシによる中途半端な介入でよく見られます。
逆に言えば、MI 側の公開エンドポイントとファイアウォール設定、SHIR 側のアウトバウンド通信（特に 3342/TCP）、そして DNS と TLS インスペクション の 3 点を押さえれば、かなりの確率で問題を解決できます。

SQL マネージド インスタンス側の設定を確認する

まずは、SQL マネージド インスタンス（MI）側で SHIR からの接続を受け入れられる状態かを確認します。

公開エンドポイント（Public endpoint）が有効か確認

  1. Azure ポータルで対象の SQL マネージド インスタンスを開く
  2. 「ネットワーク」メニューを開く
  3. Public endpoint が 有効（Enabled） になっていることを確認

無効な場合、外部（インターネット）から MI に接続することはできないため、SHIR からの接続は必ず失敗します。

ポート番号の理解：1433 と 3342 の違い

SQL MI では、接続方式によって使用するポートが異なります。

接続経路接続先ホスト名のイメージポート主な用途
VNet 内（プライベート接続）<mi-name>.database.windows.net など1433/TCP同じ VNet / ピアリング VNet からの接続
公開エンドポイント（Public endpoint）<mi-public-endpoint>.database.windows.net3342/TCPインターネット経由で MI に接続するとき（今回のケース）

SHIR から公開エンドポイントに接続する場合、リンク サービスのサーバー名は次の形式になっているはずです。

&lt;mi-public-endpoint&gt;.database.windows.net,3342

よくあるミスとして、1433 だけを許可して 3342 を閉じたまま になっているケースがあります。必ず 3342/TCP も許可しているか確認しましょう。

MI のファイアウォールに SHIR のグローバル IP を登録

MI の公開エンドポイントに接続する場合、SHIR から見たインターネット向け「発信元グローバル IP」 を MI のファイアウォールに登録する必要があります。

  • オンプレミスの SHIR：
    • 社外向けファイアウォール / NAT 装置が持つグローバル IP が発信元として見える
    • 社内から外部サイトへアクセスしたときのグローバル IP と同じことが多い
  • Azure VM 上の SHIR：
    • VM に直接割り当てたパブリック IP、もしくは NAT Gateway のパブリック IP が発信元 IP になる

Azure ポータルからの設定イメージは次のようになります。

  1. MI の「ネットワーク」→「ファイアウォール」設定画面を開く
  2. 「ファイアウォール ルールを追加」から
    • ルール名：任意（例：SHIR-OnPrem）
    • 開始 IP アドレス / 終了 IP アドレス：SHIR の発信元グローバル IP（単一 IP なら同じ値）
  3. 設定を保存

発信元 IP を誤ると、「firewall を確認してください」というエラーになります。NAT 構成が変わっていると、過去に登録した IP が無効になっていることもあるので、疑わしい場合は改めて正しい IP を確認しましょう。

SHIR 側ネットワークのアウトバウンド許可設定

MI 側が正しく設定されていても、SHIR 側から *.database.windows.net:3342 へ出て行けなければ接続は成功しません。オンプレミス環境や Azure VM 側のネットワーク制御を整理します。

最低限必要なアウトバウンド通信

項目値補足
宛先 FQDN*.database.windows.netAzure SQL ゲートウェイ。IP は動的で固定しづらい
宛先ポート3342/TCPMI の公開エンドポイント用データ ポート
方向アウトバウンド（送信）SHIR からインターネットへの通信を許可
プロキシ / TLS インスペクション無効 / バイパス*.database.windows.net:3342 は 検査対象から除外 する

ポイントは、ポート 3342/TCP をそのままインターネットまで通す ことと、TLS を中身までこじ開けない ことです。

オンプレミス FW / UTM での設定イメージ

代表的なファイアウォールルールのイメージは次の通りです。

項目設定例
送信元SHIR サーバーの IP、またはその所属セグメント
宛先インターネット（Any）
プロトコル / ポートTCP / 3342
アクション許可（Allow）

Azure SQL ゲートウェイの IP レンジは動的に変わりうるため、オンプレ FW で IP 単位に厳密制御したい場合は高い運用コストがかかります。実務的には「SHIR セグメントからインターネット向け 3342/TCP は許可」という書き方のほうが現実的なことが多いです。

Azure VM ＋ NSG で SHIR を動かしている場合

SHIR を Azure VM にインストールしている場合、NSG（ネットワーク セキュリティ グループ）の送信ルールも確認します。

  • 送信元：VirtualNetwork または該当サブネット
  • 宛先：Internet
  • プロトコル：TCP
  • 宛先ポート範囲：3342
  • アクション：Allow
  • 優先度：既存の Deny ルールより小さい値

NSG は FQDN ベースの制御ができないため、「Internet 宛 3342/TCP を許可する」形になります。さらに高度な制御をしたい場合は Azure Firewall や NVA を組み合わせ、FQDN やサービス タグを使った制御も検討してください。

TLS インスペクション / プロキシからの除外

最近の企業ネットワークでは、HTTPS の中身を検査するために TLS インスペクションを導入しているケースが増えています。しかし、SQL Server の TLS ハンドシェイクは HTTP 前提ではないため、HTTP プロキシや TLS インスペクションで中途半端に介入すると、Pre-Login ハンドシェイクの段階でタイムアウトしたり、予期せぬ通信エラーが発生しがちです。

そのため、

  • *.database.windows.net:3342 宛の通信は
    • 透過型プロキシの対象外
    • TLS インスペクションの対象外
    にする
  • PAC ファイルなどで HTTP/HTTPS 以外のポートを誤ってプロキシ経由にしていないか確認する

ことが重要です。

DNS と名前解決の確認

SHIR が参照している DNS サーバーが、<mi-public-endpoint>.database.windows.net を正しくインターネット上の Azure SQL ゲートウェイに解決できているかも確認すべきポイントです。

nslookup で解決先を確認

SHIR が動いているサーバー上で、次のコマンドを実行します。

nslookup &lt;mi-public-endpoint&gt;.database.windows.net

期待されるのは、

  • インターネット上のグローバル IP アドレスが返ってくる
  • 社内用のプライベート IP（10.x / 172.16-31 / 192.168.x など）が返ってこない

という状態です。もし社内 DNS が同じゾーン名を持っていて、プライベート IP を返している場合、DNS のスプリット ブレイン が起きており、意図しない宛先に接続しようとして失敗している可能性があります。

プロキシの PAC 設定も確認する

クライアント側で PAC ファイルを使ってプロキシを振り分けている環境では、

  • *.database.windows.net への HTTP/HTTPS 通信をプロキシ経由にするのは良いとしても
  • 3342/TCP といった非 HTTP/HTTPS ポートまでプロキシに投げてしまう と、プロキシが理解できず切断されてしまう

といった事故が起きがちです。PAC の条件式で、ポート番号を見てバイパスするなどの工夫が必要です。

リンク サービス（ADF 側）設定のチェックポイント

ネットワーク周りに目が行きがちですが、リンク サービスの設定も改めて確認しておきましょう。

  • サーバー名：
    • <mi-public-endpoint>.database.windows.net,3342 になっているか
    • カンマ区切りでポート番号 3342 が指定されているか
  • データベース名：接続したい MI 上のデータベース名
  • 認証：
    • SQL 認証の場合：ユーザー名 / パスワードが正しいか
    • Azure AD 認証の場合：マネージド ID / サービス プリンシパルに MI への接続権限があるか

AutoResolve 統合ランタイムで接続テストが成功しているのであれば、資格情報や DB 名は正しい可能性が高いですが、SHIR のときだけ接続文字列を変えているといったケースもあり得ます。念のため両者の設定を比較しておくと安心です。

実際の動作確認・トレース手順

ここからは、SHIR が動作しているサーバー上で実行できる具体的な確認手順を紹介します。

1. 名前解決（DNS）の確認

nslookup &lt;mi-public-endpoint&gt;.database.windows.net

前述の通り、返ってくる IP アドレスがプライベートかグローバルかを確認します。もし結果が社内 DNS 由来のものに見える場合は、DNS 設定から見直しましょう。

2. ポート到達性（L3/L4）の確認

Windows Server であれば、Test-NetConnection コマンドレットが便利です。

Test-NetConnection &lt;mi-public-endpoint&gt;.database.windows.net -Port 3342

結果の TcpTestSucceeded が True であれば、TCP レベルでは 3342 まで到達できています。False の場合は、

  • オンプレ FW / NSG / ルーターで 3342 が閉じている
  • 経路上で ICMP は通るが当該ポートだけ閉じている

などが疑われます。

3. SQL プロトコルでの疎通確認（sqlcmd）

ポートに到達できていても、TLS インスペクションなどで SQL プロトコルのハンドシェイクが壊れている可能性があります。sqlcmd を使って実際に接続してみましょう。

sqlcmd -S tcp:&lt;mi-public-endpoint&gt;.database.windows.net,3342 ^
  -d &lt;database_name&gt; ^
  -U &lt;user_name&gt; -P &lt;password&gt; ^
  -N -l 15
  • -N：暗号化（Encrypt）を有効化
  • -l 15：タイムアウトを 15 秒に設定

ここで Pre-Login エラーやタイムアウトが発生する場合は、TLS インスペクションやプロキシの介入を重点的に疑います。逆に sqlcmd では成功するのに ADF からだけ失敗する場合は、ADF 側のリンク サービス設定や SHIR のバージョンも確認しましょう。

4. Windows ファイアウォール / ネットワークトレース

サーバー側でパケットのドロップ状況を確認するため、以下のような方法があります。

  • Windows Defender ファイアウォールのログ
    • %systemroot%\system32\LogFiles\Firewall\pfirewall.log を有効化し、3342/TCP のドロップを確認
  • netsh trace を使ったトレース採取 netsh trace start capture=yes scenario=NetConnection rem ADF からの接続テストを実行 netsh trace stop 生成された ETL を Microsoft Message Analyzer や Wireshark で解析し、どのタイミングで通信が切断されているかを確認します。

5. ネットワーク機器側ログとの突き合わせ

オンプレ FW や UTM、Azure Firewall、NSG フローログといったネットワーク機器のログと、SHIR / Windows 側のログを タイムスタンプで突き合わせる と、どこでブロックが発生しているかを特定しやすくなります。

特に次のようなログを探してみてください。

  • 送信元：SHIR サーバー or そのサブネット
  • 宛先：*.database.windows.net に相当する IP
  • 宛先ポート：3342
  • アクション：Deny / Drop

SHIR 固有のログも活用する

自己ホスト型 IR には、接続試行やジョブ実行結果に関するログが出力されています。既定では、インストールフォルダ配下の Logs ディレクトリなどに保存されています。

  • 接続テストやパイプライン実行のタイミングで、該当時刻のログを確認
  • エラーが出ている時間帯を、ネットワーク機器ログと突き合わせる

これにより、「SHIR はこのタイミングで MI に接続しようとしている」「そのタイミングでネットワーク機器がブロックしている」といった因果関係を明確にできます。

よくある落とし穴チェックリスト

最後に、実際の現場でよく見かけるミスをチェックリストとしてまとめます。トラブルシューティングの際に、一つずつ潰していくと効率的です。

  • MI の 公開エンドポイントが無効 のままになっている
  • MI の ファイアウォールに SHIR のグローバル IP が登録されていない
  • 社外向け NAT 構成が変わり、過去に登録した IP が変わっているのに更新していない
  • 1433 のみ許可して 3342 を許可し忘れている
  • *.database.windows.net:3342 を
    • TLS インスペクションの除外対象にしていない
    • 透過プロキシ / PAC 設定で誤ってプロキシ経由にしている
  • Azure VM 上の SHIR で、NSG の送信ルールが Internet 宛 3342/TCP を Deny している
  • DNS がスプリット ブレインを起こしており、.database.windows.net を社内アドレスに解決している

公開エンドポイントを使わない代替アーキテクチャ

セキュリティ要件が厳しい環境では、「MI の公開エンドポイントをそもそも使いたくない」という要望も多くあります。その場合は、次のような構成を検討できます。

プライベート エンドポイント（Private Link）で MI に接続

  • MI に対して プライベート エンドポイント を作成
  • MI への接続を VNet 内のプライベート IP に限定し、インターネット経由の公開エンドポイントを無効化
  • ポートは通常の SQL ポート（1433/TCP）を利用

この場合、SHIR も MI と同じ VNet またはピアリングされた VNet に配置し、Site-to-Site VPN や ExpressRoute を通じてオンプレからその VNet へ接続する形になります。

ADF マネージド仮想ネットワーク + マネージド IR を使う

  • ADF の マネージド仮想ネットワーク を有効化
  • その中に マネージド IR を配置し、MI とはプライベート エンドポイント経由で接続
  • データ経路がすべて Azure 内で完結し、インターネットに露出しない

この構成では、自己ホスト型 IR を使う必要がなくなるケースもあります。オンプレソースとの連携が必要な場合だけ SHIR を残し、クラウド完結のシナリオはマネージド IR に寄せる、といったハイブリッドな設計も有効です。

ストーリーで追う：実際の切り分けフロー例

最後に、実際のトラブルシューティングの流れを簡単なストーリー形式で整理してみます。

  1. まず AutoResolve IR に切り替えて接続テスト
    • → 成功したので、MI 側の基本設定（DB 名や資格情報）は正しそうだと判断
  2. SHIR に戻し、SHIR サーバー上で Test-NetConnection を実行
    • → TcpTestSucceeded=False だったため、「そもそも 3342 へ到達できていない」と判明
  3. オンプレ FW のログを確認
    • → SHIR セグメントからの 3342/TCP が Deny されているエントリを発見
    • → 3342/TCP のアウトバウンド許可ルールを追加
  4. 再度 ADF から接続テスト
    • → 今度は Pre-Login タイムアウトに変化
  5. プロキシ / TLS インスペクションの設定を確認
    • → *.database.windows.net:3342 も TLS インスペクション対象になっていることが判明
    • → 除外設定を追加
  6. SHIR から sqlcmd で接続テスト
    • → 正常に接続できることを確認
  7. ADF のリンク サービスからも接続テスト
    • → テスト成功、パイプラインも正常完走

このように、「AutoResolve では通るが SHIR では通らない」という状況は、ネットワーク側の設定の抜け漏れやセキュリティ機器の介入を浮かび上がらせる非常に良いヒントになります。
ポイントは、MI 側の許可（発信元 IP と公開エンドポイント） と SHIR 側のアウトバウンド許可（特に 3342/TCP と TLS インスペクション除外） の両輪で考えることです。

まとめ：SHIR から MI へ確実に接続するために

この記事の内容を簡単にまとめると次の通りです。

  • AutoResolve で成功 / SHIR で失敗 という事実は、SHIR 経路のネットワークに問題があることの強い証拠
  • MI 側では
    • 公開エンドポイント（Public endpoint）を有効化
    • SHIR の発信元グローバル IP をファイアウォールに登録
    • 公開エンドポイントでは 3342/TCP を使うことを理解しておく
  • SHIR 側では
    • *.database.windows.net:3342 へのアウトバウンド通信を許可
    • 透過プロキシ / TLS インスペクション / NSG によるブロックや介入を避ける
    • DNS が正しいグローバル IP に解決できているか確認
  • nslookup、Test-NetConnection、sqlcmd、netsh trace といったツールを組み合わせれば、どこでブロックされているかをかなりの精度で特定できる
  • よりセキュアな構成を求めるなら、プライベート エンドポイントや ADF マネージド VNet ＋ マネージド IR を組み合わせ、公開エンドポイントに依存しない構成も検討できる

SHIR と SQL マネージド インスタンスを組み合わせると、オンプレ／クラウドをまたぐ柔軟なデータ連携基盤を構築できます。その一方で、ネットワーク設計が甘いと「テスト接続が通らない」「Pre-Login で止まる」といった分かりづらいトラブルに悩まされがちです。
本記事のチェックポイントとトレース方法を押さえておけば、同様の問題に出会っても、落ち着いて原因を切り分け、短時間で復旧できるはずです。

Azure
ネットワーク ファイアウォール Azure Data Factory SQL Managed Instance 自己ホスト型IR

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次