web-dev-qa-db-ja.com

マルチインスタンスサーバーでのSQL Server Reporting Services（SSRS）IP処理

Tl; Dr

マルチインスタンスSQL Serverに専用のIPアドレスとポート（162.xxx.xxx.51：1433）を持つSQL Serverインスタンス（SQLSERVER01-i01）があります（Windows Server上の各SQL Serverインスタンスには独自のIPアドレスがあります） ）これらはすべて1つのWindowsサーバー（SQLSERVER01/162.xxx.xxx.50）で実行されています。

また、独自のIPアドレスとポート（168.xxx.xxx.71：1433）を持つ専用のReporting Servicesインスタンス（SQLSERVERRS01-i01）があり、独自のIPアドレス（168を持つ別のWindowsサーバー（SQLSERVERRS01）で実行されています.xxx.xxx.70）。

専用のReporting Servicesサーバーには、APPL1またはhttp://SQLSERVERRS01-i01:80/Reports_APPL1を介して到達できるアプリケーションhttp://SQLSERVERRS01:80/Reports_APPL1があります。

ホストヘッダーのReporting Services構成の*:80configurationのため、SSRSは両方の要求を取得します。

各IP範囲の間に複数のファイアウォールがあります。つまり、IP-to-IPまたはIPrange-to-IP接続ごとに特定のルールを適用する必要があります。 ただし、2台のサーバーが関与する場合、セキュリティにより、常にファイアウォールのIP-to-IPルールでなければならないことが規定されています。

質問

（さらに下のスクリーンショットに基づく）

Reporting ServicesサーバーがSQLサーバーインスタンス（162.xxx.xxx.51上）に接続してデータを取得する場合、常にWindowsサーバーの基になるIPアドレス（168.xxx.xxx.70 /推奨）との接続を構築します）SSRSが実行されているか、または（時々）SQL Server Reporting ServicesインスタンスのIPアドレス（168.xxx.xxx.71）を使用しますか？

これは、IP-to-IPアプローチを使用したファイアウォールルールの設定に関連しています。ポート1433を介した168.xxx.xxx.71から162.xxx.xxx.51への接続、または168.xxx.xxx.70から162.xxx.xxx.51への接続を定義するルールを適用する必要がありますポート1433。

現在、私は両方のファイアウォールルールに適用します。

ボーナス質問

専用IPアドレスと通信するようにReporting Servicesサーバーを構成できますか？この場合、アドレスは168.xxx.xxx.71です。

探していない回答

ファイアウォールの構成を最適化する方法や、ネットワークにゾーニングの概念を実装する方法についてのアドバイスは求めていません。 （すでにパイプラインに入っています）。さらに、SQL ServerとSSRSを同じサーバー上に配置することで問題が解決することを示すフィードバックには興味がありません。私はそれを知っており、喜んでそれを行いますが、SSRSコンポーネントと一緒に実行するために必要なサードパーティのソフトウェアについては。

できます

私が持っている構成は、SSRSとSQL Serverインスタンスの間に両方のファイアウォールルールを適用すると機能します。

168.xxx.xxx.71 --> 162.xxx.xxx.51 : 1433
168.xxx.xxx.70 --> 162.xxx.xxx.51 : 1433

安全にファイアウォールルールを1つ減らして、すべてが引き続き機能することを確認したいと思います。 （下のスクリーンショットを参照）
編集：これまでに読んだ記事は、2番目のルールだけが必要であることを示唆していますが、保証はありません。

すでに相談した記事

  1. SQL Serverインストールのセキュリティに関する考慮事項
    ベース記事。

  2. SQLサーバーアクセスを許可するようにWindowsファイアウォールを構成する
    この記事は、SQL Serverのファイアウォール構成に関する他のすべての記事を指しています。

  3. データベースエンジンアクセス用のWindowsファイアウォールの構成
    IPアドレスのワードは使用されていません。

  4. レポートサーバーアクセス用のファイアウォールの構成
    この記事は、次のようにかなり興味深いものでした：

    外部コンピューターのSQL Serverリレーショナルデータベースにアクセスする場合、またはレポートサーバーデータベースが外部SQL Serverインスタンスにある場合は、外部コンピューターのポート1433および1434を開く必要があります。

    ... IP構成/設定/デフォルトについての言葉ではありません。

  5. マルチホームのWindowsコンピューターでのソースIPアドレスの選択

  6. Windows Server 2008およびWindows VistaのソースIPアドレス選択の機能は、以前のバージョンのWindowsの対応する機能とは異なります

第5条と第6条は James （dba.se）によって提供されました。それらは現在最も適切な答えのようです。ただし、1つの記事で複数のNICの使用について言及しているのに少し懐疑的ですが、NICに複数のIPが割り当てられています。 Tom （dba.se）アドバイスや一般的なコメントも含まれています。

なぜここにあり、dba.stackexchange.comにはないのですか？

最初はこの質問の複雑な性質のため、serverfault.comにこの質問を投稿することに抵抗がありました。質問には、SQL Server固有の傾向とWindows Server固有の傾向の両方があります。最終的に私はそれをここに投稿することにしました。これは、Windows ServerのIPを処理するためのものだと思うからです（より良い言葉を失うため）。

モデレーターがdba.stackexchange.comでより適切な回答を得られると考えている場合は、質問をそこに移動してください。

長い説明

私たちの環境には、複数のSQL Serverインスタンスと複数のIP設定をホストするWindowsサーバーがあります。複雑なファイアウォール構成、専用のSQL Server Reporting Services（SSRS）サーバーを追加し、次のような環境を作成します。

Environment Overview

基本的に、個々のIPアドレスで最大15（15）のSQL Serverインスタンスを実行する1つのWindowsサーバーを持つことができます。同じことが専用のReporting Servicesインスタンスにも当てはまります。

ファイアウォールルール

現在、さまざまなIP範囲はゾーンとして構成されていません。つまり、各ファイアウォールルールを個別にIP-to-IPまたはIPrange-to-IPルールとして構成する必要があります。 2台のサーバーが関与する場合、セキュリティにより、常にIP-to-IPルールでなければならないことが規定されています。各SQL Serverインスタンスには独自のセットがあります通信に関与するファイアウォールのルールの集まりであり、これはサーバーからサーバーへのリンクまたはクライアントからサーバーへのリンクです。ファイアウォールルールを適用すると、現在4〜6週間の待機期間が発生します。ファイアウォールルールの量を減らすと、ネットワークセキュリティチームへのプレッシャーが軽減されます。

SQL ServerインスタンスのIP構成

専用IPおよびポートでのみピックアップするようにSQL Serverインスタンスを構成するには、SQL Server構成マネージャーユーティリティの一部の設定を変更します。最初のステップは、SQL Server構成マネージャーを起動し、左側のセクションでSQL Serverネットワーク構成を選択することです。 InstanceNameのプロトコル。左側のペインでTCP/IPプロトコル名を左クリックし、Enableプロトコル。次に、プロトコルを再度左クリックして、Properties for TCP/IPウィンドウを表示します。

次に、Protocolレジスタに次の設定が設定されていることを確認します。

Enabled           : Yes
Listen All        : No

IPアドレスレジスタで、問題のIPアドレスの次の設定を確認します（この例では、Reporting Servicesサーバーの場合、168.xxxになります） .xxx.71）

Active            : Yes
Enabled           : Yes
IP Address        : 168.xxx.xxx.71
TCP Dynamic Ports : 
TCP Port          : 1433

注：TCP Dynamic Ports isempty 0（ゼロ）だけではありません。

これで、ポート1433を使用して168.xxx.xxx.71上のデータベース接続のみをピックアップするSQL Serverインスタンスが作成されました。

SQL Serverインスタンスの概要

SQL Server Browserサービスは実行されておらず、個々のSQL Serverインスタンスは、ポート1433で独自のIPアドレスのみを使用するように構成されています。 .xxx.50（ホスト）と162.xxx.xxx.51（SQLインスタンス）次の構成項目になります。

Windows Server      : SQLSERVER01 
Windows Server IP   : 162.xxx.xxx.50
SQL Server Instance : SQLSERVER01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the Host itself)
SQL Server IP/Port  : 162.xxx.xxx.51:1433

SQL Serverは、162.xxx.xxx.50：1433の要求を取得しません。SQLServer構成マネージャーユーティリティでこのIPアドレスをリッスンするように構成されているSQL Serverインスタンスがないためです。 SQL Serverは、SQLSERVER01-i01（ポート1433）または162.xxx.xxx.51,1433の要求のみを取得します。

SQL Server Reporting Servicesインスタンスの概要

SQL Server Browserサービスが実行されておらず、個々のSQL Server Reporting Servicesインスタンスは、ポート1433で独自のIPアドレスのみを使用するように構成されています。GENERALというSQL Server Reporting Servicesインスタンスがあり、ホスト名がSQLSERVERRS01のWindowsサーバーであるアプリケーションAPPL1という名前のSSRSと2つのIPアドレス168.xxx.xxx.70（ホスト）と168.xxx.xxx.71（SQLインスタンス）で、次の構成項目になります。

Windows Server      : SQLSERVERRS01 
Windows Server IP   : 168.xxx.xxx.70
SQL Server Instance : SQLSERVERRS01-i01 (DNS A record)
SQL Server Instance : GENERAL (can only be used on the Host itself)
SQL Server IP/Port  : 168.xxx.xxx.71:1433
Reporting Services  : http://sqlserverrs01-i01/Reports_APPL1
                      http://sqlserverrs01/Reports_APPL1

SQL Serverは、168.xxx.xxx.70：1433の要求を取得しません。これは、SQL Server構成マネージャーユーティリティでこのIPアドレスをリッスンするように構成されているSQL Serverインスタンスがないためです。 SQL Serverは、SQLSERVER01-i01（ポート1433）または162.xxx.xxx.71,1433の要求のみを取得します。

SSRSは http：// sqlserverrs01-i01/Reports_APPL1 または http：// sqlserverrs01/Reports_APPL1 のいずれかの要求をピックアップします。ホストヘッダー。

回答を書くことに時間を費やす気がある人に十分な情報を提供できたと思います。技術的な詳細とリンクを楽しみにしています。

StackEdit で記述され、後でstackexchange互換になるように手動で変更されます。

歴史

編集1 ：初期リリース
編集2 ：読みやすくするために再フォーマットされています。説明SF/DBを下に移動しました。 Windows Serverのホスト名を追加
編集 ：ファイアウォールルールリストの誤ったIPアドレスを修正しました。
編集4 ：Wordホスティングを一部の場所で実行中（非仮想化環境）に変更しました。 IPアドレスを1文で追加
編集5 ：サポートを参照して参照した記事のリストを追加しました
編集6 ：履歴セクションのクリーンアップ

sql-serverfirewallwindows-server-2012-r2ipssrs
9
John aka hot2use

前書き

私が最初の調査で見つけたさまざまなドキュメントと、リンクやディスカッションで提供されたドキュメントによると、確実で信頼性の高い準拠ソリューションが思い付きました。

RFC 3484

さらに下で行われたバイナリ比較と適用されたルールは RFC 3484 に従っています。これは明らかにIPv4アドレスにも有効です。

RFC 3484は、ルール8の直後にも次のように述べています。

Rule 8 may be superseded if the implementation has other means of
choosing among source addresses.  For example, if the implementation
somehow knows which source address will result in the "best"
communications performance.

マルチホームWindowsコンピューターでのソースIPアドレスの選択

RFC 3484のすべてのルールがIPv4アドレスに適用されるわけではありません。 Microsoftブログの記事 マルチホームのWindowsコンピューターでのソースIPアドレスの選択 は、適用されるルールについて説明しています。

Windows Vista/Windows Server 2008 Behaviourのすぐ下に、次のような小さなセクションがあります。

XPと同様に、プログラムがソースIPを指定しない場合、スタックはターゲットIPアドレスを参照し、IPルートテーブル全体を調べて、パケットの送信に最適なネットワークアダプターを選択できるようにします。 。ネットワークアダプターが選択された後、スタックはRFC 3484で定義されたアドレス選択プロセスを使用し、そのIPアドレスを送信パケットのソースIPアドレスとして使用します。

SQL/SSRSインスタンスにNICが1つしかないので、最初の部分は無意味です。 Windows Serverは常に、利用可能な唯一のNICを選択します。

これまでのところ、RFC 3484とMicrosoftブログを組み合わせると、両方のIPアドレスがソースIPアドレスの有効な候補になります。説明は答えのさらに下に続きます。

ケーブルガイ

Cable Guyの記事 The Cable Guyの強力で弱いホストモデル は、Strong Host Sending and ReceivingでIP選択がどのように機能するかについて詳しく説明しています（---）環境と弱いホストの送受信環境。追加の読み取りは適切ですが、ソースIPがどのように選択されているかについては説明しません。この記事は、既知のRFC 3484に関連しています。

説明できないことを説明する

解決策を説明するために、まず問題のIPアドレスを同等のバイナリに変換する必要があります。私の質問ではゲートウェイを提供しなかったので、2つの値を想定します。

送信元IPアドレスとバイナリ表記

以下は、関連するIPアドレスの変換されたバイナリ値のリストです。

10101000.00000001.00000001.01000110   168.xxx.xxx.070/128   Windows Server
10101000.00000001.00000001.01000111   168.xxx.xxx.071/128   SQL Server / SSRS Instance
10101000.00000001.00000001.00000010   168.xxx.xxx.002/128   Gateway (Assumption 1)
10101000.00000001.00000001.01100010   168.xxx.xxx.100/128   Gateway (Assumption 2)
11111111.11111111.11111111.10000000   255.255.255.128/025   Subnet Mask / CIDR

ターゲットIPアドレスとバイナリ表記

10101000.00000000.00000000.00110011   168.xxx.xxx.051/128   SQL Server

例1：SQL/SSRSインスタンスIPよりも低いゲートウェイIP

この例では、ゲートウェイのIPアドレスがSQL Server/SSRSインスタンスのIPアドレス、つまり168.001.001.002よりも低いと仮定します。

Windows ServerとSQL Server/SSRSインスタンスの両方のバイナリアドレスを比較すると、次のようになります。

SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000111 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

Window Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 1)
10101000.00000001.00000001.01000110 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

結果の例1

この例では、両方のIPアドレスが同じ量の一致する上位ビット（または最長の一致するプレフィックス）を持っています。これまで、http.sysプロセスは発信通信にどちらかのIPアドレスを使用していました。

例2：SQL/SSRSインスタンスIPよりも高いゲートウェイIP

この例では、ゲートウェイのIPアドレスがSQL Server/SSRSインスタンスのIPアドレス、つまり168.001.001.100よりも大きいと仮定します。

Windows ServerとSQL Server/SSRSインスタンスの両方のバイナリアドレスを比較すると、次のようになります。

SQL/SSRS Instance IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (SQL/SSRS)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

Windows Server IP
10101000.00000001.00000001.00000010 (Gateway Assumption 2)
10101000.00000001.00000001.01100010 (Windows)
-----------------------------------
xxxxxxxx.xxxxxxxx.xxxxxxxx.x------- (x=matching high order bits)

結果の例2

ゲートウェイのIPアドレスがWindowsサーバーおよびSQL/SSRSインスタンスのIPアドレスよりも高い場合でも、一致する上位ビット（または最長の一致するプレフィックス）の量は同じです。これまで、http.sysプロセスは発信通信にどちらかのIPアドレスを使用していました。

これまでの調査結果のまとめ

これまでのところ、http.sysプロセスがWindowsサーバー（.70）のSQL/SSRSインスタンス（.71）で実行される発信通信に使用するIPアドレスを特定することは不可能です。

「あなたが不可能を排除したとき、どんなに残っていても、ありそうもないが、真実であるに違いない」-シャーロックホームズ

前述のRFCおよびMicrosoftの知識により、送信元IPアドレスを確実に特定/選択/定義できる状況があります。しかし、IPアドレスが互いに近すぎたり、ゲートウェイに近すぎたりする場合は、すべてが運に任されています。またはそれは？

私は（ファイアウォール）ルールを作成する立場にあり、Microsoftは...

実装（それ）には、送信元アドレスから選択する他の手段があります。たとえば、実装が何らかの方法でどの送信元アドレスが「最良の」通信パフォーマンスをもたらすかを知っている場合。

...そして、http.sysプロセスのIPアドレスを決定するために行う必要があるすべては、目的のIPアドレスを持つファイアウォールルールを1つだけ作成することです。

何が起こるのですか

  1. 168.xxx.xxx.71から168.xxx.xxx.51：1433までのファイアウォールルールを定義します
  2. SQL/SSRSインスタンスのhttp.sysコンポーネントはRFC 3484に準拠し、定義されたルールに従ってソースIPを選択します
  3. IPアドレス168.xxx.xxx.71（NIC1上）は、ポート1433を介してIPアドレス168.xxx.xxx.51に到達するためのソースIPアドレスとして決定され、すべての発信パケットに割り当てられます

利点

  1. 私はRFC 3484の実装を決して妨害していません
  2. 私はルートやARP構成をいじるつもりはありません
  3. RFC 3484およびMicrosoftの実装に準拠しています
  4. レジストリ設定やシステム構成をハッキングしていない
  5. ファイアウォールルールが1つ少ない

検証

ファイアウォールルールからIPアドレスを削除する必要はまだありませんが、設計/定義どおりに機能することを確信しています。要約が続きます。

歴史

編集1 最初の投稿
編集2 回答を整理し、履歴セクションを追加

6
John aka hot2use

SSRSは、いくつかの標準データソースと他の.NETデータソースをサポートします。

https://msdn.Microsoft.com/en-ca/library/ms159219.aspx

データソースにSQLネイティブクライアントを使用している場合、ソースIPアドレスを指定するオプションはありません。

https://msdn.Microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring（v = vs.110）.aspx

したがって、ネットワーク接続をセットアップするときに、クライアントがBind（）メソッド中にIPADDR_ANYを使用するのは当然のことです。これにより、Windowsが決定を下します。

Windows 2008以降のアドレス選択は、ネクストホップと一致する最大ビット数に基づいています。つまり、デフォルトゲートウェイ（または定義した特定のルート）によって答えが異なります。

https://blogs.technet.Microsoft.com/networking/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer/

ダイアグラムにはルートやゲートウェイについての言及はありませんでした。

幸運を！

4
Jens Ehrich