这种想法必须经过深思熟虑的，但不幸的是，。这是一个错误的想法。有文章《Why TCP Over TCP Is A Bad Idea》，详解了Why。
其实重传叠加问题是无法解决的，要知道，TCP的RTO计算是极其复杂的。影响它的因素也非常多，这就是说，仅仅要你用一个TCP封装还有一个TCP。外层TCP丢包，且RTO小于内层TCP的RTO。连接就会崩溃。而以上这个条件是非常easy满足的。
用TLS来封装IP数据报是对TLS的误用！SSL/TLS的初衷是提供传输层之上的安全层，本身执行了可靠的TCP上，其记录层协议封装的是应用层数据，因此。SSL/TLS是对基于TCP应用的安全增强，并非一个通用的传输协议。之所以TLS执行于TCP之上，就是这个原因。由于应用是基于TCP的。假设你想实现一个IP层的VPN，用TLS来封装IP数据报，就相当于你将IP数据报当成了一个基于TCP的应用数据，这不正是《Why TCP Over TCP Is A Bad Idea》中描写叙述的那种连接崩溃的场景吗？事实是，IP数据报显然不是基于TCP的应用数据。
后来出现了DTLS。显然去掉了非常多约束，轻量了非常多，假设非要封装使用TLS封装IP数据报，首先要想到的怎么也应该是DTLS而不是TLS。DTLS衍生自TLS，而且保留了UDP无序的语义。可是它还是从TLS继承了非常多复杂的东西，本质上，DTLS也是封装应用数据的，这些应用基于UDP。循着这个思路，假设我们能够将IP数据报看作是一个基于UDP的应用数据。那么就能够用DTLS封装它了。能吗？当然能。UDP本身就是IP的第四层镜像。仅仅是多了一个多路复用机制。
使用DTLS封装IP数据报实现一个IP层VPN将会是一个不错的选择，可是还有更好的方法。
OpenVPN提供了一种更好的方式。仅仅使用TLS实现控制通道。而封装加密IP数据报的数据通道则是首选普通UDP通道。这有点IPSec的影子，不是吗？IPSec使用独立的IKE协商好SA，然后使用独立的ESP/AH协议封装加密IP数据报。
其实。这才是实现IP层VPN的正确方式，本来安全參数的协商和认证/加密就是两个独立的过程，独立的过程。
TLS/DTLS将这些封装进了一个会话过程中。该会话通过一个称为SSL握手的过程建立。在握手的过程中协商安全參数。握手完成后将使用协商好的安全參数保护兴许的应用数据。这样的方式的不灵活性在于你无法添加自己的协商机制，除非改动TLS协议。
另外作为一个TLS Record，IP数据报被封装在Application data中，外部能看到的仅仅是一个TLS Record，中间系统非常难对其进行识别和控制，也就是说。作为加密后的IP数据报的传输协议。TLS非常适合。可是非常难从外部去控制它，你看到的永远是一个TLS Record头，而看不到VPN协议的头。
对于IP数据报的保护，终于的思想还是IPSec的那套思想。即定义安全端点，定义安全联盟。协商安全參数，保护IP数据报，四个过程是全然独立的。
尽管你能够将IP数据报看作是“应用数据”，可是它毕竟不是应用数据，TLS源自应用数据的安全需求，它针对单一应用，单独的业务逻辑能够起到非常好的安全加固作用，比方实现HTTPS。比方OpenVPN的控制通道，这些都是业务单一且固定的应用。可是加密IP数据报却不适合，抛开TCP over TLS的连接崩溃问题不谈而引入DTLS，控制和传输叠加在一个会话中将会使扩展非常难，比方防火墙无法区分VPN数据和其他TLS应用数据。比方无法实现组播加密，比方无法重协商单独的安全參数，同一个SSL会话无法被不同的安全端点共享...
因此， 使用TLS记录封装IP层VPN IS A Bad Idea。DTLS更好，但是不是绝对的。真正的好节目，最大限度地利用TLS不要控制通道协商交换安全参数，然后定义一个单独的封装协议封装保护的安全参数IP数据报。
样品太多，IPSec。OpenVPN。只是OpenVPN该代码是太恶心了，据了解，这个想法写了后它。也许它会更好。