ICA Proxy数据访问流程

42ew222

在Citrix的解决方案当中，都采用Citrix的NetScaler设备进行ICAProxy，将虚拟桌面和虚拟应用发布到外网。接下来详细说明ICA Proxy的访问数据流程。

如上图所示，其表示的步骤详细说明如下：

• 客户端通过HTTP GET请求发送访问的FQDN 地址到NetScaler的VPN虚拟服务器。
  
• NetScaler的VPN虚拟服务器经过检测确定传入的连接类型是未认证的客户端HTTP请求，然后将该客户端的HTTP请求重定向到认证页面（状态HTTP 302；其认证页面为：/vpn/index.html）。所以当我们在输入URL返回的时候，我们会获取到一个FQDN/vpn/index.html的认证页面。
  
• 这个时候我们在客户端输入用户登陆凭据，并将其发送给NetScaler的VPN虚拟服务器（HTTP Post/cgi/login）。
  
• NetScaler的VPN虚拟服务器会将凭据发送到后端指定的身份验证服务器进行验证。如果存在二次身份验证（如RADIUS认证），那么VPN服务器就需要进行二次身份验证。该验证通过发起对RADIUS认证服务器的认证请求并要求服务器响应。
  l  该VPN虚拟服务器与用于向二次认证服务器请求响应（即一次性响应密码）（HTTP200）。
  l  同时客户端也会发送质询响应到VPN虚拟服务器（HTTP POST/ CGI/ dlge）。
  
• VPN虚拟服务器设置身份验证Cookie并将客户重定向到基于从客户端(HTTP 302; 位置: /cgi/setclient?cvpn)的HTTP标头的UserAgent（这是HTTP的标头，在使用HTTP协议进行请求时，HTTP协议头部会添加User-Agent，该信息可以标识请求者的一些信息，如什么浏览器类型和版本、操作系统，使用语言等信息。）一个“客户端设置”页面。
  
  
• 客户端发送包括身份验证Cookie请求(HTTP GET /cgi/setclient?cvpn).。
  
• VPN虚拟服务器确定传入连接的类型来进行身份验证并将HTTP客户端重定向到/vpns/cvpnpage.html (HTTP 302)页面。
  
• 客户端发送包括身份验证Cookie请求(HTTP GET /vpns/cvpnpage.html)。
  
• VPN服务器通过客户端VPN页面再度重定向到StoreFront（SF）或Web Interface（WI）的页面：/cvpn/https/storefront.internal.com/Citrix/StoreWeb (HTTP 302)。
  
  
• 客户端发送包括身份验证Cookie请求(HTTP GET /cvpn/https/storefront.internal.com/Citrix/StoreWeb)。
  
• 在SF/ WI服务器的单点登录（SSO）服务回调到VPN服务器(HTTPPOST /CitrixAuthService/AuthService.asmx; <GetAccessInformation [...]>)。
  
• VPN服务器响应SF/ WI的认证信息，其中包括Smart Access的信息(HTTP 200; <GetAccessInformationResult>)。
  
• 在SF/ WI服务器枚举用户的应用程序，并将它们通过VPN客户端呈现给前端的用户界面客户端(HTTP 200)。
  
  
• 用户启动（点击）的应用程序(HTTP GET)。
  l  Store Front：/cvpn/https/storefront.internal.com/Citrix/StoreWeb/Resources/LaunchIca/[...]
  l  Web Interface：/cvpn/https/webinterface.internal.com/Citrix/XenApp/site/launcher.aspx[...]
  
• 在SF/ WI服务器构造并发送ICA文件(HTTP 200)。
  l  Address（地址）：包含STA信息(;STA_VERSION;STA_SERVER_ID;STA_TICKET,见下文或着访问我之前的文章，在ICA协议里面有对STA这一字符串的说明)。
  l  SSLProxyHost（代理主机）：包含网关的FQDN和TCP端口号。
  
  
• Citrix Receiver启动ICA文件并发送SOCKS v5连接到服务器。
  l  address type（地址类型）：域名。
  l  destination address（目的地址）：STA票据。
  
• NetScaler的VPN虚拟服务器确定传入连接的类型是SOCKS v5，并处理代理连接。
  l  上述的NetScaler检查是基于字节序列签名或着特征来确定连接（协议）的类型的。
  l  如果被检查的字节匹配一个协议签名，则该处理程序被调用。
  l  这些处理包括HTTP，SOCKSv5，CGP。
  l  当前的实现假设SOCKSv5和CGP连接来自ICA客户端。
  
• NetScaler的执行通过发送STA票据到STA服务器并请求相应的数据(<RequestData>)。
  
• STA服务器将原始数据转发到网关，即VPN虚拟服务器。(其中值包含<Valuename="CGPAddress"> and <Value name="ICAAddress">)。
  
• 这个数据是用来完成后续通过SOCKSv5代理一系列的接收和请求的。
  
  STA票编码格式
  
  比如 ;STA_VERSION;STA_ID;TICKET
  STA_VERSION：数字字段识别STA的版本。
  10--STA1.0和1.1版；
  20-- STA2.0版
  22 --STA2.2版
  40 --STA4.0版（用于会话可靠性）
  
• STA_SERVER_ID：0序列 -16个字符代表服务器名称的哈希值。
  当多个STA由单个网关服务器共享，每个STA ID必须是唯一的。这允许网关来定位创建票证STA和返回到STA门票验证。 （即STA01创建的票据将无法在STA02存在。）
  
• TICKET：一个随机产生的序列32（大写）字母数字字符。