NAT溯源问题解析

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.)

你可能感兴趣的:(日志,休闲,溯源,LSN,cgn)