NAT在企业网乃至家庭用户已经应用很多年，防火墙和路由器通常是兼做NAT的主要设备。随着IPv4地址耗尽，运营商在完全过渡到IPv6之前不得不开始使用NAT设备，随之而来的是更加标准化的适用于运营商的大规模NAT规范和标准，即LSN（Large Scale NAT）或CGN（Carrier Grade NAT)。专业的LSN设备也应运而生，不再是使用防火墙或者路由器兼差。 但在运营商开始考虑使用NAT时，溯源成为一个棘手的问题。在企业网中，通常没有必要进行溯源。溯源典型的应用就是指当某个机构或者网站提供某个合法源IP地址在某一时刻访问或发布了特定内容，需要查明这个IP当时是在什么地方或者哪台电脑在使用。如果没有经过NAT设备，该合法IP在互联网上是唯一的，运营商可以根据宽带接入认证等技术确定该IP的使用者。使用NAT设备后，由于大量内部用户使用私有IP共用同一个合法IP，溯源要求NAT设备必须把某一时刻NAT地址池中特定合法IP的特定端口是哪个用户在使用的信息发送给日志服务器，由日志服务器保存一定时间，供相关部门查询。下面就NAT流量日志类型进行讨论。中间涉及到LSN的一些NAT行为规范，不做具体阐述。

  1. 基于会话的日志

    这是目前绝大部分NAT设备采用的日志方式。在传统NAT（Symmetric NAT)中，任意一个新建TCP连接或者UDP会话都会使用某个NAT地址的一个特定唯一的端口，NAT设备中的会话表包含每个会话的以下信息：内部IP：内部端口，NAT IP：NAT端口，目的IP：目的端口。为了精确记录某个NAT端口的使用情况，每个会话需要在其创建和关闭时均发送日志，这意味着每个会话需要2条日志。这种日志方式在小型企业使用尚可，在运营商使用是不可思议的，这也是目前已经在小流量使用NAT设备的运营商碰到的问题。问题包括：

    • NAT设备发送日志能力。运营商NAT设备的新建连接速率可能在每秒数十万乃至数百万，尤其是遇到DDoS***时。发送日志的能力理论上要达到连接速率的2倍。事实上，传统NAT设备发送每秒上万条的日志就经常有日志丢失的情况。
    • 日志服务器处理能力和存储容量。按照一条日志150字节计算，一个家庭用户平均每天33000个连接计算，日志数量是连接数量的2备，按照相关规定需要保存3个月的日志信息，一个用户3个月的日志存储需要900M空间。一个100万用户的运营商需要900T的存储用于日志存储。而相应的日志服务器数量也需要大量增加。
    • 日志丢失问题。由于日志各个环节需要处理大量日志，流量突发超过日志处理能力会导致日志丢失，导致溯源系统无法查到需要的信息。

    基于上述原因，在运营商大规模NAT部署中，基于会话的日志是不现实的，这也正是LSN设备要解决的问题。

  2. 基于端口映射的日志

    这种日志类型和LSN中的NAT行为相关，在传统NAT中，即使同一个内部IP使用同一个源端口向不同目的发起连接，NAT设备也会分配多个NAT端口，这也是典型的P2P应用的连接方式。而在LSN中，定义了EIM（Endpoint Independent Mapping，对端无关映射)的NAT行为，同一个内部IP的同一个源端口无论对外发起多少连接，只要目标IP：目标端口不同，都会被映射为同一个NAT IP的同一个NAT端口，而且这个NAT端口不会同时分配给两个或以上内部IP。因此，支持EIM的NAT设备，只需要发送包含“内部IP：内部端口，NAT IP：NAT端口”的映射日志即可。例如，迅雷下载持续下载一天（P2P应用通常使用相同源端口发起多个连接），先后与10000个对端建立连接，如果用不支持EIM的NAT设备，只能采用基于会话的日志，需要20000条日志。如果采用基于端口映射的日志，只需要2条即可，一条是第一个连接时发送的，另外一条是该映射所有连接关闭后发送的。由此可见，EIM配合基于端口映射的日志可以大大减小日志数量。

    这种日志类型的局限在于只对P2P类似的应用减小了日志数量，对于客户端不同连接使用不同源端口的应用如WEB访问等帮助不大。

  3. 基于NAT端口块的日志

    这种日志类型同样也涉及到NAT设备的NAT功能本身。为了减小日志量，全球运营商和LSN设备厂商相继提出类似技术草案，其根本在于当用户发起第一个连接时，一次性为该用户分配包含多个NAT端口的端口块并发送日志，在该用户关闭所有连接前，只要所分配的所有端口未使用完毕，不需要发送日志。当端口块使用完毕时，可以分配更多端口块。这种方式适用于所有应用，可以将每个用户的日志量降到1台普通服务器无需额外存储即可承担。

  4. 基于用户的日志

    这种方式其实是基于NAT端口块的日志的一种极端情况。定义足够大的NAT端口块，使每个内部IP只能分配一个NAT端口块。这样日志只需要记录某个内部IP什么时间开始使用某个NAT端口块，什么时间全部连接关闭或超时。这种方式下，对于超过端口块的连接，可以考虑丢弃该连接直到有空余端口，或者在NAT池中每个IP都保留一部分端口作为动态使用，这部分超额动态使用的会话需要基于端口映射的日志。

  5. 零日志

上述两种方式分配端口块是动态的，因此需要发送日志。为了进一步减少日志，静态映射端口块的功能被越来越多厂商支持。这种方式要求LSN设备按照一定算法为内部所有私有IP分配固定的一段NAT端口块。网管系统或者日志服务器无需流量日志，只需要根据该算法即可推算私有IP与NAT 端口块的映射关系。不必再担心发送日志时由于网络或其他原因丢失日志。这种方式的弊端是NAT地址利用率低，不上线的用户对应的NAT端口也不可以被其他用户使用，对于IP地址资源不足的小型互联网接入服务商不是很适用。对于原来在使用合法IP的大型运营商，1个合法IP静态映射为20个私有IP已经完全可以解决其地址匮乏的问题。静态映射和零日志对这些大型运营商非常适合。

不管上述哪种日志方式，有一个问题无法解决，就是基于NAT IP无法唯一确定用户，因为NAT本身一定是多个私有IP在共用一个合法IP。如果只提供IP地址，只能追溯到当时在使用这个IP地址的若干个内部用户。如需唯一确定内部IP，必须提供NAT IP地址及端口号。相信随着大型运营商开始采用NAT，相关部门及各个网站在需要溯源时会记录并提供端口号信息。

本文主要就日志进行了讨论，单从日志一个方面就可以看到运营商级别的NAT远非传统NAT那么简单。其中涉及到但未具体阐述的NAT规范本身更决定了运营商级的NAT一定需要是专门的LSN设备，远非将NAT作为次要辅助功能的传统防火墙或路由器所能胜任的。

（R.S.)