我们第一篇中介绍过，SSL VPN的特色及优势便是可以借助Web覆盖所有的远程访问需求，而现在这些非Web的应用使得原本基于Web的SSL VPN看似束手无策了。但事实并非如此，在本篇技术贴中，强叔就是要带着大家跨过山和大海，共同见证SSL VPN展示出的神奇力量——端口转发功能。
端口转发，一言以蔽之，就是端口转发客户端程序在远程用户侧获取用户的访问请求，再通过虚拟网关转发到内网相应的服务器。接下来以最常见的Telnet访问为例，介绍远程客户端通过SSL VPN访问内网的Telnet应用。
端口转发业务的配置如下，与前面介绍的SSL VPN其他功能一样，无论访问什么样的应用，首先都要在虚拟网关中添加相应的资源，对Telnet而言，只需要在虚拟网关中配置Telnet服务器的IP地址和端口即可。
远程用户在登录后的虚拟网关界面中，可以选择手动启用端口转发功能，也可以设置为登录后客户端自动启用，总之全凭虚拟网关一句话；除了可以自动启动端口转发功能，还可以选择是否保持端口转发长连接，这是由于有些应用的访问持续时间较长（例如管理员正操作Telnet过程中突然要离开一段时间），选中后可以防止因SSL连接超时断开而中断端口转发业务。
端口转发的数据处理流程相对复杂，强叔这里给出一张简图，后文将对各个阶段逐一介绍。
说明：这里的端口转发客户端包含了SSL VPN客户端功能，只是为了强调端口转发业务才特地如此称谓。
准备阶段
1. 登录SSL VPN
此过程在SSL VPN第一篇贴子《远程接入IPSec现短板，SSL VPN登上历史舞台》中已经介绍，不再赘述。
另外需要大家知悉，在上一篇贴子中强叔是围绕URL展开分析的，而端口转发的分析将有所不同，尽管也登录了虚拟网关，但因为是非Web类的应用访问，所以对应的资源访问也不再使用Web，而是借助其他应用程序，如Putty（Telnet/SSH工具）、Filezilla（FTP工具）、Foxmail（邮件程序）等。这时问题也随之而来了，非web应用程序是如何利用已经登录的SSL VPN连接的呢？
2. 顺风耳收到指令，进入聆听状态
使用非web应用程序进行数据访问时，看似与SSL VPN没什么关系，但实际上，端口转发的关键的技术点已在此恭候多时：用户使用Windows系统的IE浏览器登录虚拟网关后，会在本地PC的IE浏览器上自动运行端口转发客户端（ActiveX控件）。这个客户端的作用就是像顺风耳一样时刻“聆听”其他程序的所有请求，并在千钧一发之际将远程用户发给内网服务器的请求“拦截”下来，然后再通过SSL连接发送给虚拟网关。对于“聆听”到的请求，选择哪些请求进行拦截，这位顺风耳并不是一意孤行，是根据虚拟网关这位上级的指示来严格执行的。那么指令是什么呢？
前面配置的端口转发资源，实际上就是虚拟网关给端口转发客户端下发的指令——“有用户要访问这些资源，你协助他们完成访问任务”。在端口转发功能中，下发的指令便是目的主机IP地址+目的端口，以上信息可以唯一确定远程用户要访问的应用信息。
如下图所示，远程用户手动启用端口转发功能后，端口转发客户端会自动向虚拟网关请求资源信息，客户端请求到的资源信息会保存在远程用户PC的内存中，随时待命，便于在接下来选择“拦截”哪些请求。
为了不暴露内网服务器的地址，具体资源信息无法在端口转发客户端上进行查看，菜单中的资源也无法直接点击，只有简单的提示作用。不过我们可以间接通过查看端口转发客户端日志（存放路径为%appdata%\Roaming\svnclient\log），了解资源信息下发的过程。
Telnet连接建立阶段
3. 顺风耳精准拦截，施展代理绝活
在顺风耳的脑海中，已经明确要“拦截”哪些请求了，当下要做的就是竖起耳朵，聆听自己关心的内容。当用户使用Telnet程序对10.1.1.1的23端口请求连接时（一个TCP SYN报文），顺风耳发现与上级虚拟网关下发的资源信息（目的IP+目的端口）匹配，立即将此TCP SYN报文“拦截”。如果按照普通的人的做法这时就可以将请求报文发给虚拟网关交差了，但这里顺风耳考虑到如果不经过处理便发送给虚拟网关，即会导致每个Telnet请求（即每条TCP连接）都会对应建立一条新的SSL连接，这样做会不但会占用过多的系统资源，而且响应速度也会有延迟。为了节省虚拟网关的会话和内存资源，提高用户体验，顺风耳决定先乔装打扮成接收方，模拟接收一次Telnet业务请求（TCP连接），弄清楚用户需要访问什么样的资源，采用“集中代理的方式，一条SSL 连接搞定”的战术，减轻“上级”（虚拟网关）的压力。如何模拟接收Telnet业务？如何集中代理呢？顺风耳这个优秀的代理业务员自有妙计：
端口转发收到Telnet请求后对报文进行改造，将原来要发送给10.1.1.1的请求改为发送给自己（127.0.0.1），这样就等于自己代替Telnet服务器接受了请求。不过，模拟归模拟，模拟的同时必须记录改造前后的对应关系（本地换回记录表），便于后续可以代替Telnet服务器应答真正的用户（4.1.64.179）。
本地环回记录表
|
改造项目 |
改造前 |
改造后 |
|
源IP地址 |
4.1.64.179 |
127.0.0.1 |
|
源端口 |
随机 |
随机 |
|
目的IP地址 |
10.1.1.1 |
127.0.0.1 |
|
目的端口 |
23 |
1047（23+1024） |
端口转发客户端与自己建立了TCP连接1（也叫本地环回连接），使用netstat命令验证如下。
4. 构造私有报文头，提交“端口转发业务单”
模拟接收Telnet业务请求后，端口转发客户端对用户的请求已经了然于胸，按流程要求需要填写“端口转发业务单”提交上级领导。业务单中必须包括用户要请求的目的地址（10.1.1.1）和端口（23），以及命令字（建立连接、传输数据报文或关闭连接等），这样上级才能进一步处理。
此处需要注意：由于端口转发客户端自己模拟了接收方建立了TCP链接1，所以业务单中必须对该TCP链接做一个标记（TCP连接1的socket ID，称为客户端socket ID），只有这样当上级将业务受理结果返回时，端口转发客户端才能根据标记找到TCP连接1，将返回结果发给对应的Telnet客户端。
“端口转发业务单”在端口转发业务中被称为私有报文头（简称私有头）。这里仅以Telnet请求连接的报文为例，对私有报文头的主要字段进行说明。Telnet连接建立阶段报文载荷为空，所以传输时只有私有报文头，在数据传输阶段报文才会有载荷。
|
字段名称 |
字段说明 |
|
用户标识 |
标识用户身份，虚拟网关自动为用户分配。可以理解为端口转发业务单号。 |
|
命令字 |
1. Open-新建连接 2. Data-数据命令 3. Close-关闭连接 |
|
业务类型 |
1. 端口转发 2. Web-Link Web-Link实际上就是HTTP/HTTPS的端口转发业务，也就是说Web-Link资源，同样也可以配置为端口转发资源。但是请注意，在Web-Link资源中知名端口可以不指定，例如http://www.huawei.com/，但是在端口转发的配置中端口号是必选，例如HTTP的知名端口号80，HTTPS是443。 |
|
源IP 地址 |
原始请求中的源IP地址，本例中为远程用户客户端的地址：4.1.64.179 |
|
目的IP地址 |
原始请求中的目的IP地址，本例中为内网Telnet地址：10.1.1.1 |
|
协议类型 |
目前仅支持TCP协议。 |
|
目的端口 |
原始请求中的目的端口，本例中为内网Telnet端口：23 |
|
客户端socket ID |
远程用户与自己建立连接使用的socket ID，用于标识此次会话，后续的报文会继续使用这个socket ID。 |
|
服务器socket ID |
防火墙作为Telnet Client与内网服务器建立连接使用的socket ID，作用与客户端socket ID一样，均用来标识会话。 |
“端口转发业务单”整理完成后通过SSL连接加密发送给虚拟网关。
需要注意的是，此处建立的是一条专门用于端口转发业务的SSL连接，而非登录时已经建立好的SSL连接。当Telnet对其它资源发起访问时情况类似，建立新的TCP连接后，端口转发客户端也会再填写一份“端口转发业务单”，并共享这条SSL连接进行发送。这样，在客户端和虚拟网关之间会始终保持一条唯一的SSL连接。总之，所有的“端口转发业务单”都将送往这条SSL连接，经过加密后再发往虚拟网关，大大减轻了虚拟网关的工作量。
5. 虚拟网关与内网服务器建立连接
虚拟网关收到加密后的报文，对其进行解密，在“端口转发业务单”中获取到Telnet真实的目的IP地址和端口、命令字等信息，此时虚拟网关将作为Telnet客户端与内网服务器进行交互建立Telnet连接。通过查看防火墙的会话表，可以得出防火墙随机启用了端口10010向10.1.1.1:23发起访问请求，建立了TCP连接2。
6+7 内网服务器响应报文返回Telnet客户端
虚拟网关收到内网服务器的响应报文（登录界面），在发给远程客户之前，虚拟网关依然会构造私有报文头， 填写TCP连接2的socket ID（服务器socket ID），这样便可以与TCP连接1建立对应关系。最终，虚拟网关把经过SSL加密后的私有报文头+数据发送给端口转发客户端；端口转发客户端根据私有头中客户端socket ID找到TCP连接1，再根据本地环回记录表找到Telnet客户端真实IP地址，最终返回真实的数据。
端口转发客户端收到经SSL解密后的数据如下，从截图中标识的部分已经依稀看到登录页面的文字了，也就是Telnet数据报文，而上半部分的内容正是私有头的内容。
Telnet客户端收到的Telnet登录界面如下。
数据通信阶段
后续的Telnet数据报文，会继续使用之前建立的TCP连接1和TCP连接2，然后通过私有报文头将两个连接进行关联，最终打通“Telnet客户端—端口转发客户端—虚拟网关—Telnet服务器”之间的传输通道，实现数据通信。
Telnet应用的端口转发流程就介绍到这里， Telnet协议只是最简单的单通道协议，除此之外，端口转发还支持如下类型应用：
l 多通道协议，支持FTP和Oracle SQL NET。在实际的配置中，对于FTP协议只需要指定控制通道的端口21，协商后的数据端口会被自动“聆听”，无需额外配置。
l 多协议应用。对于有些应用，需要多个协议支持，例如Email，需要在配置端口转发业务前，弄清楚使用发送协议（SMTP:25）和接收协议（POP3:110或者IMAP:143）的端口号，并为每一种协议配置一条端口转发资源。
l 多IP固定端口应用。例如IBM Lotus Notes，对应的数据库存在于多个服务器上，但是对外提供服务时，均使用1352端口。这类应用在配置端口转发业务时，无需遍历配置所有服务器，只需要在“主机地址类型”中选择“任意IP地址”即可。
在实际应用中，端口转发的配置和使用都十分简单（SSL VPN的特色嘛），但殊不知神功练就的背后夹杂了多少泪水，也许在实际的使用中用不到这些生僻的内容，但是相信有那么一瞬间，强叔会助你灵光一现，发现更大的世界。那么接下来，将进入SSL VPN的最后一篇，与L2TP VPN十分类似的三层VPN功能，将SSL VPN的资源访问控制，延伸无界……