1.七层代理模式还是IP层VPN
非常多人会问，我究竟是使用代理模式呢，还是使用VPN模式，假设我想数据在中间不安全的链路上实现加密保护的话。
这个问题有一个背景。那就是，你想保护你的数据，能够使用VPN，可是有时候，第七层的代理模式或许更好。比方SSL卸载器。比方内置SSL处理的代理。分为正向代理和反向代理。
正向代理：代理的是訪问者。一般位于訪问者一端，訪问者能意识到代理的存在，直接訪问代理，由代理向server发起訪问。
反向代理：反向代理代理的是被訪问者。
位于被訪问者一端。訪问者意识不到代理的存在。訪问者訪问代理。由代理将请求重定向到真正的server。
且看上述差别的后半段，全然同样。这也是最easy引起迷惑的地方，可是我如今的解释不关注这些，假设单看TCP层以及IP层的訪问模式。会发现上述的正向代理和反向代理没有不论什么差别-你会发现TCP层和IP层的封包是一样，因此差别正是体现于第七层-重点是实际訪问client是否设置代理。体如今HTTP头。当我们已经屏蔽了第七层的差别后，仅仅看TCP层的訪问模型，你会发现一个事实，即无论是正向代理还是反向代理。在TCP看来都用同样的方式卡在了路径*，client和代理建立TCP连接，代理和server建立TCP连接。
如今明确什么时候用代理什么时候用IP层VPN了吗？答案在于数据流的方向！
假设再深挖一下。假设数据流始终都是从你这里发起的。有一个代理声称能够替你完毕你要求的事务。还能够提供安全加密服务，未尝不可啊，假设还有一个代理对server声称。它能够汇集成千上万的client的訪问请求，那也行啊。可是代理对数据流的发起方向有要求。反过来就难了。对于服务端而言。它要主动发起一个到某个client的訪问，怎样使用代理，这意味着代理必须显式知道client的位置，而这差点儿是不可能。
此时须要一个新的方案，那是什么呢？那就是将整个反向的訪问流封装于一个正向建立的隧道内，这个隧道是长连接的。除非显式拆除。它会一直存在。
这是什么？这就是IPSec VPN。PP2P，L2TP。OpenVPN等三层以及三层下面的VPN。当然，使用三层以及三层VPN的代价就是你将不能处理全部的四层以上特别是七层的信息，比方你不能解析过境包的HTTP头(做这件事远远比你想的困难。首先你要识别出这是一个TCP的HTTP数据包，或许仅仅是一个IP分片。你要实现重组。或许是一个乱序的TCP段，你要实现TCP的按序逻辑...更现实的。或许一个HTTP头会分在多个TCP段中，....人生苦短，为何如此折磨自己，使用安全代理吧)...
假设你能保证数据流都是从client主动发往服务端的。且你须要更细的基于七层信息的控制粒度，且百折不扣地使用TCP代理。
假设哪怕有一类从服务端反向的连接，或者存在诸如UDP等协议的数据流。请考虑IP层VPN。
我们能够看到，使用IP层VPN始终是一种备选方案。是这种。这是现实，也是趋势。
请看看FTP的现实吧，FTP存在反向的连接，可是依旧存在安全的FTP代理。假设你认为FTP不够复杂。那么请看看标准的信令/数据分离的SIP协议，市面上也有了非常多的能够处理SIP协议的安全代理，这些都不是IP层的VPN。终于，IP层VPN仅仅剩下了一块保留地。那就是保持多个物理位置分离的子网之间的虚拟专用性(安全连通性)。这块保留地才是真实的IP层VPN的领域，其实。非常多其他方面的使用IP层VPN技术进行单点接入的系统都是一种误用！
对于单点接入系统以及单点訪问系统，链路的加密仅仅是一个基本不能再主要的安全需求，很多其他的訪问控制，接入控制。AAA等非常难集成在IP层VPN以内，即便OpenVPN提供了强大的push机制，client也是能够拒绝不论什么push reply的。
2.大便骑沟便沟内
这是什么含义？
还记得曾经那种*一条沟的厕所吗？在沟的一端墙壁上面有一个水箱。一拉绳子。水就冲下来，一冲一条沟。例如以下图所看到的：
请看错误的方式。尿不会落在大便池中。而是会洒在蹲位上，有时，假设角度没对准。大便也不会落在池中，而是会落在蹲位的还有一边，这会引起连锁反应，后来的人仅仅能採用蹲在同一边的错误方式，由于便池的还有一边有屎..于是我们的宿舍管理员李大爷再也忍不住了，用毛笔在宣纸上写下赫然几个大字。张贴于男厕所的墙壁上。上面写着“大便骑沟便沟内”。是的。书法手笔不错...