vpn网络建设解决技术方案

vpn网络建设解决技术方案内容摘要：

组网方式 IPVPN 的联网方式大致有三种： 固定 IP 与固定 IP； 固定 IP 与动态 IP； 动态 IP 与动态 IP。 第一种的联网方式是比较传统的方式，技术上实现最容易，目前的防火墙等设备就可以实现这种功能；第二种的 VPN 联网方式对于目前大多数专业的 VPN 厂商也基本能解决；而第三种方式即动态 IP 与动态 IP 之间的 VPN 通讯却成了很多厂商和科研机构望而却步的技术难题，实现起来并解决大规模的实际应用就更加困难。 xxx 公司 作为国内领先的专业 VPN 厂商，投入了很大的人力、财力，经过一 段时间的攻关和研究，最终以 “策略服务器” 的方式解决了这个难题。 “策略服务器” 管理系统由 Dynamic VPN 管理服务器、网络管理员和 Dynamic VPN 网元组成。 Dynamic 管理服务器由 WEB 服务器、管理应用服务器、数据库服务器组成。 WEB服务器负责以 WEB 服务的形式对外提供各种管理服务，管理应用服务器完成具体的逻辑与业务处理功能，数据库服务器负责保存 Dynamic VPN 管理所需要的各种数据，它可以是关XX 集团 VPN 网络建设解决方案 第 10 页 共 25 页 系数据库和 /或 LDAP 服务器。 xxx 公司 的 “策略服务器 ”不但真正解决了全动态的 VPN 组网方案，还融入了 PKI 技术，采用基于数字证书的动态 IKE 进行协商和认证，解决了大规模 VPN 组网的安全管理和安全认证技术。 基于 IPVPN 中 NAT 穿透问题 基于 IPsec 的 VPN 解决方案中 NAT 穿透问题一直是很多厂商以及客户所棘手的问题。 不但 IPsec 协议本身不能穿透 NAT 设备，就是常用的视频、语音等通讯方式所用的 和 SIP 协议也不能穿透 NAT。 下面以 A、 B 两地实现视频会议为例，阐述一下 NAT 穿透问题。 我们假设在 宽带城域网 有两个用户 A 和 B，其中 A 用户处在私网内部， B 用户是在Inter 公网上，这两个用户都 安装了 IP 视频会议终端，希望通过 宽带城域网开个临时的视频会议。 如下图示， B 用户首先呼叫 A 用户， B 用户发出的 或 SIP 建立会话连接的初始化包发送到 A 用户网络的 NAT 设备时，由于 NAT 设备只做 IP 地址转换的处理，因此不知道该如何将 B用户发来的 或 SIP 建立会话连接的初始化包转发给内网的哪个用户，只好将该初始化包丢弃。 而 A 用户虽然一直在等待 B 用户的初始化包，但 A 用户却永远等不到 B 用户的初始化包，这样 A 用户和 B 用户永远都建立不起来 或 SIP 会话连接，也就无法开 IP 视频会议。 图 32 NAT 穿透问题示意图（一） 另一种情况也一样，由 A 用户首先呼叫 B 用户，如下图示， A 用户发出的 或 SIP建立会话连接的初始化包发送到 A 用户网络的 NAT 设备时，由于 NAT 设备只做 IP 地址转换的处理， NAT 设备将该 IP 包包头中的 A 用户私网地址替换成自己的公网地址，这样 A用户发出的 或 SIP 建立会话连接的初始化包才能够发送 B 用户处， B 用户上层的 视频XX 集团 VPN 网络建设解决方案 第 11 页 共 25 页 会议应用程序收到该初始化包，并作出应答，但是 A 用户在发出 或 SIP 建立会话连接 的初始化包时，在上层应用数据包中采用的地址是 A 用户的私网地址，这样 B 用 户上层的 视频会议应用程序就会采用初始化包中上层应用数据包里的 A 用户的私网地址来发送应答包，由于 A 用户的地址是私网地址，因此该应答包就无法在公网上传送。 这样 A 用户和B 用户还是建立不起来 或 SIP 会话连接，还是无法开 IP 视频会议。 图 33 NAT 穿透问题示意图（二） xxx 公司 作为国内领先的专业 VPN 厂商，经过一段时间的 攻关和研究，初步解决了 NAT穿透问题，为企业构建跨城域网的 VPN 网络以及视频、语音通讯的建立提供了解决方案。 如果需要实现穿越 NAT 的安全连接，需要在内部网络和外部网络之间设置 ADT 引擎（需要在 NAT 设备上为 ADT 引擎作静态地址翻译）或者在外网（公网）设置 ADT 引擎。 ADT引擎是一个专用 UDPT(即 UDP 隧道 )数据包的路由转发软件，放置在网络边缘，在内部网络和外部网络之间转发数据流量。 下面为数据包的结构： UDPT 封装 标准 IP 报文 IP Tunnel Header UDP Header UDPT header IP virtual header IPSec headers(optional) Pay load XX 集团 VPN 网络建设解决方案 第 12 页 共 25 页 UDPT 包在经过 ADT 引擎转发时， ADT 引擎根据 UDPT 包内的 UDPT Header 域所指定的路由信息来更换 UDPT 包 IP Tunnel Header 域的源地址和目的地址，从而完成从一个私网成员到另一个私网成员的包转发，而 UDPT 包内部的 IP Virtual Header 的源地址和目的地址始终保持不变，保证了上层应用中 IP 地址的完整性，从而实现 IPSec、 SIP 等多媒体协议端到端通信的完整性。 系统设计功能分析 企业建设安全的信息系统，一个前提是不能改变原 有的应用方式，并且既要保证安全的远程访问（加密），又要和正常的直接访问（明文）相兼容，适合多种多样的应用需求。 按照本方案建设的网络安全系统，将在不改变应用系统结构和用户的使用习惯已经与正常访问兼容的基础之上，为 XX 集团的信息系统提供强有力的安全保障，并在移动接入、分支机构网络等方面为企业节省成本，带来直接的效益。 VPN 系统对原有系统的兼容 VPN 安全网关遵循标准的 Ipsec 和 IKE 协议，在网络层对 IP 数据包进行加密，对网络中的数据流做基于五元组的访问控制，因此，对于应用系统是完全透明的，即上 层的应用程序感觉不到数据在传输过程中被加密；也就是最终用户感觉不出使用了 VPN 前后在网络系统上有什么不同，也不必对自己平时的使用习惯做任何改变；应用程序的开发商也不需要对在 VPN 上使用的系统做特别的修改。 在 XX 集团内部，无论是目前已投入使用的多套应用系统，还是以后的新系统，不管系统平台如何，采用的结构是传统的 C/S 还是 B/S，都将可以平滑过渡到 VPN 网络平台上使用。 Ipsec 协议决定了只要在网络传输上使用 TCP/IP 协议的应用系统，都可以在 VPN 平台下正常运行，然而在 TCP/IP 协议作为事实上的工业标准的今天，任何新开发的应用系统都是基于此的，因此对于将来的 ERP 等系统修改、扩展乃至增加系统等等， VPN 系统完全不需更改，不必要担心应用系统的兼容性问题。 VPN 系统对原有网络的兼容 由于根据网络设计 VPN 设备 —— VPN 安全网关将会串行的连接在总部的路由器之后，XX 集团 VPN 网络建设解决方案 第 13 页 共 25 页 并将作为分公司的路由设备为网络提供路由，因此，在增加了这个设备后会不会影响原有正常的网络访问，比如 WEB、 MAIL、 DNS 等等是一个必须说明并确认的问题。 这个问题可以分为二个方面来讨论，首先是内部的服务器是否能象原来一样向外提供服务，其次是内部网络用户是否能正常访问互联网（ Inter）。 下面将就这二点分别阐述。 1） 服务器单独放在一个子网中，使用私有 IP 地址，对外是不可见的，但可以通过在 VPN 安全网关上配置静态端口映射，使得外部网络可以访问到该服务器的某端口，而通常服务器都是通过 TCP 或 UDP 的某一个的端口来提供服务（比如 WEB 使用 TCP 的 80 端口， DNS 使用 UDP 的 53 端口等等），因此对于绝大多数的 应用，都可以使用静态端口映射来满足向外提供服务的需求。 对于某些少数在网络通信中使用不固定端口的应用，还可以通过静态地址映射来达到目的，即将整个服务器映射成公有地址。 这样， XX 集团公司中所有需要公开的服务器都可以利用 VPN 安全网关的静态端口映射和静态地址映射向外提供服务。 2） 内网主机众多，可是公有 IP 地址有限，要访问互联网必须通过地址转换来实现，VPN 安全网关的地址池映射功能可以满足提供内部网络上互联网的要求，并且还可以对上网的主机和时间段作出控制。 同样，对于分公司的子网，也可以通过 VPN 安全网关的地址池映射功 能提供内部主机的上网。 为满足以上二点采用的各种技术和 VPN 安全加密功能都可以同时发挥作用， VPN 安全网关将根据数据包的 IP 地址和端口（五元组）信息自动地对 IP 数据包作出相应地处理，达到以上的目的。 即 VPN 系统与原有的网络系统完全兼容，绝不会因建设了 VPN 系统而导致原有的正常访问中断或改变方式。 网络层的访问控制和身份认证 VPN 系统在网络层实现了访问控制和身份认证功能。 当一个用户需要访问受网关保护的服务器的信息时， VPN 安全网关首先根据预先配置的策略判断对方的 IP 地址是否授权的用户，如果有为对 方配置的策略，则开始 IKE 密钥协商，密钥协商包含了身份认证的过程，在基于 PKI 体系下的身份认证能很好地确保网络访问的安全性和唯一性。 只有在 IKE 密钥协商成功以后， VPN 安全网关才会把服务器的返回数据通过加密发送到客户端；对进来的数据进行完整性校验和解密。 XX 集团 VPN 网络建设解决方案。