大家都知道的，Linux 操作系统在虚拟机软件里是很好安装的，但是在实体机上安装 Linux（任意发行版本）都是需要光驱（光盘）的，因为以前安装 Microsoft Windows * 系列系统都是采用 U 盘来做 USB Boot 来启动安装，由于需要 Linux 实体机来测试 Gnome 3.2 的新引擎（在 Windows 下 VMware * 均不可渲染）。

原本我将操作系统 Fedora 16 / Cent OS 6 / Red Hat Linux 都拷贝到 U 盘用 USB Boot 测试过，都能读到 U 盘，但是无法启动安装程序（Instsll 步骤），也尝试过几个 USB Boot 烧制工具，烧制了 USB Boot 之后，可以读取安装界面，但是到了网卡部分，都全部出错了，无法继续下一步。

求助各位大神，分享用 U 盘烧制 USB Boot 的经验，一边日后测试工作中能够顺利进行，谢谢大家！

今天是农历 2011 年的最后一天了，也是团年的日子，首先祝大家节日快乐，望大家在新的一年里，多多搞钱啊。

没意思，可以说毫无兴致。我对过年没兴趣，甚至反感，在我心里，已经很多年对过年都是平常心了，毫无意义。

我哥问我：这个年你准备怎么过？可以跟朋友一起过啦？你上海的朋友有不回去过年的没？

我回答道：打游戏，睡觉，上网，睡觉，找吃的，睡觉。都 2012 了，年味早已尽失，丝毫没有兴致，平常心。

经常都是各式各样的活动，各式各样的局，还可以了啦。

就像你看到的那样，看来我的日子过得还不算那么糟。

正如标题所述，小妹妹一只，不错吧。

俗话说得好，你只看图，从不说话。

事实一次又一次的证明了“天生丽质”这个词，涂抹多少粉黛都不敌自然美，看图就知道了。

下一个测试，我们将认证用户移动到 LDAP 服务器上。我们有非常简单的 LDAP schema，并且不会让任何产品陷入循环回路。然而，我们也碰到了不少的大大小小问题。Fortinet 和 SonicWall 在这项测试中都失败了。拿 SonicWall 来说，一个用户仅仅只能是一个组的成员，这对大部分 SSL VPN 的部署来说，是不切实际的。Fortinet 不能从 LDAP 中获得组信息，我们认为它根本就不能和 LDAP 服务器工作，直到技术支持建议在 GUI 中用IP地址代替域名，才解决了问题。

我们遇到的其它问题是在设置 LDAP 时，与 GUI 所相关的。在我们测试 Array 时，我们碰到了很多 GUI 的 bug 问题，所以不得不利用命令行界面来完成 LDAP 的设置。在 Caymas 上碰到的问题和 Array 相似：GUI 的 bug 问题使得我们被迫转换设置平台来完成目标。CheckPoint Connentra 的 LDAP 配置系统设计很差并且没有说明文档，这些缺点让我们的工作绕了很大的圈子。我们在 Juniper 和 Nokia 的设备中发现了一个非常不错的功能：他们可以利用 LDAP 信息作为访问控制决策的一部分（Nokia 也可以让你基于 RADIUS 服务器的信息作出访问控制决策）。例如，假如错误密码的尝试次数超过 10 次，你可以利用 LDAP 目录中的一个字段来限制访问。

尽管我们利用了错误/失败来衡量所有产品的得分，但是每款产品在如何处理 LDAP 的问题上，仍然有很大地不同。假如你计划大范围的部署 SSL VPN，在 LDAP 目录和 schema 方面上检查产品的互操作性对于你来说非常关键。Windows 的活动目录应用对于 SSL VPN 管理者来说引起了很大地麻烦。尽管利用 LDAP 来实现活动目录是非常容易理解的，从一个站点到另外一个站点 schema 的不同对于 SSL VPN 管理者来说是一个梦魇，SSL VPN 管理者也不是活动目录的专家。然而即使是活动目录专家也不可能对 LDAP 目录有很好的理解。

例如 Citrix 活动目录服务器和 LDAP 树结构是完全不同的。解决这个问题的方法是：通过微软，利用 Kerberos 进行认证。AEP，F5，Juniper，Nokia 和 SonicWall 可以直接和活动目录进行通信。这是解决问题的首选方法并且更容易实现。假如 SSL VPN 不能直接和活动目录进行通信，我们可以利用 LDAP 进行代替，但是这种方法会耗费网络管理者们的大量精力。我们最后一个测试是使用数字证书进行认证。尽管利用以 PKI 为基础的数字证书并不是非常流行认证方法，但是它和普通认证方法相比却可以提供很高的安全性。除此之外，因为微软的活动目录有内置的 PKI 选项，和以前相比，所有的 Windows 环境都可以方便的发布数字证书。

在这个测试项目中的大赢家是 F5，Juniper，Nokia 和 Nortel，所有这些产品都出色的完成了我们设定的目标。F5，Juniper 和 Nokia 允许你把证书和其它认证方法进行结合。AEP 和 SonicaWall 仅仅允许你把证书当作一个额外的机制来使用，例如利用数字证书、用户名和密码进行结合。仅仅 Caymas 甚至不允许你把数字证书工作当作一个认证机制来使用。在 Array 和 Fortinet 的设备不允许和我们自己的证书工作和得到证书撤销清单。难以使用的软件和不充足的文档消耗了我们的精力。

Aventail 也在这项测试中失败，不幸的是，因为它的产品不支持证书撤销清单检查，这对 PKI 部署来说是一项关键地要求，尽管这对于利用证书进行认证来说并没有什么问题。Check Point 在工作开始之前也花费了不少时间，直到他们的工程师支持团队告诉我们产品仅仅支持 1 至 2 种更新清单格式，工作才得以继续进行。数字证书尽管已经集成进了 SSL VPN 中，但还是有些问题存在。AEP，Array，Caymas，Check Point，F5 和 SonicWall 对于他们自己的数字证书并不能生成合适的证书签名请求。

SSL VPN 认证互操作性测试，在这个系列测试中，我们评估了每一家厂商的 SSL VPN 和几个常用认证方法配合使用情况，以此我们来确定客户端经由 SSL 链路进入网络的效果如何。在这里，你可以得到安全的假设，即大部分的产品支持 RADIUS，SecureID 和 LDAP 认证。

评测完毕！

著作版权：Super Me 转载需要联系

关于虚拟化方面，现在很多的 SSL VPN 设备可以扮作多个、独立的服务器。例如，你可以为自己雇员访问内部网准备一个 URL，为合作伙伴的外部网访问准备另外一个不同的 URL，这看起来像是不同的入口。Array、Aventail、Caymas、F5，Juniper 和 Nortel 都支持入口虚拟化。Array 和 Nortel，由于他们的提供服务经验，在 SSL VPN 测试中都有最好的虚拟化表现。F5、Juniper 和具有较少扩展性的 Caymas 和 Aventail，也提供了更多的面向企业的虚拟化支持，他们支持将一台设备虚拟成多个 SSL VPN 部署。

目前的 SSL VPN 部署支持越来越多的用户，而用户的数据信息很可能链接到外部的认证服务器上，例如 RADIUS 和 LDAP。在这个测试项目中，我们衡量了每款 SSL VPN 设备和我们的 5 个认证服务器的配合怎么样，并且评估厂商在方面的功能怎么样。 我们从 RADIUS 服务器测试开始。除了 SonicWall 之外，所有厂商都通过了基本的 RADIUS 测试。SonicWall 的 SSL-VPN 2000 的问题是：你在 SSL-VPN 2000 上不能控制 RADIUS 服务器查询服务所用的端口号。对此我们比较困惑。在上世纪的 90 年代，RADIUS 的开发者中有的人用的是自己设置的端口号，有的是用的标准的端口号。选择什么端口号并没有什么定论，在一些高端服务器中，它们会监听端口以追求最大的兼容性。SonicWall 的 SSL-VPN 2000 是惟一一款不让我们指定查询RADIUS服务器所用端口号的产品，因为此原因，SSL-VPN 2000不能和我们的测试所用服务器进行通信。

关于 RADIUS 测试的第二项是，确定设备可以从 RADIUS 服务器上获得组信息。因为在 SSL VPN 上的安全和访问控制策略通常是按组策略表示的。而不是按单独的用户。对于 RADIUS 来说，并没有一个标准的方法来从 RADIUS 服务器上获得组信息，但是却有一些产业所公认的方法。AEP，Fortinet 和 SonicWall 都在此项测试中失败，因为这些厂商都不允许你从 RADIUS 服务器中获得组信息。我们也从 Array 的 RADIUS 工具中发现了同样的问题，Array SPX-5000 拒绝相信我们的 RADIUS 服务器，并且持续不断地重复发送同一个用户认证请求。

第三个 RADIUS 测试是，指定 SSL VPN 设备认证到我们的RSA认证管理器上（也就是先前的 ACE 服务器），一个 RADIUS 服务器可以处理 RSA 的 SecurID 令牌环。你可以用私有协议或者 RADIUS 和 RAS 的服务器进行通信，但是大部分网络管理者选择使用 RADIUS。SecurID 服务器会发送回不同的特别消息到 SecurID 令牌环中。例如，SecurID 管理器会强迫用户变化 PIN 码，所以 SSL VPN 设备必须适当的处理这些消息。AEP 和 Array 直接和 SecurID 服务器进行通信，这就意味着他们的产品不能从服务器上获得组信息。Fortinet 和 SonicWall 完全失败了，因为两个产品不能适当地处理 SecurID，这就意味着用户不能可靠地登录到 SecurID 令牌环上。

接下文 ………………………

著作版权：Super Me 转载需要联系

关于用户自定义在 SSL VPN 产品中另外一个非常大的不同是支持终端用户的个性化和自定义设置。一些产品允许终端用户创造书签，重新整理图标和保存密码。同样依赖于你的部署，这些对于终端用户的满意度可以是不重要的，也可以是至关重要的。密码保存是一项非常好的功能，而这个功能可以有很多意味。对于在 SSL VPN 设备后的 Web 资源来说，可能会需要身份认证。一个 Web 服务器可能有单个的、静态用户名和密码在许多用户进行共享（例如内部网页面中的组），或者可能每个用户都有一个身份认证（例如 Webmail 服务器）。

管理这些用户名和密码是一台好的 SSL VPN 设备工作的一部分。当在远程位置时，假如用户敲入一个用户名和密码连接一个资源，SSL VPN 设备应该可以保存密码（假如系统管理者打开这个选项）以减轻用户不断输入用户名和密码的重复工作。当资源使用的是同一个注册信任时，一个“单点注册”能力就应该能够自动给用户注册，而不用两次敲进同一个用户名和密码。Juniper 的 SA-6000 在这个测试项目中无疑又保持了领先，提供了最好的选项设置，用户可以选择使密码缓存跨越进程。密码可以被静态的锁住某些资源，并且单点注册也是被支持的。Nokia 和 Nortel 支持这些选项其中的两个，我们测试的其他设备在这方面的能力很弱。Nortel 仅仅支持通过 LDAP 服务器存储用户名密码，因为它不能本地存储密码。

当然密码不能作为用户自定义的惟一话题。书签的顺序和外形都是应该可以由用户进行管理，AEP，Array，Aventail 和 Caymas 都不能给与终端用户任何的选项。我们测试的其他厂商都提供了一些或者所有选项。Fortinet 的入口设置是独一无二的，不像我们测试的其他 SSL VPN 设备，它并没有预先注入连接资源。用户会被要求注册登陆和自己新建到某些资源上的书签和图标，而这些资源是被 SSL VPN 所保护的。不幸的是，在我们测试的版本中，一个 BUG 阻止了定义书签的能力，严重的限制了入口功能。Fortinet 还有另外的奇怪特性值得一提：它们的 SSL VPN 入口不能在 443 端口上运行。SSL VPN 是在 443 端口上运行的，我们非常不能理解为什么 Fortinet 的设计者们会做出如此决定。

接下文 ………………………

著作版权：Super Me 转载需要联系