过了几天，小丽的男朋友又给小丽打来了电话，对方报的电话是“7654321”，王爷爷一看通讯录，靠： 

门牌    电话 
一号门    1234567  （这个是小明的） 
一号门    7654321  （注意：这个原来是小丽的，但是被小明改了） 
...... 

     王爷爷不知道改了啊，于是就去找一号门的小明了，小明心里这个美啊，他以小丽父亲的口吻严厉的教训了那个男的和小丽之间不正当的男女关系，结果那个男的恭恭敬敬的挂了电话。当然小丽并不知道整个事情的发生... 

    这里小明的行为叫做“ARP欺骗”（因为在实际的网络上是通过发送ARP数据包来实现的，所以叫做“ARP欺骗”），王爷爷的通讯录叫做“ARP表” 

    这里要注意：王爷爷现在有两个通讯录了，一个是记录每个院子传达室电话的本本，叫做“路由表”，一个是现在说的记录院子里面详细信息的本本，叫做“ARP表”。 

    有句命言是“人们总是在追求完美的，尽管永远也做不到”（请记住这句话，因为这是一个大名人--也就是我，说的） 

    王爷爷的制度中有一条是这么写的“每个月要重新检查一下门牌号和电话的对应本（也就是ARP表）”，这个动作叫做“刷新ARP表”，每个月的时间限制叫做“刷新ARP表的周期”。这样小明为了让那个男的永远不能找到小丽，之后每个月都要偷偷改一次那个通讯录，不过这样也是不得不做的事啊！ 
    补充一点，小明是很聪明的，如果通讯录（ARP表）被改成了这样： 

门牌（MAC）    电话（IP） 
一号门             1234567  （这个是小明的） 
二号门             1234567  （注意：这个被小明改了，但是他一时头晕改错了） 
...... 

    就会是计算机就会弹出一个对话框提示“出现重复的IP地址”，最终会导致王爷爷不知所措，于是通知一号门和二号门，你们的电话重复了。这样小丽就知道有人在破坏她的好事，这个现象叫做“骗局被揭穿了” 

小不点知道了小明偷听他和小暗的电话，于是就和小暗约定好了密码。小不点在家里把要说的加密了之后告诉小暗。土豆－〉星期三，地瓜－〉请客，笨蛋－〉小不点家。于是小不点告诉小暗：土豆笨蛋地瓜。小明听了？？？不懂。。。。郁闷了。。。这是加密。 
除此之外，小丽也知道了小明改他家的电话号码了。于是王爷爷就登门一个一个把电话和门牌号记下来。并且藏起来不允许外人修改，只能自己有钥匙（密码）。这是ip地址和MAC地址绑定。当有人改了电话号码的时候，就得找王爷爷改。麻烦是麻烦了，但是安全了。不过小明偷偷的把王爷爷的钥匙偷配了一把（盗窃密码成功），于是他还可以修改。这样么，就这样了。

VPN实现的是一块更为广袤的“私密空间”和一条更为隐秘的“安全通道”。

随着网络应用的遍地开花，安全技术逐渐成为VPN产品的一个拳头支撑，基于IPSec和SSL协议的不同VPN产品也正表现着VPN的不同安全特色……

在如今的网络时代，信息共享正在被赋予越来越丰富的外延，诸如本地信息的远程化、远程资源的本地化等，但凡能通过网络方式实现的，人们都乐此不疲地琢磨并尝试着。

VPN（虚拟专用网络）作为一种虚拟通道技术，其最初的设想只是为了满足远程访问的专用接入需求，并且能够避开IP地址资源有限的尴尬，而最终大量产品的市场需求以及后续VPN技术的不断延伸发展，也足以说明网络信息化对这一专用通道技术的强烈呼唤。

伴随着社会本身的进步以及信息化进程的大副进展，各种网络应用随即接踵而至，越来越多的安全需求成为VPN技术的关键。

总览VPN的安全实现

在原先维持网络更多虚拟空间的前提下，如何保证接入用户的合法性、保证网络访问的安全性以及系统本身的安全可靠性等等，都成为VPN需要面对的问题。

首先，VPN能保障哪些安全呢？很容易想象，VPN的实现技术和方式有很多，但是所有的VPN产品都应该保证通过公用网络平台传输数据的专用性和安全性。如在非面向连接的公用IP网络上建立一个隧道，利用加密技术对经过隧道传输的数据进行加密，以保证数据的私有性和安全性。此外，还需要防止非法用户对网络资源或私有信息的访问。

其次，VPN还应当为不同网络的数据提供不同等级的服务质量保证（QoS）。如对移动办公的用户，随意自主的连接性和信号的覆盖性就是VPN服务质量保证的一个主要因素；而当分支机构某用户通过VPN专有网对总部系统网络进行访问的话，整个总部系统的网络需要保持良好的稳定性。

此外，对于带宽和流量的控制，则是对网络优化的一个重要方面。充分有效地利用有限的广域网资源，保证重要数据的有效且可靠的带宽，将是关系网络整体稳定性的一个重要指标。通过流量预测与流量控制策略，可以按照优先级实现带宽资源的合理配置和管理，从而净化所处的网络。

IPSec VPN：端对端的安全

隧道技术是最典型、也是应用最为广泛的VPN技术，通过匹配四层网络模型中的不同层协议，可以生成不同的VPN技术及产品，如IPSec VPN就是第三层隧道协议匹配IP层（第三层）的IPSec协议生成的，而SSL VPN则是第四层隧道协议匹配应用层（第四层）的SSL协议生成的，这两种VPN也是当前业内最为流行的VPN技术及产品。

IPSec工作于网络层，是一个开放的结构，定义在IP数据包格式中，不同的加密算法都可以利用IPSec定义的体系结构在网络数据传输过程中实施。IPSec协议可以设置成在两种模式下运行：一种是隧道（tunnel）模式，一种是（transport）模式。隧道模式下，IPSec把IPv4数据包封装在安全的IP帧中。传输模式是为了保护端到端的安全性，即在这种模式下不会隐藏路由信息。IPSec几乎可以为所有的应用提供访问，包括客户端/服务器模式和某些传统的应用，但是由于基于网络层，不能穿越通常的NAT、防火墙。

IPSec为Internet业务提供最强的安全功能，与其他隧道和安全技术相比，其优越性在于它的安全性和互操作性，但是管理相对复杂。IPSec得到各厂商广泛支持，非常适合于组建远程网络互联VPN。如果需要相对安全、保密的通道、网络流量有限、对业务实时性要求不高，应首选IPSec建立VPN。

IPSec VPN是基于IPSec协议的VPN产品，由IPSec协议提供隧道安全保障。IPSec是一种由IETF设计的端到端的确保基于IP通讯的数据安全性的机制。IPSec隧道模式具有以下特点：只能支持IP数据流；工作在IP栈的底层，因此，应用程序和高层协议可以继承IPSEC的行为；由一个安全策略（一整套过滤机制）进行控制。安全策略按照优先级的先后顺序创建可供使用的加密和隧道机制以及验证方式。当需要建立通讯时，双方机器执行相互验证，然后协商使用何种加密方式。此后的所有数据流都将使用双方协商的加密机制进行加密，然后封装在隧道包头内。

目前防火墙产品中集成的VPN使用较多的是IPSec 协议，在中国其发展处于蓬勃状态。

　　PPP（Point-to-Point Protocol点到点协议）是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作，并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。

　　二、 PPP链路建立过程

　　PPP协议中提供了一整套方案来解决链路建立、维护、拆除、上层协议协商、认证等问题。PPP协议包含这样几个部分：链路控制协议LCP（Link Control Protocol）；网络控制协议NCP（Network Control Protocol）；认证协议，最常用的包括口令验证协议PAP（Password Authentication Protocol）和挑战握手验证协议CHAP（Challenge-Handshake Authentication Protocol）。

　　LCP负责创建，维护或终止一次物理连接。NCP是一族协议，负责解决物理连接上运行什么网络协议，以及解决上层网络协议发生的问题。

　　下面介绍PPP链路建立的过程：

　　PPP链路状态机如图1所示。一个典型的链路建立过程分为三个阶段：创建阶段、认证阶段和网络协商阶段。

　　阶段1：创建PPP链路

　　LCP负责创建链路。在这个阶段，将对基本的通讯方式进行选择。链路两端设备通过LCP向对方发送配置信息报文（Configure Packets）。一旦一个配置成功信息包（Configure-Ack packet）被发送且被接收，就完成了交换，进入了LCP开启状态。

　　应当注意，在链路创建阶段，只是对验证协议进行选择，用户验证将在第2阶段实现。

　　阶段2：用户验证

　　在这个阶段，客户端会将自己的身份发送给远端的接入服务器。该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。在认证完成之前，禁止从认证阶段前进到网络层协议阶段。如果认证失败，认证者应该跃迁到链路终止阶段。

　　在这一阶段里，只有链路控制协议、认证协议，和链路质量监视协议的packets是被允许的。在该阶段里接收到的其他的packets必须被静静的丢弃。

　　最常用的认证协议有口令验证协议（PAP）和挑战握手验证协议（CHAP）。 认证方式介绍在第三部分中介绍。

　　阶段3：调用网络层协议

　　认证阶段完成之后，PPP将调用在链路创建阶段（阶段1）选定的各种网络控制协议（NCP）。选定的NCP解决PPP链路之上的高层协议问题，例如，在该阶段IP控制协议（IPCP）可以向拨入用户分配动态地址。

　　这样，经过三个阶段以后，一条完整的PPP链路就建立起来了。

　　三、 认证方式

　　1）口令验证协议（PAP）

　　PAP是一种简单的明文验证方式。NAS（网络接入服务器，Network Access Server）要求用户提供用户名和口令，PAP以明文方式返回用户信息。很明显，这种验证方式的安全性较差，第三方可以很容易的获取被传送的用户名和口令，并利用这些信息与NAS建立连接获取NAS提供的所有资源。所以，一旦用户密码被第三方窃取，PAP无法提供避免受到第三方攻击的保障措施。

　　2）挑战-握手验证协议（CHAP）

　　CHAP是一种加密的验证方式，能够避免建立连接时传送用户的真实密码。NAS向远程用户发送一个挑战口令（challenge），其中包括会话ID和一个任意生成的挑战字串（arbitrary challengestring）。远程客户必须使用MD5单向哈希算法（one-way hashing algorithm）返回用户名和加密的挑战口令，会话ID以及用户口令，其中用户名以非哈希方式发送。

　　CHAP对PAP进行了改进，不再直接通过链路发送明文口令，而是使用挑战口令以哈希算法对口令进行加密。因为服务器端存有客户的明文口令，所以服务器可以重复客户端进行的操作，并将结果与用户返回的口令进行对照。CHAP为每一次验证任意生成一个挑战字串来防止受到再现攻击（replay attack）。在整个连接过程中，CHAP将不定时的向客户端重复发送挑战口令，从而避免第3方冒充远程客户（remote client impersonation）进行攻击。

　　四、PPP协议的应用

　　PPP协议是目前广域网上应用最广泛的协议之一，它的优点在于简单、具备用户验证能力、可以解决IP分配等。

　　家庭拨号上网就是通过PPP在用户端和运营商的接入服务器之间建立通信链路。 目前，宽带接入正在成为取代拨号上网的趋势，在宽带接入技术日新月异的今天，PPP也衍生出新的应用。典型的应用是在ADSL（非对称数据用户环线，Asymmetrical Digital Subscriber Loop）接入方式当中，PPP与其他的协议共同派生出了符合宽带接入要求的新的协议，如PPPoE（PPP over Ethernet），PPPoA（PPP over ATM）。

　　利用以太网（Ethernet）资源，在以太网上运行PPP来进行用户认证接入的方式称为PPPoE。PPPoE即保护了用户方的以太网资源，又完成了ADSL的接入要求，是目前ADSL接入方式中应用最广泛的技术标准。

　　同样，在ATM（异步传输模式，Asynchronous Transfer Mode）网络上运行PPP协议来管理用户认证的方式称为PPPoA。它与PPPoE的原理相同，作用相同；不同的是它是在ATM网络上，而PPPoE是在以太网网络上运行，所以要分别适应ATM标准和以太网标准。

　　PPP协议的简单完整使它得到了广泛的应用，相信在未来的网络技术发展中，它还可以发挥更大的作用。

PPP协议文档

传输控制协议（Transmission Control Protocol，TCP）是一种面向连接的、可靠的、基于字节流的运输层通信协议，通常由IETF的RFC 793说明。在简化的计算机网络OSI模型中，它完成运输层所指定的功能。

在因特网协议族中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。

应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分割成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传送单元(MTU)的限制）。之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包，就给每个字节一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。

TCP通路的建立和终结
TCP连接包括三个状态：连接建立、数据传送和连接终止。TCP用三路握手过程建立一个连接，用四路握手过程建立来拆除一个连接。在连接建立过程中，很多参数要被初始化，例如序号被初始化以保证按序传输和连接的强壮性。

连接建立（三路握手）
一对终端同时初始化一个它们之间的连接是可能的。但通常是由一端打开一个套接字(socket)然后监听来自另一方的连接，这就是通常所指的被动打开。被动打开的一端就是服务器端。而客户端通过向服务器端发送一个SYN来建立一个主动打开，作为三路握手的一部分。服务器端应当为一个合法的SYN回送一个SYN/ACK。最后，客户端再发送一个ACK。这样就完成了三路握手并进入了连接建立状态。

数据传输
在TCP的数据传送状态，很多重要的机制保证了TCP的可靠性和强壮性。它们包括：使用序号对收到的TCP报文段进行排序以及检测重复的数据；使用校验和来检测报文段的错误；使用确认和计时器来检测和纠正丢包或延时。

在TCP的连接建立状态，两个主机的TCP层间要交换初始序号 (ISN)。这些序号用于标识字节流中的数据，并且还是对应用层的数据字节进行记数的整数。通常在每个TCP报文段中都有一对序号和确认号。TCP报文发送者认为自己的字节编号为序号，而认为接收者的字节编号为确认号。TCP报文的接收者为了确保可靠性，在接收到一定数量的连续字节流后才发送确认。这是对TCP的一种扩展，通常称为选择确认(SACK)。选择确认使得TCP接收者可以对乱序到达的数据块进行确认。

通过使用序号和确认号，TCP层可以把收到的报文段中的字节按正确的顺序交付给应用层。序号是32位的无符号数，在它增大到232-1时便会回绕到0。对于ISN的选择是TCP中关键的一个操作，它可以确保强壮性和安全性。

TCP的16位的校验和的计算和检验过程如下：发送者将TCP报文段的头部和数据部分的反码和计算出来，再对其求反码，就得到了校验和，然后将结果装入报文中传输。（这里用反码和的原因是这种方法的循环进位使校验和可以在16位、32位、64位等情况下的计算结果在叠加后相同）接收者在收到报文后再按相同的算法计算一次校验和。这里使用的反码使得接收者不用再将校验和字段保存起来后清零，而可以直接将报文段连同校验和一起计算。如果计算结果是-0，那么就表示了报文的完整性和正确性。

注意：TCP校验和也包括了96位的伪头部，其中有源地址、目的地址、协议以及TCP的长度。这可以避免报文被错误地路由。

按现在的标准，TCP的校验和是一个比较脆弱的校验。具有高出错率的数据链路层需要额外的连接错误纠正和探测能力。如果TCP是在今天被设计，它很可能有一个32位的CRC校验来纠错，而不是使用校验和。但是通过在第二层使用通常的CRC或更完全一点的校验可以部分地弥补这种脆弱的校验。第二层是在TCP层和IP层之下的，比如PPP或以太网，它们使用了这些校验。但是这也并不意味着TCP的16位校验和是冗余的，对于因特网传输的观察表明在受CRC保护的各跳之间，软件和硬件的错误通常也会在报文中引入错误，而端到端的TCP校验能够捕捉到很多的这种错误。这就是应用中的端到端原则。

数据发送者之间用对接收数据的确认或不予确认来显式的表示TCP发送者和接收者之间的网络状态。再加上计时器，TCP发送者和接收者就可以改变数据的流动情况。这就是通常所指的流量控制，拥塞控制/或拥塞避免。TCP使用大量的机制来同时获得强壮性和高可靠性。这些机制包括：滑动窗口、慢启动算法、拥塞避免算法、快速重启和快速恢复算法等等。对于TCP的可靠的丢包处理、错误最小化、拥塞管理以及高速运行环境等机制的优化的研究和标准制定，正在进行之中。

连接终止
连接终止状态使用了四路握手过程，在这个过程中每个终端的连接都能独立地被终止。因此，一个典型的拆接过程需要每个终端都提供一对FIN和ACK。

TCP的端口
TCP使用了端口号的概念来标识发送方和接收方的应用层。对每个TCP连接的一端都有一个相关的16位的无符号端口号分配给它们。端口被分为三类：众所周知的、注册的和动态/私有的。众所周知的端口号是由因特网赋号管理局(IANA)来分配的，并且通常被用于系统一级或根进程。众所周知的应用程序作为服务器程序来运行，并被动地侦听经常使用这些端口的连接。例如：FTP、TELNET、SMTP、HTTP等。注册的端口号通常被用来作为终端用户连接服务器时短暂地使用的源端口号，但它们也可以用来标识已被第三方注册了的、被命名的服务。动态/私有的端口号在任何特定的TCP连接外不具有任何意义。可能的、被正式承认的端口号有65535个。

TCP的发展历程
TCP是一个复杂的但同时又是在发展之中的协议。尽管许多重要的改进被提出和实施，发表于1981年的RFC793中说明的TCP的许多基本操作还是未作多大改动。RFC1122：《因特网对主机的要求》阐明了许多TCP协议的实现要求。RFC2581：《TCP的拥塞控制》是一篇近年来关于TCP的很重要的RFC，描述了更新后的避免过度拥塞的算法。写于2001年的RFC3168描述了对明显拥塞的报告，这是一种拥塞避免的信号量机制。在21世纪早期，在所有因特网的数据包中，通常有大约95%的包使用了TCP协议。常见的使用TCP的应用层有HTTP/HTTPS（万维网协议），SMTP/POP3/IMAP（电子邮件协议）以及FTP（文件传输协议）。这些协议在今天被广泛地使用，这证明了它们的原作者的创造是卓越的。

最近，一个新协议已经被加州理工学院的科研人员开发出来，命名为FAST TCP（基于快速活动队列管理的规模可变的传输控制协议）。它使用排队延迟作为拥塞控制信号；但是因为端到端的延迟通常不仅仅包括排队延迟，所以FAST TCP (或更一般地，所有基于排队延迟的算法) 在实际互联网中的能否工作仍然是一个没有解决的问题。

对TCP的选用情况
TCP并不是对所有的应用都适合，一些新的带有一些内在的脆弱性的运输层协议也被设计出来。比如，实时应用并不需要甚至无法忍受TCP的可靠传输机制。在这种类型的应用中，通常允许一些丢包、出错或拥塞，而不是去校正它们。例如通常不使用TCP的应用有：实时流多媒体（如因特网广播）、实时多媒体播放器和游戏、IP电话（VoIP）等等。任何不是很需要可靠性或者是想将功能减到最少的应用可以避免使用TCP。在很多情况下，当只需要多路复用应用服务时，用户数据报协议（UDP）可以代替TCP为应用提供服务。