Firebox での DNSWatch 構成の例
DNSWatch を有効化する前に、DNSWatch がどのようにネットワークに組み込まれるかを計画することが重要です。このトピックでは、DNSWatch が以下の項目とどのように統合されるか説明します:
- ローカル DNS サーバーありのネットワーク
- ローカル DNS サーバーなしのネットワーク
- Mobile VPN 構成
- 複数の内部ネットワーク
- BOVPN 構成
Firebox で DNSWatch を有効にすると、Firebox によって DNSWatch へリダイレクトされるアウトバウンド DNS 要求を制御する DNSWatch 実施設定が構成されます。ローカル DNS サーバーを利用していて、DNSWatch を無効化する場合は、Firebox での DNSWatch 構成の例 を参照してください。このトピックに含まれる他すべての例では、DNSWatch 実施が有効化されています。
実施設定の詳細については、次を参照してください:Firebox で DNSWatch を有効化する。
構成の例
これらの例は、DNSWatch の構成方法、および Firebox と ネットワーク上の他の DNS 設定の構成方法について説明します。これらの例では、Firebox は既定のネットワーク モードである混合ルーティング モードで構成されています。
DNSWatch 実施を有効にせずに DNSWatch でネットワークを保護したい場合は、この例の構成を使用します。これが最も一般的な構成です。
ネットワーク構成
DHCP
この例では、ネットワーク上に DHCP クライアントがあり、DHCP サーバーは Firebox またはローカル DHCP サーバーのいずれかです。
Firebox が DHCP サーバーである場合は、Firebox で DNS 転送を有効にします。DNS 転送が有効で、かつ Firebox が DHCP サーバーとして構成されている場合、Firebox は 独自の IP アドレスを DNS サーバーとして DHCP クライアントに提供します。
ローカル DHCP サーバーを使用している場合は、ローカル DNS サーバーを DHCP クライアントに提供するようローカル DNS サーバーを構成できます。
DNS
ローカル DNS サーバーでは、Firebox の IP アドレスでフォワーダを構成することをお勧めします。
この例では、Windows Server 2016 で Firebox IP アドレス 10.0.1.1 のフォワーダを構成します。
任意で、DNSWatch IP アドレスに向けてフォワーダを構成できます。
地域の DNSWatch の IP アドレスをすべて含む DNSWatch ダッシュボードで、これらの IP アドレスを取得できます。DNSWatch IP アドレスは、dnswatch.watchguard.com ドメインに解決されます。DNSWatch ダッシュボードの詳細については、DNSWatch ダッシュボード を参照してください。DNSWatch の IPアドレスが変更された場合、これらのフォワーダを手動で新しい IP アドレスに更新する必要があります。
DNSWatch サーバーをフォワーダとして指定する場合は、DNSWatch IP アドレス以外のフォワーダを構成しないことをお勧めします。DNS サーバーが DNS フォワーダに順次に接続するのではなく同時に接続するように構成されている場合、一部の DNS 要求が DNSWatch 以外の DNS サーバーに送信されることがあります。つまり、ユーザーは DNSWatch によって常に保護されるわけではないことを意味します。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。キャッシュをフラッシュすると、外部リソースの DNS 要求は、ローカル DNS サーバーのキャッシュではなく DNSWatch によって解決されます。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
信頼済みインターフェイスに 1 つの内部ネットワークがあります。
ネットワーク (グローバル) サーバー リストには、ローカル DNS サーバーとパブリック DNS サーバーが含まれます。Firebox 構成にローカル DNS サーバーを含める一般的な理由は次のとおりです:
- Firebox で DHCP を使用してローカル DNS サーバを配布したいが、Firebox に Interface DNS サーバーが構成されていない。
- Mobile VPN ユーザーが、ローカル ドメイン解決において、ネットワーク (グローバル) サーバー リストに指定されているローカル DNS サーバーを使用するようにする。
Mobile VPN ユーザーの DNSWatch 構成例については、このトピックの 例5 を参照してください。
ローカル ドメインの DNS 解決が機能するよう、リストの一番最初に DNS サーバーを表示する必要がある。
- 10.0.2.53
- 8.8.8.8
- 4.2.2.1
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域のサーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
DNSWatch には、WatchGuard サービスドメインの DNS 要求が DNSWatch に送信されないようにする例外リストが含まれています。実施を無効にすると、この例外リストは使用されません。DNSWatch の実施を無効にする場合、WatchGuard サービスドメイン watchguard.com、ctmail.com、および rp.cloud.threatseeker.com の条件付き DNS 転送ルールを構成することをお勧めします。構成するルールは、これらのサービスが最も近い地域のサーバーに接続するようにします。
DNSWatch の構成
DNSWatch の実施を無効にします。DNSWatch の実施を無効にすると、ネットワーク上のホストからの DNS 要求は DNSWatch の DNS サーバーを使用するようホストを手動で構成しない限り、DNSWatch に送信されません。ただし、Firebox は独自の DNS 要求に対して DNSWatch を使用します。
内部リソースへの DNS 要求
ネットワーク上のホストがネットワーク上の内部リソースの DNS 要求を送信すると、ローカル DNS サーバーがその要求を解決します。
Firebox 自体がローカル リソースに対する要求を生成する場合、Firebox リゾルバがローカル DNS サーバーに要求を転送します。
外部リソースへの DNS 要求
Firebox が DHCP サーバーとして構成され、DNS 転送が有効になっている場合
ネットワーク上のホストによって外部リソースへの DNS 要求が送信されると、その要求は Firebox IP アドレスに転送されます。Firebox は、キャッシュされた情報から要求を解決するか、条件付き DNS 転送ルールで指定された DNS サーバーに要求を転送するか、DNSWatch に要求を転送します。
ローカル DHCP サーバを使用しており、ローカル DNS サーバ上に Firebox IP アドレス用のフォワーダを設定した場合
ネットワーク上のホストが外部リソースへの DNS 要求を送信すると、ローカル DNS サーバーはその要求を Firebox にリダイレクトします。Firebox は、キャッシュされた情報から要求を解決するか、DNSWatch に要求を転送します。
Firebox で DNS 転送も有効にしていて、Firebox の DNS 転送ルールと DNS 要求が一致する場合、Firebox はそのルールで指定されている DNS サーバーに要求を転送します。
ローカル DHCP サーバを使用しており、ローカル DNS サーバ上に DNSWatch IP アドレス用のフォワーダを設定した場合
ネットワーク上のホストが外部リソースへの DNS 要求を送信すると、ローカル DNS サーバーはその要求を DNSWatch にリダイレクトします。
Firebox で DNS 転送も有効にしていて、Firebox の DNS 転送ルールと DNS 要求が一致する場合、Firebox はそのルールで指定されている DNS サーバーに要求を転送します。
この例では、ネットワークにローカル DNS サーバーが含まれません。
DNSWatch 設定で、実施を有効化します。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーが特定のドメインで他の地域の地域サーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
この例では、ネットワークの設定は以下の通りです。
ローカルネットワーク構成
ローカル DNS サーバーには、パブリック DNS サーバー用のフォワーダがあります。この例では、Windows Server 2016 で 8.8.8.8 および 4.2.2.1 のフォワーダを構成しています。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
信頼済みインターフェイスに 1 つの内部ネットワークがあります。
ネットワーク (グローバル) サーバーのリストには、以下のパブリック DNS サーバーのみが含まれています:
- 8.8.8.8
- 4.2.2.1
任意で、Firebox 自体がローカル ホスト名を解決する必要がある場合は、DNS 転送ルールを設定できます。
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域のサーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 にドメインのユーザーの要求を転送する DNS 転送ルールを構成できます。
DNSWatch の構成
DNSWatch 設定で、実施を有効化します。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
内部リソースへの DNS 要求
ネットワーク上のホストがネットワーク上の内部リソースの DNS 要求を送信すると、ローカル DNS サーバーがその要求を解決します。
Firebox 自体が example.com ネットワーク上のローカルリソースへの要求を生成すると、Firebox は example.com 用に設定した DNS 転送ルールを使用して、要求をローカル DNS サーバー (この例では 10.0.2.53) に転送します。
外部リソースへの DNS 要求
ネットワーク上のホストが外部リソースへの DNS 要求を送信すると、ローカル DNS サーバーはその要求をサーバー上に構成されているパブリック IP アドレスフォワーダにリダイレクトします。ただし、DNSWatch が有効になっているため、Firebox がこのトラフィックを検出すると、Firebox はキャッシュされた情報から要求を解決するか、要求を DNSWatch に転送します。
この例では、ネットワークの設定は以下の通りです。
ローカルネットワーク構成
ローカル DNS サーバーには、パブリック DNS サーバー用のフォワーダがあります。この例では、Windows Server 2016 で 8.8.8.8 および 4.2.2.1 のフォワーダを構成しています。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。キャッシュをフラッシュすると、外部リソースの DNS 要求は、ローカル DNS サーバーのキャッシュではなく DNSWatch によって解決されます。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
信頼済みインターフェイスに 1 つの内部ネットワークがあります。
ネットワーク (グローバル) サーバー リストには、ローカル DNS サーバーとパブリック DNS サーバーが含まれます。Firebox 構成にローカル DNS サーバーを含める一般的な理由は次のとおりです:
- Firebox で DHCP を使用してローカル DNS サーバを配布したいが、Firebox に Interface DNS サーバーが構成されていない。
- Mobile VPN ユーザーが、ローカル ドメイン解決において、ネットワーク (グローバル) サーバー リストに指定されているローカル DNS サーバーを使用するようにする。
Mobile VPN ユーザーの DNSWatch 構成例については、このトピックの 例5 を参照してください。
ローカル ドメインの DNS 解決が機能するよう、ローカル DNS サーバーのリストの一番最初に DNS サーバーを表示する必要がある。
- 10.0.2.53
- 8.8.8.8
- 4.2.2.1
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域の地域サーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
DNSWatch の構成
DNSWatch 設定で、実施を有効化します。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
内部リソースへの DNS 要求
ネットワーク上のホストがネットワーク上の内部リソースの DNS 要求を送信すると、ローカル DNS サーバーがその要求を解決します。
Firebox 自体がローカル リソースに対する要求を生成する場合、Firebox リゾルバがローカル DNS サーバーに要求を転送します。
外部リソースへの DNS 要求
ネットワーク上のホストが外部リソースへの DNS 要求を送信すると、ローカル DNS サーバーはその要求をサーバー上に構成されているパブリック IP アドレスフォワーダにリダイレクトします。ただし、DNSWatch が有効になっているため、Firebox がこのトラフィックを検出すると、Firebox はキャッシュされた情報から要求を解決するか、要求を DNSWatch に転送します。
DNSWatch で Mobile VPN ユーザーを保護するには、ネットワークにローカル DNS サーバーが必要です。これが必要な理由は、DNSWatch の実施がが信頼されているインターフェイス、オプショナル インターフェイス、またはカスタム インターフェイス上のホストにのみ適用されるためです。Mobile VPN ユーザートラフィックは、外部インターフェイスに到達します。つまり、DNSWatch の実施はそのトラフィックに適用されません。ただし、Mobile VPN のユーザーが Firebox 配下のローカル DNS サーバーに DNS 要求を送信すると、DNSWatch 実施が適用されます。
この例では、ネットワークの設定は以下の通りです。
ローカルネットワーク構成
ローカル DNS サーバーには、パブリック DNS サーバー用のフォワーダがあります。この例では、Windows Server 2016 で 8.8.8.8 および 4.2.2.1 のフォワーダを構成しています。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。キャッシュをフラッシュすると、外部リソースの DNS 要求は、ローカル DNS サーバーのキャッシュではなく DNSWatch によって解決されます。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
信頼済みインターフェイスに 1 つの内部ネットワークがあります。
ネットワーク (グローバル) サーバー リストには、以下のローカル DNS サーバーとパブリック DNS サーバーが含まれます:
- 10.0.2.53
- 8.8.8.8
- 4.2.2.1
1 つまたは複数の Mobile VPN 機能が有効化されています。Mobile VPN with IKEv2、Mobile VPN with SSL、Mobile VPN with L2TP、または Mobile VPN with IPSec。
Firebox の Mobile VPN 機能がネットワーク (グローバル) DNS サーバー リストを使用するように構成されている場合は、モバイル ユーザーのローカル ドメインの DNS 解決が正常に機能するように、ローカル DNS サーバーがリストの最初に表示されていなければなりません。
Mobile VPN クライアントから VPN に接続されると、Firebox で構成されている設定に基づいて、クライアントに DNS サーバー設定が割り当てられます。
Fireware v12.2.1 以降における Mobile VPN ユーザーの DNS
- この例では、Mobile VPN クライアントで Firebox のネットワーク DNS サーバー リストが使用されます。
つまり、Mobile VPN クライアントで、Firebox のネットワーク DNS サーバー リストに構成されている最初の DNS サーバー (この例では 10.0.2.53) および DNSWatch DNS サーバー 1 つが取得されます。すべての Mobile VPN 構成で、これが既定の DNS 設定となります。 - ネットワーク DNS サーバー リストを使用しない場合は、Mobile VPN ユーザーにのみ適用される DNS サーバー設定を指定します。
Mobile VPN 構成で、ローカル DNS サーバーがリストの最初に表示されることを確認してください。また、DNSWatch DNS サーバーも指定する必要があります。DNSWatch IP アドレスが変更された場合は、手動で Mobile VPN 構成の DNS 設定を新しい IP アドレスに更新する必要があります。ヒント!
Fireware v12.2 以前の Mobile VPN ユーザーの DNS
- この例では、Mobile VPN with IPSec、Mobile VPN with L2TP、および Mobile VPN with IKEv2 クライアントは、Firebox (この例では10.0.2.53) のネットワーク DNS サーバー リストに構成されている最初の DNS サーバーと DNSWatch DNS サーバー 1 つを取得します。
- Mobile IKEv2、IPSec、または L2TP VPN ユーザーのみに適用される DNS サーバー設定を指定することはできません。
- Mobile VPN with SSL の場合、Mobile VPN クライアントは、Mobile VPN with SSL 設定で構成されている DNS サーバーを取得します。
Mobile VPN with SSL 構成で、ローカル DNS サーバーがリストの最初に表示されることを確認してください。また、DNSWatch DNS サーバーも指定する必要があります。DNSWatch の IP アドレスが変更された場合は、新しい IP アドレスを使用して Mobile VPN with SSL 設定を手動で更新する必要があります。ヒント!
Mobile VPN クライアントの DNS 設定の詳細については、DNS および Mobile VPN を参照してください。
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域の地域サーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
DNSWatch の構成
DNSWatch 設定で、実施を有効化します。この設定は、信頼されているインターフェイス、オプショナル インターフェイス、またはカスタム インターフェイスに接続されている内部ネットワークにのみ適用されます。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
DNSWatch の実施は、外部インターフェイスには適用されません。つまり、Mobile VPN ユーザーには適用されないということです。ただし、Mobile VPN ユーザーは、VPN トンネル経由でローカルの DNS サーバーに DNS 要求を送信する場合、DNSWatch によって保護されます。
この例では、Mobile VPN クライアントが Firebox に接続すると、ローカル DNS サーバー 10.0.2.53 が取得されます。
この例では、Mobile VPN クライアントも DNSWatch DNS サーバーの IP アドレスを 1 つ取得します。Firebox 配下のローカル DNS サーバーが利用できない場合、Mobile VPN クライアントは DNS 要求を DNSWatch DNS サーバーに送信します。ただし、この場合、DNSWatch はパブリック DNS リゾルバとしてのみ機能します。DNSWatchは、生成された DNS 要求が DNSWatch に登録された Firebox ではなく、Mobile VPN ユーザーによって生成されたため、既知の悪質なドメインへの接続を防止できません。
内部リソースと外部リソースに対する DNS 要求
フルトンネルでの VPN 接続とスプリットトンネルでの VPN 接続の両方で、モバイルユーザからのすべての DNS 要求は、VPN トンネル経由で Firebox に送られます。Firebox 配下にあるローカル DNS サーバーが要求を解決できない場合、要求はそのリスト内の最初の DNS フォワーダ (この例では 8.8.8.8) へ要求をアドレス指定します。
ただし、DNSWatch 実施が有効化されているため、Firebox はポート 53 のトラフィックを監視します。Firebox リゾルバは、キャッシュを確認して要求を解決します。キャッシュした情報で要求を解決できない場合、Firebox は要求を DNSWatch に転送します。
この例では、ネットワークの設定は以下の通りです。
ローカルネットワーク構成
ネットワーク A には、パブリック DNS サーバーのフォワーダがあるローカル DNS サーバーがあります。ネットワーク B のホストは、ネットワーク A のローカル DNS サーバーを使用しています。
ローカルの DNS サーバーには、8.8.8.8 と 4.2.2.1 のフォワーダがあります。この例では、Windows Server 2016 でフォワーダを構成しています。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。キャッシュをフラッシュすると、外部リソースの DNS 要求は、ローカル DNS サーバーのキャッシュではなく DNSWatch によって解決されます。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
1 つの Firebox に 2 つの内部ネットワークがあります。
ネットワーク (グローバル) サーバー リストには、ローカル DNS サーバーとパブリック DNS サーバーが含まれます。ローカルの DNS サーバーは、リストの最初に表示されている必要があります。
- 10.0.2.53
- 8.8.8.8
- 4.2.2.1
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域の地域サーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
Firebox の設定には、ネットワーク A とネットワーク B 間の DNS トラフィックを許可するポリシーも必要です。
DNSWatch の構成
DNSWatch 設定で、実施を有効化します。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
内部リソースへの DNS 要求
ネットワーク A のホストが内部リソースの DNS 要求を送信すると、ネットワーク A のローカル DNS サーバーがその要求を解決します。
ネットワーク B のホストが内部リソースの DNS 要求を送信すると、ネットワーク A のローカル DNS サーバーがその要求を解決します。
Firebox 自体がローカル リソースに対する要求を生成する場合、Firebox リゾルバがネットワーク A のローカル DNS サーバーに要求を転送します。
外部リソースへの DNS 要求
ネットワーク A またはネットワーク B のホストが外部リソースへの DNS 要求を送信すると、ネットワーク A のローカル DNS サーバーはその要求をサーバー上に構成されているパブリック IP アドレスフォワーダにリダイレクトします。ただし、DNSWatch が有効になっているため、Firebox がこのトラフィックを検出すると、Firebox はキャッシュされた情報から要求を解決するか、要求を DNSWatch に転送します。
この例では、サイト A およびサイト B が BOVPN 経由で接続されています。ローカル DNS サーバーはサイト A にのみあります。
DNSWatch によって保護されるには、サイト B のユーザーは、サイト A のローカル DNS サーバーに DNS 要求を送信する必要があります。これは、DNSWatch の実施がが信頼されているインターフェイス、オプショナル インターフェイス、またはカスタム インターフェイス上のホストにのみ適用されるためです。BOVPN トラフィックは、外部インターフェイスに到達します。つまり、DNSWatch の実施はそのトラフィックに適用されません。ただし、BOVPN ユーザーが Firebox 配下のローカル DNS サーバーに DNS 要求を送信すると、DNSWatch 実施が適用されます。
BOVPN 構成では、サイト A で Total Security Suite の登録および DNSWatch が有効な場合、DNSWatch はサイト A に DNS 要求を送信する他のサイトに Basic Security Suite 登録しかない場合でも、他のサイトを保護します。
ネットワークには、この図の構成が適用されています。
ローカルネットワーク構成
サイト A には、パブリック DNS サーバーのフォワーダがあるローカル DNS サーバーがあります。サイト B のホストは、サイト A のローカル DNS サーバーを使用しています。
ローカル DNS サーバー (この例では Windows Server 2016 が搭載) で、8.8.8.8 と 4.2.2.1 でフォワーダを構成します。
ローカル DNS サーバーのキャッシュに、DNSWatch が悪質とみなすドメインのエントリが含まれている可能性があります。DNSWatch を有効にした後は、ローカル DNS サーバー上の DNS キャッシュをフラッシュすることをお勧めします。キャッシュをフラッシュすると、外部リソースの DNS 要求は、ローカル DNS サーバーのキャッシュではなく DNSWatch によって解決されます。
サーバーにおける DNS 転送設定の詳細については、お使いのオペレーティングシステムのマニュアルを参照してください。
DNSWatch は、ルート ヒントと互換性がありません。Windows サーバーで、フォワーダおよびルート ヒントの両方が構成されていると、フォワーダが応答しない場合はルート ヒントが使用されます。DNSWatch で最良の結果を得るには、フォワーダ タブの 使用可能なフォワーダがない場合はルート ヒントを使用する オプションを解除することをお勧めします。
Firebox 構成
サイト A とサイト B には、それぞれ別の Firebox があります。
どちらの Firebox には、以下があります:
- 信頼済みインターフェイスに 1 つの内部ネットワーク
- 外部インターフェイスで BOVPN ゲートウェイが構成済み
両方の Firebox のネットワーク (グローバル) サーバー リストには、サイト A のローカル DNS サーバーとパブリック DNS サーバーが含まれます。ローカルの DNS サーバーは、リストの最初に表示されている必要があります。
- 10.0.2.53
- 8.8.8.8
- 4.2.2.1
DNSWatch の構成
サイト A の Firebox では DNSWatch が有効になっています。
サイト A の Firebox の DNSWatch 設定で、実施を有効化します。この設定は、信頼されているインターフェイス、オプショナル インターフェイス、またはカスタム インターフェイスに接続されている内部ネットワークにのみ適用されます。実施が有効化されると、Firebox はネットワークのポート 53 のトラフィックを監視します。Firebox は、ネットワークのホストが様々な DNS サーバーで構成されている場合でも、ネットワークから DNSWatch へのすべてのアウトバウンド DNS 要求をリダイレクトします。
DNSWatch の実施は、外部インターフェイスには適用されません。ただし、BOVPN ユーザーは、VPN トンネル経由でローカルの DNS サーバーに DNS 要求を送信する場合、DNSWatch によって保護されます。
米国 (米国東部)、EU (アイルランド)、および APAC (日本およびオーストラリア) に、DNSWatch の地域サーバーがあります。ユーザーがドメインで他の地域のサーバーに接続することが重要である場合、条件付き DNS 転送ルールを追加できます。ルールでは、任意のドメイン名とパブリック DNS サーバーを指定します。
たとえば、DNSWatch ではなく 8.8.8.8 に example.com のユーザーの要求を転送する DNS 転送ルールを構成できます。
内部リソースへの DNS 要求
サイト A のホストが内部リソースの DNS 要求を送信すると、ローカル DNS サーバーがその要求を解決します。
サイト B のホストが内部リソースの DNS 要求を送信すると、サイト A のネットワーク上のローカル DNS サーバーがその要求を解決します。
Firebox 自体がローカル リソースに対する要求を生成する場合、Firebox リゾルバがサイト A のローカル DNS サーバーに要求を転送します。
外部リソースへの DNS 要求
サイト A またはサイト B のホストが外部リソースへの DNS 要求を送信すると、ネットワーク A のローカル DNS サーバーはその要求をサーバー上に構成されているパブリック IP アドレスフォワーダにリダイレクトします。ただし、DNSWatch が有効になっているため、Firebox がこのトラフィックを検出すると、Firebox はキャッシュされた情報から要求を解決するか、要求を DNSWatch に転送します。