大家都知道的，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 的经验，一边日后测试工作中能够顺利进行，谢谢大家！
文：Super Me（2006）编：打死算了（2011 末）
下一个测试，我们将认证用户移动到 LDAP 服务器上。我们有非常简单的 LDAP schema，并且不会让任何产品陷入循环回路。然而，我们也碰到了不少的大大小小问题。Fortinet 和 SonicWall 在这项测试中都失败了。
文：Super Me（2006）编：打死算了（2011 末）
关于虚拟化方面，现在很多的 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（2006）编：打死算了（2011 末）
关于用户自定义在 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（2006）编：打死算了（2011 末）
在入口控制级别方面，相比其他厂商的产品来说 F5，Juniper 和 Nokia 之所以表现不同，是因为他们各自的管理界面。假如入口自定义对于你的部署来说不是那么重要，你就不必关注这三家产品的优势了。在每个 SSL VPN 设备中，资源（例如是 Web 页面）和入口链接的意义有些不同。资源被定义为一系列的主机和 URL 路径，同时也可能包含许多不同的 Web 服务器，以上所有这些工作在一起保证了终端用户对于 Web 应用的安全访问。
入口链接的意义可以简单地被理解为：用户接触到 Web 应用的最后底线。假如一个链接被定义了，那么它对于被允许访问的用户是可以显示的。资源链接和入口链接的分离对于 SSL VPN 设备来说非常必要。例如，Juniper 的管理界面长期以来是一个非常大的弱点，因为它不认为一个资源是一个原子性的对象，这就意味着管理任何 Web 应用的访问控制和入口呈现也许要求额外的定义和许多的手工控制。
Juniper 对于链接资源和入口的控制方法和 Aventail 和 Nokia 非常相似：对于入口来说，当一个资源被管理时，一个复选框会被加到链接的旁边。 其他的厂商，例如 AEP，Caymas，Check Point 和 F5，他们将入口和资源定义连接的非常紧密。Array 和 Nortel 的处理手法非常危险，入口和访问控制是完全分离的。对于很多静态 SSL VPN 的部署来说，根本就没有什么不同点，但是假如你计划要频繁地更换 SSL VPN，你就不要定义每个事物两次（在 Array 例子中，我们意识到入口和资源定义是大小写敏感的）。
接下文 ………………………
提示：点击文章标题阅读全文和发表您的反驳评论 …… ……
