基于Cookie的Radware配置,解决动态IP访问网站问题.docVIP

基于Cookie的Radware配置，解决动态IP访问网站问题 摘要，本文主要针对目前多省出现的WEB登陆出现“验证码输入错误”问题的分析，从Radware的四、七层功能原理和实现方式进行介绍，并结合XXX系统网站实际解决过程，详细说明基于Cookie会话保持的Radware配置方式，解决动态IP访问网站问题的思路和配置方案。 目前该问题部分省份通过现有桥接程序做一对一的端口映射，供特定用户群访问的方式来解决，该解决方式不在此做介绍。 一．问题描述及分析 问题现象描述 用户反映登录平台，在首页输入验证码后一直报错“验证码输入错误”，导致登录不上平台。经过现场维护人员的跟踪和测试，发现，导致该问题的直接原因是主机在访问互联网时出口IP地址频繁变更（即学校出口配置了多对多的NAT方式），而在系统Radware现有的配置模式下，用户每次访问的SESSION不能保证被分配到同一台主机，如果两次会话请求被分发在不同主机的话，就会出现访问异常。 图示说明如下： 图： 1数据流分析 问题分析 根据图1的数据流分析显示，在现实中的表象为当用户打开登陆页面和输入用户名、密码、验证码后点击登陆的两次请求，由于两次访问源IP地址发生变化被Radware送到了两台不同的WEB服务器，而第二次响应的服务器没有分配该临时验证码信息，导致用户验证码错误。对于分发策略，目前各省Radware Farm配置的负载均衡算法均为Cyclic（轮循）和Entry Per Session的四层会话模式。 Entry Per Session四层会话的模式，对于访问源IP不变的情况下会将请求送至同一台服务器，但对于源IP频繁变更的话，将不能保证被送至同一台服务器处理，即Cookie会话不能够保持。 Radware配置说明： 图： 2 开启7层Cookie会话保持 数据流图 实现原理说明： Radware学习并记录Cookie信息是在服务器的回包中进行，当用户第一次登录时，请求包通常没有带上Cookie信息，这时服务器会主动插入一个Cookie回应用户，这时Radware就记下这个Cookie是哪台服务器发的，下次用户只要带上这个Cookie访问，Radware就会主动将这个请求分发给发布该Cookie的服务器。 配置方案及说明 基于7层Cookie的Radware配置方法相对较为简单，在原有Farm和四层配置不变的情况下，增加Layer 7的配置即可，配置风险性较低，配置即时生效不需重启设备，出现异常删除配置即可回退。 AppDirector Layer 7 Sever Persistency Text Match Create 选择需要做会话保持的服务器的Farm，配置L4协议类型、端口号以及会话保持的关键字名称，需要注意Cookie的老化时间与应用的一致，单位是秒。 Farm Name: Farm名称 Application Port: 应用服务的端口号 Persistency Identifier : Cookie的ID，通常是 JSESSIONID Learning Direction: 系统默认为Server Reply，这也是最常的配置方法。表示AD学习并记录Cookie是从服务器的回包中进行。当用户第一次登录时，请求包通常没有带上Cookie信息，这时服务器会主动插入一个Cookie回应用户，这时AD就记下这个Cookie是哪台服务器发的，下次用户只要带上这个Cookie访问，AD就会主动将这个请求分发给发布该Cookie的服务器。也可以配置为Client Request，但不常用，表示Cookie学习的方向来自客户的请求 Inactivity Timeout: Cookie的老化时间，应该与应用的一致，1800秒为30分钟比较常见 配置好后，点击“set”保存。 AppDirector Layer 7 Sever Persistency Statistics 可以查看学习到的Cookie情况 注意事项 目前系统大部分省使用的Radware型号为AppDirector 100，在开启基于7层Cookie会话保持功能配置下会消耗Radware资源，维护人员在配置该功能时需关注Client Table量和设备负荷情况，但在当前情况下各省系统的Radware设备负荷普遍不高，出现连接数瓶颈问题几率不大。