将Umbrella DNS与HTTP代理一起使用

简介

本文档介绍如何将Umbrella DNS与HTTP代理配合使用。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档中的信息基于Umbrella全局DNS服务，不适用于安全网络网关(SWG)。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

HTTP代理会拦截网络上的HTTP/S流量。然后，它代表原始客户端与远程服务器建立HTTP/S连接，并将响应转发回该客户端。大多数HTTP代理能够根据分类或安全内容阻止到特定站点的连接，或者阻止来自远程服务器的响应，这些响应会包含恶意软件等不良内容。 

将HTTP流量重定向到代理有两种主要方法：显式重定向和透明重定向。这些不同的方法需要采取不同的步骤，才能与Umbrella结合正常发挥作用。

本文讨论HTTP代理如何影响Umbrella的行为和Umbrella解决方案的每个部分，然后提供两组显式重定向和透明重定向的步骤。 

下图是更详细地概述的解决方案的摘要：

proxy-umbrella-diagram.ping

HTTP代理如何影响Umbrella全局DNS服务

当拦截HTTP/S流量时，HTTP代理读取HTTP/S请求中的主机报头，并为该主机生成自己的DNS查询。因此，部署Umbrella解决方案时，必须考虑代理的行为。在抽象级别，这涉及确保到Umbrella IP地址的HTTP/S连接不会重定向到代理，而是直接发送到其预期目标。

网络保护

当仅使用Umbrella网络保护时，建议将HTTP代理本身配置为直接使用Umbrella进行DNS解析，或者它可以使用内部DNS服务器，后者进而将DNS查询转发到Umbrella。适当的外部IP地址可以在Umbrella控制面板中注册为网络标识。在这种情况下，无需执行其他操作即可使用Umbrella。

如果由于某种原因无法执行此操作，并且客户端本身正在使用Umbrella，则可以采取本文中详述的操作，以确保HTTP代理不会绕过实施。

Umbrella漫游客户端

使用Umbrella漫游客户端时，来自客户端计算机的DNS查询会直接发送到Umbrella。但是，由于HTTP代理执行自己的DNS查询，这会导致Umbrella漫游客户端的强制执行无效。因此，在代理环境中使用Umbrella漫游客户端时，必须遵守本文中详述的操作。

虚拟设备和Active Directory集成

虚拟设备(VA)用作受保护网络上客户端计算机的DNS服务器。因此，使用HTTP代理会以与漫游客户端相同的方式使其实施无效。因此，可采取本条所详述的行动，以确保执行有效且报告准确。

除了以下操作外，建议将HTTP代理配置为使用VA作为其DNS服务器。这允许您定义特定于代理的策略，以便可以识别来自代理的查询。此策略还允许您禁用对源自代理的查询的日志记录，从而避免在报告中存在重复的查询。

显式代理

部署显式代理需要修改浏览器代理设置，以便将流量显式重定向到代理。这可以通过在Windows中使用组策略完成，或者更常见的是通过使用代理自动配置(PAC)文件完成。无论哪种情况，这会导致浏览器将所有HTTP流量直接发送到代理，而不是发送到远程站点。因为浏览器知道代理生成自己的DNS请求，所以它不会费心解析远程站点本身的主机名。此外，如前所述，当HTTP连接到达代理时，代理会生成自己的DNS查询，此查询可得到与客户端不同的结果。 

因此，为了与Umbrella一起正常工作，需要进行两项更改：

1. 必须强制客户端进行DNS查询。
2. 发往Umbrella IP地址的HTTP连接不能转到代理，而应直接转到Umbrella。

这两种更改都可以使用PAC文件完成：

function FindProxyForURL(url, host) {    // Generate DNS request on the client    hostIP = dnsResolve(host);    // If the requested website is using an Umbrella IP address, return DIRECT    if (isInNet(hostIP, "67.215.64.0", "255.255.224.0") ||        isInNet(hostIP, "204.194.232.0",  "255.255.248.0") ||        isInNet(hostIP, "208.67.216.0",  "255.255.248.0") ||        isInNet(hostIP, "208.69.32.0",  "255.255.248.0") ||        isInNet(hostIP, "185.60.84.0",  "255.255.252.0") ||
        isInNet(hostIP, "155.190.0.0", "255.255.0.0") ||
        isInNet(hostIP, "146.112.0.0", "255.255.0.0")) ||
        isInNet(hostIP, "151.186.0.0", "255.255.0.0"))   
     {         return "DIRECT";     }     // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.    return "PROXY 192.0.2.5:8080; PROXY 192.0.2.6:8080";}

在此示例PAC文件中，首先生成DNS查询，结果的IP在hostIP变量中捕获。然后将此生成的IP地址与每个Umbrella IP地址范围进行比较。如果存在匹配，则查询不会发送到代理，而是直接发出。如果没有匹配项，则请求将发送到相应的代理。

请注意，对于未被阻止并因此未被重定向到Umbrella IP地址的站点，使用以前的PAC文件的效果是客户端和代理都向远程主机发出DNS请求。如果代理也使用OpenDNS，这意味着您的报告显示重复的查询。如果您使用的是虚拟设备（如前所述），可以通过为代理创建内部网络身份进行说明。如果需要，您可以为代理另外创建一个策略，完全禁用日志记录以隐藏这些重复请求。

注意：如果您在防火墙上阻止来自代理以外的源的出站HTTP/S请求，您必须确保允许这些请求访问前面讨论的IP范围，以允许计算机访问Umbrella阻止页面。

透明代理

对于透明代理，HTTP流量在网络级别重新路由到代理。由于客户端不知道代理，因此浏览器会生成自己的DNS请求。这意味着，如果代理也使用Umbrella，则每个请求都会重复。此外，策略应用不正确，因为代理使用它收到的DNS响应，而不是客户端收到的结果。

与本文前面部分中的明确事例不同，解决此问题不需要我们在客户端上强制DNS请求，因为这种情况已经发生。但是，仍然需要将HTTP连接的代理绕过到Umbrella IP地址。根据您使用什么机制将流量重定向到代理，执行此操作的方法差异很大。但是，一般来说，它涉及免除重定向Umbrella IP地址范围。

例如，假设思科ASA上使用WCCP使用以下ACL将流量重定向到代理：

access-list wccp-traffic extended permit ip any any 

可以修改wccp-traffic ACL以拒绝重定向到Umbrella IP范围的代理（从而绕过代理）：

access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0access-list wccp-traffic extended deny ip any 146.112.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 155.190.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 151.186.0.0 255.255.0.0

access-list wccp-traffic extended permit ip any any

注意：此ACL未经测试，因使用的ASA版本或Cisco IOS®版本而异。请确保您创建的任何ACL都适合您的解决方案，并且在部署到生产环境之前已经过彻底测试。

注意：如果您在防火墙上阻止来自代理以外的源的出站HTTP/S请求，您必须确保允许这些请求访问前面讨论过的IP范围，以便允许计算机访问Umbrella阻止页面。