DAD & GARP & ARP Neighbor Cache

在Windows系统中，如何通过已知的IP地址找到对方设备的物理地址(MAC Address)呢？通常，Windows系统会通过ARP协议发送一个ARP请求，请求包含四个主要的属性：

1） SendersMacAddress

2） SendersIp4Address

3） TargetMacAddress

4） TargetIp4Address

SendersIp4Address和SendersMacAddress分别填上自己的IP和MAC，TargetIp4Adress会填上想要解析的对方的IP地址，TargetIPMACAddress置为00-00-00-00-00-00；网络上IP为TargetIp4Adress的设备收到此请求后，将会作出响应，响应内容是告诉请求发自己的MAC地址。如，

1      4:21:9 PM 7/30/2012               192.168.15.33 192.168.15.2  ARP    ARP:Request, 192.168.15.33 asks for 192.168.15.2     

  Frame: Number = 1, Captured Frame Length = 42, MediaType = ETHERNET

+ Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-15-5D-08-83-1E]

- Arp: Request, 192.168.15.33 asks for 192.168.15.2

    HardwareType: Ethernet

    ProtocolType: Internet IP (IPv4)

    HardwareAddressLen: 6 (0x6)

    ProtocolAddressLen: 4 (0x4)

    OpCode: Request, 1(0x1)

    SendersMacAddress: 00-15-5D-08-83-1E

    SendersIp4Address: 192.168.15.33

    TargetMacAddress: 00-00-00-00-00-00

    TargetIp4Address: 192.168.15.2

2      4:21:09 PM 7/30/2012              192.168.15.2  192.168.15.33 ARP    ARP:Response, 192.168.15.2 at 00-15-5D-08-83-16

  Frame: Number = 2, Captured Frame Length = 42, MediaType = ETHERNET

+ Ethernet: Etype = ARP,DestinationAddress:[00-15-5D-08-83-20],SourceAddress:[00-15-5D-08-83-16]

- Arp: Response, 192.168.15.2 at 00-15-5D-08-83-16

    HardwareType: Ethernet

    ProtocolType: Internet IP (IPv4)

    HardwareAddressLen: 6 (0x6)

    ProtocolAddressLen: 4 (0x4)

    OpCode: Response, 2(0x2)

    SendersMacAddress: 00-15-5D-08-83-16

    SendersIp4Address: 192.168.15.2

    TargetMacAddress: 00-15-5D-08-83-20

    TargetIp4Address: 192.168.15.8

原先的请求方收到这样的响应后，会将对方的IP和MAC作为动态的唯一的对应信息缓存在ARP缓存中。可以通过arp –a命令进行查看。

地址冲突监测(Duplicate Address Detection)机制也使用了ARP协议的这种请求：

当TCPIP协议栈接收到加载IP地址的事件(如重启机器，重启网卡，修改TCPIP属性)时，会通过ARP协议广播一种特殊的ARP请求，这种特殊ARP请求的TargetIPAdress会填上自己的IP地址，TargetIPMACAddress置为00-00-00-00-00-00；我们称之为GARP(Gratuitous ARP)。如，

52     6:40:00 PM 8/1/2012  40.3886896           192.168.15.2         192.168.15.2         ARP       ARP:Request, 192.168.15.2 asks for 192.168.15.2

  Frame: Number = 52, Captured Frame Length = 42, MediaType = ETHERNET

+ Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-15-5D-08-83-16]

- Arp: Request, 192.168.15.2 asks for 192.168.15.2

    HardwareType: Ethernet

    ProtocolType: Internet IP (IPv4)

    HardwareAddressLen: 6 (0x6)

    ProtocolAddressLen: 4 (0x4)

    OpCode: Request, 1(0x1)

    SendersMacAddress: 00-15-5D-08-83-16

    SendersIp4Address: 192.168.15.2

    TargetMacAddress: 00-00-00-00-00-00

    TargetIp4Address: 192.168.15.2

正常情况下，如果网络中没有IP地址冲突，是没有正对这种ARP请求的响应的；如果有响应，那么就说明，这个IP地址已有冲突，此时Windows也会弹出窗口提示有IP地址冲突发生。

另外，网络其他设备接收到这种广播的GARP以后，也会响应的更新他们的ARP缓存，创建一条IP地址和MAC地址的映射(SendersMacAddress和SendersIp4Address)。

Changes

相信以上的行为对大家来说，都并不陌生。

但是，从Windows Vista以后，以上两种行为有了较大的改进：

1.      Windows Vista\2008以后的操作系统在相同的情况下广播的GARP请求中，将不包含自己的IP地址，即SendersMacAddress置为0.0.0.0；如，

2.       Windows Vista\2008以后的操作系统在接收到任何形式的GARP请求时，不再更新自己的ARP缓存而仅通过直接的ARP请求和响应来更新ARP缓存；

有这两种改进的原因是：

在之前的系统版本中，所有能接收到GARP设备的系统都会将GARP内包含的IP和MAC信息作为映射存到ARP缓存中，如果该GARP中包含的IP实际上是地址冲突的地址，当地址冲突监测发现后，就会更改IP。但是接收方已经更新了ARP缓存，且短时间内不会删除，稍后便会造成错误的IP地址解析。

且这两处更改从代码上逻辑的更改，是不可调的。

Changes again

这样的更改固然是减少了由于IP地址冲突造成的一系列问题，但是同样，也对某些依靠GARP更新客户端ARP缓存的设备或架构收到影响，如，Windows Cluster和物理的容错机制。

当群集中发生Failover的时候，虚拟的IP地址迁移到新的节点（新的MAC地址），新的节点将会广播出GARP做IP地址冲突监测，同时，一些网路设备也完全依靠这样的GARP来更新他们的ARP缓存，如，一些硬件防火墙，交换机或路由设备。设想，如果群集设备是Windows 2008系统，广播出的GARP并不包含完整的IP和MAC映射信息，网络设备将无法更新自己的ARP缓存。造成这些问题的主要原因是大部分的网络设置在Windows 2000和2003期间，设计逻辑过于依赖GARP。因而造成群集在Failover之后，客户端无法联系群集的虚拟IP – 实际上是因为他们中间的路由设备无法通过GARP更新ARP缓存，也无法主动通过发送Unicast的ARP请求以获得响应。这样的问题对于同一个网段的客户端是没有任何影响的，因为他们不依赖于路由设备。不过目前，Windows暂没有针对这种类型的情况作出更新。

另外一种情况，Windows Vista/2008作为GARP的接收方时不能根据GARP更新自己的ARP缓存的问题，Windows在2008 R2期间出了针对于Windows Vista以后所有版本的补丁https://support.microsoft.com/kb/2582281. 该补丁再一次更改了其中一个行为，即“操作系统在接收到任何形式的GARP请求时，不再更新自己的ARP缓存而仅通过直接的ARP请求和响应来更新ARP缓存”，更改后，“操作系统在接收到由Windows Vista以前的操作系统（如，Windows XP或2003）发出的GARP时，可更新自己的ARP缓存； 接收到Windows Vista以后的系统发出的GARP时，仍不更新ARP缓存”。

文件重定向（Folder Redirection）是指通过组策略的配置将用户的“应用程序数据”、“桌面”、“我的文档”、“图片收藏”和“「开始」菜单”文件夹存储在制定的网络路径上并删除本地文件。

文件重定向的配置可以在组策略的如下位置：

User Configuration\Policies\Windows Settings\Folder Redirection

右键点击其中一个文件夹（如，Desktop），在属性页中进行配置。一般来说，选用Advanced配置，即在制定的网络路径下创建单独的User Folder（以用户名命名）。

组策略执行成功后，用户的桌面信息就不再是存在本地的了，而且从网络共享目录下读取，写入。

文件重定向和Offline Files

虽然文件重定向实现了对用户数据的集中管理和备份，但是因此而造成的网络流量也是不容忽视的。因此，从Windows Xp开始，文件重定向指向的网络路径也同时默认被设置为Offline Available。这一行为可以通过组策略“Do not automatically make all redirected folders available offline”进行修改。

案例背景

基于以上的背景信息，下面描述一个真实的案例：

Domain1的组策略设置Domain Users User Group用户的My Documents被重定向到\\filesvr\sharefolder路径。sharefolder的权限配置参照：https://technet.microsoft.com/en-us/library/cc736916(WS.10).aspx

 User1属于Domain Users，于是，User1第一次登陆后能在\\filesvr\sharefolder 下创建User1文件夹\\filesvr\sharefolder\User1\My Documents。并且，在User1登陆的客户端上CSC创建了对应的Offline Cache在C:\Windows\CSC\v2.0.6\namespace\filesvr\sharefolder\User1\My Document。

不久之后，客户的环境实施了一次Domain Migration。所有的用户账号也随之迁移到了新的域中，如从Domain1\User1到Domain2\User1。

因为Filesvr也同样做了Domain的迁移，客户将sharefolder的permission重新配置了一遍保证Domain2的用户有正确的权限（甚至于Full Control）。

然而，当Domain2\User1登陆时，他\她却始终无法看到My Documents里面的旧文件。他可以继续创建新的文件，并且通过Ip和FQDN访问sharefolder\User1\My Document目录时，他可以看到所有的文件，新的和旧的。

案例分析

这是为什么呢？

原来，此时用户的客户端本地已经生成了两份Cache – 一份是之前用户在Domain1时生成的，一份是用户在Domain2时生成的。Domain2\User1对旧的那份Cache没有访问权限。

当用户账号在做Domain Migration的时候，即使保持用户名不变，用户的primary Security Identifier (SID)却已经不一样了。而，Sid正好是CSC储存的Cache的重要属性之一。

CSC使用Sid来判断用户对Cache有无权限。那么，显然Domain2\User1是无法看到由Domain1\User1创建出来的Cache的。

同时，由于启用CSC的特殊性，即使是Online的情况下，访问网络路径前，都需要经过对本地Cache的判断。所以，如果User1对Cache没有权限，也无法看到\\filesvr\sharefolder\User1路径下的旧文件（账号迁移前）。

也许您会问，为什么创建新的Cache的时候不能从服务器上把旧文件下载再下来？

CSC在下载服务器文件的时候，仅对文件的路径进行比对，如果此路径的文件已经存在，那么下载无法进行（在这个案例里，特殊点在于，用户账号迁移前后用户名无变化，都是User1；如果用户名完全改变就不会存在任何问题了）。

解决方案

唯一的解决方案是：初始化客户端的CSC Cache。参照https://support.microsoft.com/kb/942974

考虑到数据丢失问题，建议使用Script对C:\Windows\CSC路径进行备份，须使用System账号。

CSC不能将\\filesvr.example.com\sharefolder\User1设置为offline的同时将\\filesvr.example.com\sharefolder\User2设置为online。它只能将\\filesvr.example.com\sharefolder\设置为online或者offline。

所以，当CSC在监测网络的Latency或Throughput的时候，实际上是在监测连接\\filesvr.example.com\sharefolder的Latency和Throughput。因此，我们在配置Configure Slow Link Mode组策略的时候，所设置的UNC路径必须是共享文件根目录,如,\\filesvr.exampl.com\sharefolder。

注意: 虽然组策略的示例中包含双引号,但是实际配置时不能使用双引号.

 如果,配置组策略时没有按照以上规则设置,组策略无法生效. 我们遇到过很多类似的问题,最终的解决方案是设置如下形式的组策略:

Value Name                                                   Value

\\filesvr.example.com\sharefolder     latency=30

另外, 在Windows 7系统中设置Slow Link Mode有两个阀值: Latency和Throughput. 注意,

1)      两个参数可以只设置一个;

2)      如果两个同时设置, CSC会优先判断Latency,且两个参数是取并集,如,当前网络连接的Latency大于阀值,直接转换成Offline模式；如果当前网络连接的Latency小于阀值，CSC检查当前的Throughput，如果小于阀值，转换成Offline模式；

3)      Slow Link模式的监测缺省情况下是每5分钟发生一次，当从Offline模式转换成Online模式时，仅监测Latency而不监测Throughput。

首先我们看一下什么是svchost.exe, 以及为什么这么多的服务都会受到svchost.exe的影响：

- Svchost.exe 是计算机上的一个进程，该进程包含Windows 用于执行各种功能的多个或单独服务。例如，Computer Browser service和Server service使用同一个 svchost.exe 进程宿主的服务。

- 可以有多个 svchost.exe 的实例在计算机上运行，其中每个实例都包含不同的服务。svchost.exe 的一个实例可能宿主程序的单个服务，而另一个实例则可能宿主与 Windows 相关的多个服务。可以在CMD窗口下运行tasklist -svc命令查看在 svchost.exe 的每个实例下正在运行的服务。见下图：

上图中如果PID为884的svchost.exe意外终止，那么所有对应于该PID的服务都将停止服务。可见造成的影响非常巨大。

什么是 svchost.exe？
https://windows.microsoft.com/zh-cn/windows-vista/What-is-svchost-exe#

那么svchost.exe意外终止后，如何解决呢？一般可以尝试下面的步骤：

1.       首先您可以手工启动受到影响的服务，或重启计算机以尽快从故障中恢复。

2.       其次可以检查计算机是否安装了以下补丁：

MS08-067 Security Bulletin - https://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx 

KB932762 https://support.microsoft.com/kb/932762/EN-US  

3.       如果您使用了System Center产品，该产品针对网卡的一些rules和monitors会触发Windows Server 2003系统netman的一个bug。该bug将导致与netman相关的svchost.exe异常终止。下面列出一些可能触发问题的rules和monitors：

Rules:

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedReads.Collection (Percent Bandwidth Used Read)

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedWrites.Collection (Percent Bandwidth Used Write)

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedTotal.Collection (Percent Bandwidth Used Total)

Monitors:

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedReads (Percent Bandwidth Used Read)

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedWrites (Percent Bandwidth Used Write)

-          Microsoft.Windows.Server.2003.NetworkAdapter.PercentBandwidthUsedTotal (Percent Bandwidth Used Total)

在这种环境下我们需要根据以下blog中的步骤禁用这些rules和monitors：

https://blogs.technet.com/b/kevinholman/archive/2011/12/12/opsmgr-network-utilization-scripts-in-baseos-mp-version-6-0-6958-0-may-cause-high-cpu-utilization.aspx

4.       如果以上方法都无法解决问题，那么svchost.exe可能由一些其他的原因导致。这种情况下我们可以做以下尝试：

     4.1 如果一个svchost.exe实例包含了多个服务，那么某个服务出现异常会导致这个svchos.exe终止。这个实例中的其他程序都受到影响。为了减小受影响的范围，我们可以把这些服务独立出来，每个svchost.exe实例仅包含一个服务。例如把netman服务独立出来的命令如下：

     Sc config netman type= own

    注：执行这个步骤后建议重启计算机使设置生效。

    4.2 联系微软技术支持中心，我们的工程师会协助您排查这个问题。为了提高排查效率，您可以先行收集dump（内存转储）文件。一般dump文件可以比较明确的发现原因。步骤如下：

-. 从以下链接下载 userdump tool 工具: (https://www.microsoft.com/downloads/details.aspx?FamilyID=e089ca41-6a87-40c8-bf69-28ac08570b7e&DisplayLang=en).

-. 运行该工具后，该工具会解压到默认文件夹 c:\kktools\userdump8.1. 根据您系统架构在x86 或 x64下运行setup.exe.

-. 之后在Control Panel 中打开Process Dumper 进行配置.

-. 点击 New 输入 svchost.exe 作为 Application Name. 点击 OK保存设置.

-. 高亮svchost.exe ，点击 Rules。

a. 选择 user custom rules.

b. 选择一个 文件夹用来存放生成的dump文件.

c. 在Exception Codes中高亮 Access Violation。

d. 将 minidump type 设置为 Complete.

-. 点击OK保存设置.

本文将讨论此类问题发生的原因，并分析碰到此类问题时可以采取的一些基本排错步骤。

注意：在您将本文提到的步骤或方法应用到您的实际环境中之前，请先使用Print Migrator Tool备份当前的所有设置。

当我们建立群集并在群集节点上安装打印机驱动时，安装进程会将打印机驱动程序文件复制到共享文件夹\\虚拟服务器\print$ 上， 打印机驱动程序同时会被复制到群集内 当前拥有此打印群集资源的节点上的本地文件夹： %SystemRoot%\System32\Spool\Drivers\<后台打印程序 GUID>\Drivers 。驱动程序还会被复制到共享磁盘的 \PrinterDrivers 文件夹中。

群集中打印机驱动信息存放在注册表键HKLM\CLUSTER\Resources\<Cluster Resource GUID>\Parameters\Environments\<Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name> 下，该打印驱动信息对应的是群集打印队列中关联打印机当前的最新打印驱动程序信息。同时在群集中各个节点本地，也维护着打印机驱动信息，对应打印驱动的文件，如上段提到，存放在文件夹SystemRoot%\System32\Spool\Drivers\<后台打印程序 GUID>\Drivers下，对应这些打印机驱动的信息，存放在节点注册表键HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>下。在将打印群集资源转移到其他节点的过程中，目标节点的Spoolsv.exe针对各个打印驱动，首先会检查上面提到的两个注册表键下的各个子健，其中包括键值Timestamp，如果HKLM\CLUSTER\Resources\<Cluster Resource GUID>\Parameters\Environments\<Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name> 下的Timestamp比HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>下的要新，或者目标节点上根本不存在HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Print Driver Name>这个键值，则表明该打印机驱动是打印服务处于其他节点上时发生了更新，或者是新安装上去的，spoolsv.exe此时需要将打印机驱动文件从共享文件夹处拷贝到该节点的本地文件夹下。

根据上述有关打印驱动复制的信息，我们可以得出结论：存放在群集节点本地的打印驱动程序文件，和在键值HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>下的信息，需要保持严格一致。如果因为某种原因，群集中某个节点的打印驱动程序实际信息和该打印驱动对应的键值不一致，就可能导致驱动程序在打印群集资源转移时复制不正常。

所以，当您发现群集中某个节点的某些打印驱动程序无法正常复制，请首先检查如下信息：

1. 节点上的注册表键值HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>
2. 同一节点，通过打印管理程序检查相应的打印机驱动程序是否存在，以及对应的版本信息。
3. 检查本节点和群集节点上的注册表键值注册表键HKLM\CLUSTER\Resources\<Cluster Resource GUID>\Parameters\Environments\<Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>。

如果您在检查上述信息时，发现对应节点上，注册表键值中有关驱动程序的信息和该节点本地实际存在的驱动程序不符，或者本地注册表键值中有关该驱动程序子健下的键值TimeStamp比HKLM\CLUSTER\Resources\<Cluster Resource GUID>\Parameters\Environments\<Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>下的TimeStamp要新，则表示该节点上，有关该驱动程序的相关注册表键值已经损坏或无效。

解决此问题，可以首先备份HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster Resource GUID>\ <Windows X86 or Windows X64>\Drivers\Version-3\<Printer driver name>键，之后将该键删除，并将群集打印资源再次转移到该节点上。

如果上述信息依然无法帮助我们解决该问题，我们可以在复现问题时，收集如下信息：

1. 1.       Netmon(download link https://www.microsoft.com/en-us/download/details.aspx?id=4865)
2. 2.       Procmon(download link: https://technet.microsoft.com/en-us/sysinternals/bb896645.aspx)

在其中您可以看到在打印资源转移过程中，目标节点的Clussvc.exe 和Spoolsv.exe进程会访问相关的注册表键值，如下所示：

8:30:11.8554361 AM        clussvc.exe         2088       RegOpenKey     HKLM\CLUSTER\Resources\<Cluster GUID>\Parameters\Environments\<Platform type>\Drivers\Version-3\<Driver name>\               SUCCESS             

8:30:11.8554772 AM        clussvc.exe         2088       RegQueryValue                HKLM\CLUSTER\Resources\<Cluster GUID>\Parameters\Environments\<Platform type>\Drivers\Version-3\<Driver name>\TimeStamp        SUCCESS                Type: REG_BINARY, Length: 16, Data: DC 07 04 00 04 00 13 00 0A 00 16 00 1C 00 D8 00

8:30:11.8555134 AM        clussvc.exe         2088       HKLM\CLUSTER\Resources\<Cluster GUID>\Parameters\Environments\<Platform type>\Drivers\Version-3\<Driver name>\               SUCCESS             

8:30:11.8556160 AM        spoolsv.exe        1284       RegCreateKey   HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster GUID>\<Platform type>\Version-3\<Driver Name> SUCCESS             

8:30:11.8556308 AM        spoolsv.exe        1284       RegQueryValue                HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster GUID>\<Platform type>\Version-3\<Driver Name>\TimeStamp        SUCCESS                Type: REG_BINARY, Length: 16, Data: DC 07 04 00 04 00 13 00 09 00 1F 00 27 00 A7 03

8:30:11.8556902 AM        spoolsv.exe        1284       RegCloseKey      HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Cluster\<Cluster GUID>\<Platform type>\Version-3\<Driver Name> SUCCESS             

如果复制问题是由于网络失败，而非节点的注册表信息不正确所引起，在Netmon中，可以看到节点尝试访问对应文件夹失败的网络包。

本文着重讨论实现这一需求的具体方法。

实现条件：

1. 该策略要求所有计算机运行Windows Vista/2008/7或以上操作系统。
2. 所有group均可访问的DC和其他公共服务器须与受控计算机位于不同IP地址范围内。
3. 统计所有group所属IP地址范围。

实现思路：

注：所有group均可访问的DC和其他公共服务器必须位于该地址范围之外。

1. 对该范围内所有计算机启用相同的IPsec策略。
2. 配置Windows防火墙incoming策略，对属于每个group的计算机，只允许接受来自相同group的incoming流量（请保持outgoing策略不变）。

配置步骤：

1.  实验环境

本文以一台DC和三台客户端为例进行阐述，其中4台计算机的情况如下图所示：

从上图可以看出，三台客户机位于同一网段192.168.0.X。其中，Client1W7属于Group1，Client2W7和Client3W7属于Group2。我们的目标是，使Group1和Group2中的计算机不能相互访问，同一Group中的计算机访问正常。如下表：

2.  实验步骤

(1)在DC上建立一条启用IPsec的组策略。

1. 运行gpmc.msc。打开组策略管理工具。
2. 在Group Policy Management中，右击域名，点击“Create a GPO in this domain, and link it here…”
3. 输入组策略名。
4. 右击新建立的组策略，点击”Edit”，打开编辑界面。依次展开”Computer Configuration”->”Policy”->”Windows Settings”->”Security Settings”->”Windows Firewall with Advanced Security”->”Windows Firewall with Advanced Security”->”Connection Security Rules”。在右侧空白处右击，点击“New Rule”新建一条规则。
5. 在“Rule Type”页面中选择“Custom”，点击“Next”。 在“Endpoints”页面中，选择“Which computers are in Endpoint 1”下的“These IP addresses”。点击“Add”。在出现的对话框中输入需要访问控制的网段。此处为192.168.0.201~192.168.0.210，该网段包含了实验环境中需受控制的三台客户机的IP地址。点击“OK”。
6. 选择“Which computers are in Endpoint 2”下的“These IP addresses”。点击“Add”。在出现的对话框中输入需要访问控制的网段。此处同为192.168.0.201~192.168.0.210，点击“OK”。
7. 在“Requirements”页面中，选择“Require authentication for inbound and outbound connections”。点击“Next”。
8. 点击“Next”。
9. 在“Requirements”页面中，选择“Require authentication for inbound and outbound connections”。点击“Next”。
10. 在“Authentication Method”页面中，选择“Computer(Kerberos V5)”。点击“Next”。
11. 点击“Next”。点击“Next”。
12. 在“Name”页面中，输入规则名。点“Finish”。

 (2)在DC上建立针对group1的组策略，该策略阻止所有incoming连接，仅允许同组的计算机访问。

1. 在Group Policy Management中，右击域名，点击“Create a GPO in this domain, and link it here…”，建立一条新的组策略。
2. 在新建立的组策略中，建立一条阻止所有incoming连接的防火墙规则。
1. 右击新建立的组策略，点击”Edit”，打开编辑界面。依次展开”Computer Configuration”->”Policy”->”Windows Settings”->”Security Settings”->”Windows Firewall with Advanced Security”->”Windows Firewall with Advanced Security”->”Inbound Rules”。在右侧空白处右击，点击“New Rule”新建一条规则。
2. 在“Rule Type”中，保持默认设置，点击“Next”。
3. 在“Program”中，选择“All programs”,点击“Next”。
4. 在“Action”中，选择“Block the connection”，点击“Next”。
5. 在“Profile”中，点击“Next”。
6. 在“Name”页面中，输入策略名，如“Block All”。点击“Finish”。
3. 在同一组策略中，建立一条允许来自group1的incoming连接的防火墙规则。
1. 在同一组策略中，依次展开”Computer Configuration”->”Policy”->”Windows Settings”->”Security Settings”->”Windows Firewall with Advanced Security”->”Windows Firewall with Advanced Security”->”Inbound Rules”。在右侧窗格中（已存在一条名为”Block All”的防火墙规则），点击“New Rule”新建一条规则。
2. 在“Rule Type”中，选择“Custom”，点击“Next”。
3. 在“Program”中，保持默认设置，点击“Next”。
4. 在“Protocol and Ports”中，保持默认设置，点击“Next”。
5. 在“Scope”中，保持默认设置，点击“Next”。
6. 在“Action”中，选择“Allow the connection if it is secure”。
7. 点击“Customize…”，选择”Allow the connection to use null encapsulation”，选择“Override block rules”，点击“OK”。
8. 在“Users” 中，保持默认设置，点击“Next”。
9. 在“Computers” 中，选择“Only allow connections from these computers”。点击“Add”，输入“group1”。点击“OK”。点击“Next”。
10. 在“Profile”中，保持默认设置，点击“Next”。
11. 在“Name”页面中，输入策略名。点击“Finish”。
4. 将新建策略部署到属于group1的计算机上。
1. 在组策略管理工具中，点击新建组策略，在右侧界面的“Security Filtering”中删除“Authenticated Users”。
2. 
3. 点击“Add”，添加组“Group1”。
4. 

(3)在DC上建立针对group2的组策略，该策略阻止所有incoming连接，仅允许同组的计算机访问。建立方法参照步骤(2)。注意在“Computers”页面 中，添加“group2”。部署策略时，“Security Filtering”中添加“group2”。

(4)等待在三台客户机得到组策略，或在cmd.exe中使用命令“gpupdate /force”立即使组策略生效。

至此，配置过程结束。

3.  实验结果

(1)在Client1W7上无法ping通Client2W7和Client3W7。以Client3W7为例，两端抓取netmon trace的结果如下图所示：

从上图可以看出，在发出ICMP包之前，Client1W7先通过AuthIP协议与Client3W7建立IPsec安全链接。连接建立起来后，Client1W7才向Client3W7发送ICMP包。由于这两天计算机位于不同Group，防火墙规则阻挡了这一通信行为的发生。Client1W7与Client2W7间的行为与之类似。

(2)在Client3W7上，可以ping通Client2W7。

两端抓取netmon trace的结果如下图所示：

从上图可以看出，在发出ICMP包之前，Client2W7先通过AuthIP协议与Client3W7建立IPsec安全链接。连接建立起来后，Client1W7才向Client3W7发送ICMP包。由于这两天计算机位于同一Group，防火墙规则允许了这一通信行为的发生。

(3)在三台计算机上，可以ping通DC。

由于在建立连接安全规则时，指定使用IPsec的IP范围内不包括DC，因而三台计算机与DC的通信之间不使用IPsec。以Client1W7为例。

从上图可以看出，当Client1W7尝试ping DC是，Client1W7直接向DC发送ICMP包，之前没有建立IPsec链接的过程。

参考资料：

如果读者有兴趣，可以参考以下文章，了解AuthIP协议：

AuthIP in Windows Vista

https://technet.microsoft.com/en-us/library/bb878097.aspx

我们先来仔细看一下此问题的现象。用nslookup查时，看到返回的IP为空：

E:\>nslookup  a.contoso.com

服务器:  localhost

Address:  127.0.0.1

非权威应答:

名称:    a.contoso.com

在DNS服务器上抓netmon，看到DNS Server（192.168.1.107）收到DNS客户端（192.168.1.105）请求后（第48帧），通过一系列根提示和CNAME替换（49～94）将a.contoso.com解析成b.contoso.com。第95～99帧，对b.contoso.com继续解析。但在没有解析出IP的情况下，第100帧直接回复客户端，IP为空。

48           3.0836047            192.168.1.105      192.168.1.107      DNS         DNS:QueryId = 0x3, QUERY (Standard query), Query  for a.contoso.com of type Host Addr on class Internet

49           3.0941067            192.168.1.107      some.dns.server  DNS         DNS:QueryId = 0xAE00, QUERY (Standard query), Query  for a.contoso.com of type Host Addr on class Internet

……此处省略了根提示和CNAME替换的过程………

95           4.2918082            192.168.1.107      some.dns.server  DNS         DNS:QueryId = 0xC98D, QUERY (Standard query), Query  for b.contoso.com of type Host Addr on class Internet

99           4.3035002            some.dns.server  192.168.1.107      DNS         DNS:QueryId = 0xC98D, QUERY (Standard query), Response - Success, Array[192.168.2.189]

100         4.3048338            192.168.1.107      192.168.1.105      DNS         DNS:QueryId = 0x3, QUERY (Standard query), Response - Success, , 

现在的关键是，到底第99帧收到了什么样的回复，致使DNS Server做出这样异常的行为。为此我们再看一下第99帧的细节：

- Dns: QueryId = 0xC98D, QUERY (Standard query), Response - Success, Array[192.168.2.189]

    QueryIdentifier: 51597 (0xC98D)

  + Flags:  Response, Opcode - QUERY (Standard query), AA, Rcode - Success

    QuestionCount: 1 (0x1)

    AnswerCount: 1 (0x1)

    NameServerCount: 1 (0x1)

    AdditionalCount: 2 (0x2)

  + QRecord: b.contoso.com of type Host Addr on class Internet

  + ARecord: b.contoso.com of type CNAME on class Internet: c.contoso.com

  + AuthorityRecord: b.contoso.com of type NS on class Internet: some.dns.server

  + AdditionalRecord: some.dns.server of type Host Addr on class Internet: 192.168.2.189

  + AdditionalRecord: Type: OPT, Sender's largest UDP payload size: 4096

我们看到，在第99帧中，首先将b.contoso.com 通过CNAME 解析成 c.contoso.com。然后是b.contoso.com的NS记录和对应的IP地址。

这里的关键是：b.contoso.com既是CNAME，又是NS记录。因为某种原因，08 R2不允许这种情况存在。最终的结果是缓存中的CNAME被替换成NS记录，解析无法继续，直接向客户端返回。而03则允许两者并存，所以没有这样的问题。

目前对应这个问题，已经有hotfix可以解决，即 KB2616776。打上此hotfix之后，该问题得到了完美解决。

说明：为保护隐私，文中的Netmon数据做了修改和省略处理，与实际情况可能有一定出入。此hotfix的链接：https://support.microsoft.com/kb/2616776

上期回顾

上一次我们主要介绍了Offline Files的几种主要的模式以及模式之间的切换等逻辑。

简介

本文讲主要介绍XP和Windows 7基本模式切换的细节以及针对冲突管理（Conflict Management）不同的机制和行为。

概述

从Offline到Online

举个例子，客户端将\\Server\aShare和\\Server\bShare 配置为Offline Available。由于某种网络断开，两个共享目录都处于Offline(Not Connected)状态。

由于状态自动切换机制，Offline Files检测到网络恢复尝试将两个共享目录切换为Online模式。

这一过程中， Offline Files检测Sample.docx文件在客户端有没有应用程序的Open handle（是否正在被使用），Offline Files将会做以下两种操作：

1. 1.       如果客户端正在使用Sample.docx但并没有做修改，那么Offline Files会将应用程序的open handle转到服务器上对应的那个文件上。
2. 2.       如果客户端正在使用Sample.docx且文件已被修改，那么Offline Files将不会对应用程序的open handle做任何修改且不会将该文件置为online。

这种情况下针对状态切换（OfflineàOnline），XP和Windows 7有不同的行为：

• ·         在XP中，一旦Offline Files检测到\\Server\aShare\sample.docx在客户端正在被使用且已被修改并且导致切换失败后，\\Server\aShare和\\Server\bShare均无法切换到Online状态。
• ·         在Windows 7中，一旦Offline Files检测到\\Server\aShare\sample.docx正在被使用且已被修改并且导致切换失败后，仅\\Server\aShare\sample.docx文件处于Offline (Need to sync)状态，\\Server\aShare目录下的其余文件已经整个\\Server\bShare都能正常的切换到Online状态。

这是因为在XP上Offline Files的影响范围是以共享服务器（或整个Distributed File System (DFS) namespace）为单位，而Windows 7上Offline Files的影响范围是以某个共享文件（或某个DFS scope）为单位的。

从Online到Offline

跟上面有一点不同的是，从Online切换到Offline的过程中，在XP中，如果某个文件由于网络问题无法访问，客户端上属于这台文件服务器的所有Offline Files全部会被置为Offline(Not Connected)状态。而在Windows 7中，如果某个文件由于网络问题无法访问，那么这个文件所在的共享文件目录会被置为Offline(Not Connected)状态，其余的共享目录不受影响。举个例子，

• ·         在XP中，如果用户由于网络错误的原因无法访问\\Server\aServer或者\\Server\aShare\Sample.docx，\\Server\aShare和\\Server\bShare都会被置为Offline
• ·         在Windows 7中，如果用户由于网络错误的原因无法访问\\Server\aServer或者\\Server\aShare\Sample.docx，只有\\Server\aShare会被置为Offline，\\Server\bShare不受影响。

Conflict

如果文件或文件夹在处于Offline的状态并且在Offline Files无法进行自动更新^[1]的情况下，用户对客户端和服务器端的同一个文件做了不同的修改。当状态恢复^[2]为可进行自动更新的状态^[3]时，自动更新过程中就会发生冲突，即Conflict。

注[1]：Offline且无法自动更新的状态，如，Offline(not connected), Offline(Working offline)

注[2]：自动恢复或手动恢复

注[3]：可进行自动更新的状态，如Online，Offline(Slow Link)

针对Conflict的处理，XP会有弹出窗口提示你需要选择怎么处理有冲突的文件：保留客户端版本，保留服务器端版本。

Windows 7上针对冲突管理更人性化。当用户从Offline切换到Online，Background Sync就会在后台立即被触发，当Offline Files服务检测到冲突时，并不会有立即弹出的对话框提示你操作，而是你可以通过访问控制面板的Sync Center查询更新结果再人工的管理冲突文件：保留客户端版本，保留服务器端版本或保留两个版本。

经验上讲，冲突管理简单而且易管理很少出现问题。

了解无线网络的 802.1X 身份验证

https://technet.microsoft.com/zh-cn/library/cc759077

实际应用中我们经常会碰到一些无法加域的设备，比如打印机，PDA，非Windows计算机等。如何把这些设备放到802.1x的环境中? 一般可以考虑通过MAC Bypass的方式。这种方式中，客户端可以用自己的MAC地址作为用户名和密码进行802.1x验证。

实现步骤如下：

1. 为相关设备创建账号：为了不影响AD中的账号和其他NPS policy，我们在NPS服务器本地创建MAC Bypass所需账号，将这些账号放到一个本地组MAC Bypass里。

NOTE： 帐户的密码设定要遵从接入设备的要求，比如Cisco就要求用户名和密码都是MAC地址。

例如：

Username: 001122334455

Password: 001122334455

2. 在NPS服务器上设置一些注册表项。根据以下文章的要求，我们需要配置注册表项“User Identity Attribute”；这是让NPS服务器支持MAC Bypass；

https://technet.microsoft.com/en-us/library/dd197535(v=ws.10).aspx

注册表路径:
HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

注册表项：User Identity Attribute

注册表值： 31 (dword:0000001f)

3. 在NPS服务器上创建MAC bypass所需的Network Policies：

Policy Name：Mac Bypass

Conditions: User group 中添加步骤1中创建的本地组MAC Bypass。

Constrains: Authentication
Methods 仅需选中 Unencrypted authentication (PAP, SPAP)

Settings: 如果需要将通过MAC Bypass方式接入的客户端放到特定VLAN中，可以配置下图中的3个属性。根据下图，客户端会被划入VLAN 4.

-         Tunnel-Medium-Type:802

-         Tunnel-Pvt-Group-ID: 你希望使用的VLAN ID, 本例中为4

-         Tunnel-Type: Virtual LANs (VLAN)

注：如需更换VLAN ID，仅需更改Tunnel-Pvt-Group-ID对应的数值。

至此Network Policies的部分已经完成。但是测试时我们会发现一个问题，NPS服务器会自动在用户名（MAC address）前加上Domain 名称。（例如MAC 地址为001122334455的用户账户会被自动识别为 domain\001122334455进行验证）由于我们刚才添加的用户是NPS服务器的本地用户而非域用户，最终导致验证失败。

4. 为了解决这个问题，我们需要特别配置Connection Request Policies；目的是当检测到用户名为MAC地址时，自动加上NPS服务器的计算机名（而非域名）。这样NPS会使用本地用户数据库进行验证。

- 首先我们可以复制或创建一条和默认Connection Request Policies相同的policy。

- 在新policy的属性中，在Settings tab下设置Attribute:User-Name;

Find: (^[0-9a-fA-F]{12}$)  注：这个正则表达式是匹配MAC地址的格式。大致意思是从用户账号的第一位开始匹配，检查每一位是否属于0-9, a-f, A-F的范围。成功匹配12次则认为是MAC地址的格式（MAC地址为12位所以需要匹配12次）。

Replace with: RadiusServerName\$1  注：这里需要将RadiusServerName替换成NPS服务器的计算机名

对于正则表达式的使用，微软的文章如下：https://technet.microsoft.com/en-us/library/cc737419(WS.10).aspx.

5. 为了避免步骤4的Connection Request (MAC Address Bypass) 和默认Connection Request Policies冲突，我们可以给默认Connection Request Policies加上一些特殊Condition条件：

我的做法是添加User Name条件，限定user name中必须包含domain名。如果有多个domain名，可以用”|”符号隔开。

这样就真正实现了用户名为MAC地址格式的请求使用NPS本地账号验证。用户名包含domain的请求使用AD账号验证。

以上是NPS服务器支持MAC Bypass的设置。实际上MAC Bypass还需要交换机/AP的支持。有些设备上这个功能叫mac bypass或者mac filtering. 这是因为这种认证发生在客户端无法提供用户名密码的情况下，接入设备通常不会再继续向后台的radius要求验证（因为没有用户名密码）。但是在启用了这个功能的情况下，接入设备如果支持mac authorization,则会继续用mac address作为验证的凭据。

比如 Cisco 的设备就支持这个功能

https://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008084f13b.shtml#backinfo

我们已经在多篇文章中谈过了页文件的问题 – 还有些东西记在脑子里面就是尽管你想要有足够的内存来防止过多的页面交换，这个目标不应该是尝试去完全阻止页面交换活动。一些页面错误行为是不可避免的 – 举个例子 当一个进程第一次初始化的时候。内存中修改过的虚拟页面最后不得不要更新回磁盘，因此就会有一定量的Page Writes /sec。然而，当没有安装足够的内存，你可能会看到两个特定的问题 – 太多页面错误，和磁盘争夺。

让我们从页面错误开始。页面错误被划分成两种类型，Soft fault 和 hard fault。一个页面错误在一个进程在内存中请求一个页面并且系统不能够在请求的位置找到这个页面的时候发生。如果这个请求的页面事实上在内存的其他地方，那么这是一个Soft fault。然而，如果页面不得不从磁盘上面去读取，那么一个Hard fault就发生了。大多数的系统可以毫无问题的处理软页面错误。然后，如果有大量的hard fault错误你可能会感到延迟。这个额外的磁盘I/O是由于持续的页面写入磁盘与尝试访问页文件存储在相同磁盘上面的数据的应用程序产生冲突所导致的。尽管在一个系统上面高的页面错误是一个非常直接的问题，他要求一些性能监视器中的额外数据收集和分析。当对一个怀疑的页面错误问题进行排错的时候，下面是一些重要的计数器：

记住自从操作系统不得不把修改过的页写回到磁盘，就将会有页写的操作的发生。然而，这个Page Reads /sec说明Hard Fault的数量是和内存不足的情况相当敏感的。随着有效内存值的减少，Hard Fault的数量将正常的增加。总的可以被系统支撑Pages /sec的数量是磁盘带宽的一个功能。这个意味着没有一个简单的数字来决定是否磁盘是饱和的。反而是你不得不去识别由于页面交换导致的整体磁盘流量有多少。

另外内存瓶颈的一个指示器是有效内存池耗尽了。当有效内存不足的时候，虚拟内存管理器对页面的整理被触发了。页面整理所做的是通过识别最近没有使用过的虚拟内存页来重新填装有效内存池。当页面整理是有效的，老的从进程工作集里面整理出来的页面立刻就不再需要了。整理过的页面被标记为转换并保留在内存中一段时间来减少页面写磁盘发生的次数。然而，如果有习惯性的内存不足，那么页面整理就不再那么有效果并且结果就是会有更多的页面写入磁盘。自从对于标记为转换的页面来说在内存里面只有很少的空间了，如果一个最近整理过的页面再次被引用的话它不得不从内存相反的磁盘里面来访问。瓶颈越来越严重，在同一块磁盘上面的应用程序直接I/O操作发生冲突的页文件被更新也越来越频繁。

在我们总结之前，让我们快速的讨论一下上面列出的在看Memory \ Available Bytes计数器的时候指导方针。通常如果有效内存一直超过安装内存的5%，那么你应该觉得还不错。然而，有一些应用程序可以管理自己的工作集 – IIS6、Exchange Server和 SQL Server。如果有足够的有效内存，这些应用程序和虚拟内存管理器交互来增加他们的工作集，并且当操作系统给出信号的时候整理他们的工作集。这些应用程序依赖于内存-所在的缓存缓冲区来减少到磁盘的I/O。因此作为结果就是内存将总是看起来是满的。

本文转译自AskPerf的博客文章, 原文链接如下：

https://blogs.technet.com/b/askperf/archive/2008/01/29/an-overview-of-troubleshooting-memory-issues-part-two.aspx