解剖NetScreen (4)

本文档的Copyleft归yfydz所有，使用GPL发布，可以自由拷贝，转载，转载时请保持文档的完整性，严禁用于任何商业用途。
msn: yfydz_no1@hotmail.com
来源：http://yfydz.cublog.cn

0. 声明
本文仅仅是从技术角度分析如何实现NetScreen防火墙，即如果要把本人的一台Linux机器变成NetScreen防火墙估计要作那些工作，所有观点均为个人观点，不代表任何组织或团体，只谈技术，不带任何吹捧、攻击或贬低，欢迎大家一起讨论，有错误请指正，但对文章中如有不明白的名词和概念请问google而不要问我。

1. 参考资料:
http://www.juniper.net/techpubs/software/screenos/screenos5.1.0/translated/
CE_v5_SC.pdf 第5卷：VPN

2. 前言

VPN现在也成了防火墙功能的一个重要组成部分，最常用的VPN协议是IPSec，其次还有PPTP、L2TP，至于SSL VPN一般是作为单独设备出现，不作为防火墙；而MPLS一般只是电信设备里用。

NS支持的是IPSec和L2TP，没提PPTP。NS以前不作SSL VPN，收购了一个作SSL VPN的公司后也有SSL VPN的专门产品。

3. 协议概述

3.1 IPSec

IPSec是一个标准协议族，最新基本框架标准在RFC4301-4309中定义，原来老标准体系(RFC2410-2412)中的主要部分：RFC2401，2402， 2404， 2406， 2407， 2408， 2409已经被废除了，只有RFC2403，2405， 2410， 2411， 2412还有效，此外还有其他相关的各种RFC和draft，一个比较完整的VPN标准列表可见：http://www.vpnc.org/vpn-standards.html

(感叹一声：计算机的东西变化就是快，一个东西都还没上手就已经作废了，想想还要搞一辈子真是苦啊,555)

IPSec使用的协议为AH（51）或ESP（50），模式为通道模式或传输模式，密钥可以是手工配置，也可以是自动密钥交换，目前实现使用 IKE协议（RFC2409），以后就是IKEv2了（RFC4306），这种情况下通信双方需要共享一些信息，该信息可能是共享的数据串，也可能是公开密钥算法中对方的公钥或证书。

IKE分两个阶段，第一阶段有两种协商模式，main mode和aggressive mode，第一阶段主要是身份认证和协商加密和认证算法，协商的前两步是明文，后面就是加密的了，NAT-T，XAUTH等在此阶段使用；第2阶段只有一种模式，quick mode，协商信息都是都是加密的，协商通信的SA，确定通信加密密钥(对称加密密钥)，PFS在此阶段使用。

IPSec中涉及几乎所有PKI相关技术，关于PKI可参考PKCS系列，关于X.509证书可以参考RFC2459，证书管理协议参考RFC4210，不过国内PKI建设还是比较差，真正用证书的IPSec不多。

IPSec本身还有很多相关技术，如：为提高安全性的完美向前加密PFS；为支持NAT环境的NAT-T；检测对方失效的DPD；提供用户级认证的XAUTH；通过IPSec通道传输多播/广播信息等。

IPSec的实现分两类，一种是网关，为内部网络的通信进行保护，一般称为VPN网关；一种是主机，为本机的通信进行保护，一般称为VPN客户端。在RFC中规定，网关必须实现通道模式，而传输模式是可选的，而主机必须同时支持通道和传输模式。

IPSec实际应用环境分为静态网关到静态网关；静态网关到动态网关；静态网关到静态客户端；静态网关到动态客户端；动态网关到动态网关；动态网关到动态客户端等多种类型，后两种的实现需要第3方设备的支持，如VPN管理中心，DDNS等。

IPSec设备使用模式可分为路由模式或透明模式，还要支持一些特殊网络拓扑环境，如星型VPN、同网段VPN通道等。

IPSec的高可用性分两类，一是通道热备，通过VPN网关冗余实现，要能实现通道状态备份；二是通道均衡，VPN流量自动均衡，自动识别失效通道。VPN的高可用性属于难度很大的功能。

所以说，目前要实现某一情况的IPSec现在不算很难，因为现在open source的IPSec实现已经不少，但能完全实现上述所有情况的还是比较困难的。

在Linux下，IPSec最有名的实现是freeswan，并有很多相关补丁，可以实现绝大多数IPSec需求，但关于高可靠性方面是个空白。在国内使用的话，一般还会要求支持国产加密算法。在Linux2.6中，已经自带了IPSec的实现(native IPSec)，不过在内核中它和freeswan只能二选一，不能同时使用。

freeswan提供的IPSec是基于路由的，不支持基于策略的VPN；使用native IPSec和netfilter配合，也许能实现基于策略的VPN。

3.2 L2TP

L2TP标准在RFC2661中定义，目前大部分实现都是基于此RFC，而最新的L2TPv3则在RFC3931中定义。其实l2TP只是提供一种封装方法，并没有加密认证过程，所以真正要保证安全一般是和IPSec结合，在RFC3193中定义了如何用IPSec封装L2TP。

Linux下有l2tpd的L2TP实现，将L2TP包封装在UDP1701端口数据中，防火墙作为服务器监听UDP1701端口。

L2TP/PPTP的应用环境相对简单，一般就是VPN设备作为服务器，然后由远程的客户端来连接，在Windows中自带了PPTP/L2TP客户端，比IPSec要容易实施，所以在某些不需要网关互连的环境下用PPTP/L2TP比IPSec要方便。

3.3 需求小结

除了具体的各种功能需求外，其实有个最常用的需求也是最难实现的需求，是要求VPN通道在任何情况下如果不是手工断开的话，都能一直保持稳定不断，不需要任何人工参与，这是一个实现起来非常难的需求，要求VPN设备能具备很强的鲁棒性，而open source的代码大都没有如此鲁棒，需要自己增加不少处理措施。

老实说，我对IPSec通信的可靠性还是有一点怀疑，AH、ESP包中只有序列号而没有确认号，NAT-T只是包装在UDP包而不是TCP包，因此没有重传机制，如果使用CBC模式的加密算法，只要一个包丢失后续的包就无法解析了，因此VPN通道可能需要经常重新建立。不过在目前实际应用看，好象通道自动重建不是很多，看来是现在的网络可靠性还是比较高，丢包的概率很小了。

4. NetScreen的IPSec

NetScreen的加密认证算法使用硬件实现，所以速度上比软件实现的要快很多。

4.1 证书

NS使用两种密钥创建机制创建VPN通道:手动密钥和具有预先共享密钥或证书的“自动密钥IKE”。

NS支持证书、PKCS#7、可通过LDAP或HTTP在线检索CRL。

NS证书处理过程是先在设备上生成证书请求，下载后发送给CA进行签发，将CA签发的证书再上载回设备，同时也需要上载CA的公钥证书和 CRL，也可以使用SCEP自动获取证书和自动更新证书，使用OCSP协议来检查证书状态。SCEP和OCSP是freeswan所不支持的。NS也可以自签证书，说明其内部也建了个CA，openssl可用来建CA。

4.2 加密选项

NS提供的加密选项很多，基本上在IPSec处理时只要有不同选择时都提供有选项，给用户的自由度比较大，但对用户的要求也就比较高了，不过一般情况下就用缺省配置就可以了。国内产品一般没提供那么多的选项配置，NS可配置的包括：

ESP/AH；通道模式/传输模式；自动IKE/手工密钥；main/aggressive； 证书/共享密钥；RSA/DSA；密钥长度512/768/1024/2048；DH组：1/2/5；加密算法：AES/DES/3DES；认证算法：MD5/SHA1；IKE ID：IP/U-FQDN/FQDN/ASN1-DN；PFS：Y/N；replay检测：Y/N；

4.2 基于路由和基于策略的通道

NS提供了基于路由和基于策略的VPN通道，由于IPSec是第三层实现的，SA定义中也没有上层协议的信息，所以基于路由应该是最自然和合理的，基于策略只是由于需求的提高而增加的，所以需要增加新的处理措施，所以一般基于策略的VPN应该是更消耗资源一些。

freeswan是只支持基于路由的VPN，如何在此基础上实现基于策略的VPN还没想清楚，或许由策略路由来辅助可能有帮助。

基于策略的VPN是在配置策略动作时指定为加密处理，CheckPoint也是这样作的；基于路由的VPN一般是先要配置VPN通道信息,NS还支持在VPN通道接口上使用动态路由协议，这样在大型网络中比较灵活。

个人感觉基于路由和基于策略的区别是在于通道的建立时机，基于路由的IPSec是事先建立的，以后两点间的通信就全走通道了；而基于策略的IPSec是动态的，有点象拨号中的“dial on demond”，在有数据需求是才去建立通道，数据通信完就结束。

4.3 站点到站点的VPN（网关到网关）

freeswan的VPN通道接口“ipsec*”是VPN配置文件中绑定到固定网卡上的，使用和该网卡相同的地址，VPN通道建立后，自动建立到达对方的路由，不需要另外配置。而NS的VPN通道接口可以自己单独定义，可以配也可以不配地址，VPN通道路由需要自己添加。

对于动态地址，NS使用FQDN来定义对方，建立通道前通过DNS解析获取对方实际地址，这点freeswan也可以作。不过这要求设备支持DDNS，在获取IP地址后自动通知DNS服务器自己的IP。

对于重叠地址的VPN通道连接，普通情况建立的VPN通道是无效的，因为当访问对方的IP时会认为是访问本地，这时需要对两边地址进行转换，数据在进入VPN通道前就要转换地址。不过NS支持得有限，只支持部分地址的点转换，好象不能实现网络对网络的全面转换。这种地址转换本身不属于 IPSec，只是IPSec的一个预处理过程，netfilter本身不支持这样的转换模式，但可以简单修改后支持，修改量不大，而且最终可以实现网络对网络的一对一转换，也就是可以访问对方网络内的任意一台机器，而不是有限的服务器。

透明模式VPN，是指防火墙运行在透明模式下，但防火墙上配地址，用该地址建立VPN通道保护防火墙内部到外部的通信。freeswan是可以支持的，使用前先启动桥，将ipsec网卡绑定到桥网卡就可以了。

4.4 拨号VPN

拨号VPN的特点就是启动VPN时还不知道对方地址，服务器端是处在监听状态等待对方来连接。在freeswan中称之为Road Warrior，配置时除了对方地址等为ANY外其他参数基本和网关到网关的类似。一般这种情况下会应用XAUTH来认证对方。NS是通过证书中的ID或共享密钥来识别对方，也可以启用XAUTH。从NS的配置实例看，NS可以通过对方子网来区分对方，这点在freeswan中作不到。

对于多个拨号对端，NS提供组IKE ID、共享IKE ID来通配对方。

freeswan是通过地址匹配来找连接信息的，所以只能配一个匹配任意IP地址的连接，匹配了第一条连接后就不会再去找第二条连接的信息。

4.5 高级VPN功能

NS支持NAT-T、VPN通道的监控、每个通道接口多个通道、冗余VPN网关、背对背VPN、星型VPN等。前3个freeswan都可以支持，在某些特定配置下也可以支持星型VPN。

不过不太理解背对背和星型有什么实际区别，NS中背对背用在不同区段，需要查找策略；星型用在同一区段，不需要查找策略，可本质上有什么区别呢？不都是从一个通道进来，VPN设备解密，再从另一个通道里发出去的过程么？查不查策略和IPSec本身有什么关系？

freeswan本身不支持冗余处理，需要自己定义相关的处理，因为这种多网关协商取最高优先权的处理模式不是RFC定义的，需要自己定义。不过NS也不能实现网关间的全部数据连接状态的冗余备份，切换后连接会重置，但可以以状态检测失效为代价来使连接不重置。

5. NetScreen的L2TP

NS的L2TP支持使用IPSec进行加密，而且只能使用传输模式，NS的L2TP本身的功能基本上Linux下的l2tpd都能提供，很容易实验通；不过和IPSec结合比较麻烦，没试成功过。不过以其那么麻烦地用L2TP+IPSec，还不如用PPTP，Linux下有完整的PPTP实现和相关MS-MPPE的补丁，可以提供128位的加密保护。

6. 小结

NS的VPN功能的确算比较完整的，尤其是IPSec部分，不过影响其在国内应用的不是技术而是法律因素，很多情况是禁止使用国外的VPN产品的。

国内的VPN厂家不算少，可大部分还是基于freeswan修改的，而且是靠软件实现加密和认证，国密办允许的加密卡速度都比较慢，好象都没有超过百兆的，还不如AES的软件加密来得快，硬件加速卡国内基本没有产的，都是美国或台湾产的，感觉国内还是比较落后。

对于常用的公开的加密算法如AES、3DES等，目前还没有公开的破解，但没人保证美国NSA已经能够破解，所以真正国内只允许使用国密办允许的加密算法，都是硬件化的，靠通过算法保密来提高可靠性，使用软加密的都是打擦边球；对于HASH算法，由于王小云教授的横空出世，MD5和SHA1相继被破解，感觉一下没有合适的HASH算法可用了，提出新的可靠HASH算法是密码界的最紧迫的任务了。