VPN DNS leak 问题的解决

前一段时间遇到一个问题。customer说发现连接VPN后在PPP端发现security leak，整个转了好大一个圈子才把问题解决了。之所以费这么大周折，倒不是因为很难解决，只是费了很大劲儿才定位了root cause。

1. 到底是不是security leak？

customer说连到VPN server，然后ping的过程中就发生了DNS leak，因为他们在PPP看到了明码。我跟他们一顿解释，在发送端，数据是在PPP以下的层次中的数据都是加密的。在接收端是在PPP以上的层次看到的数据都是解密的，这是正常的，不是security leak。

图1 VPN 在stack中的位置

他说不好意思，听不懂你在说什么，我只好继续发图解释。Tunnel保护数据在internet中的传输，到达corpnet后就被解密了。在接收端的PPP以上的层次接收到的肯定是明码，因为已经被解密过了。

图2 网络结构

对方是一个印度的大概是在线支持之类的角色吧。经过一轮沟通，他还是不清楚我在说什么。最后只好吐血画了张大图继续和他解释。在中间的绿色部分是处在VPN tunnel中的，如果在这儿的任意一层发现明码肯定是leak，但是到达VPN server后，上升到绿色部分以上之后就不再是VPN的保护范围了，应该所以能看到明码。

图3 网络结构

他说好像是懂了，他说customer的拓扑要比这个复杂。是client先通过ISP连到internet，然后再通过internet连到VPN sever的。这就有点麻烦了，因为他描述的scenario中包含两个PPP，我问他是在哪个PPP上发现了security leak。他说在两个PPP处都发现了明码DNS。

图4 customer的网络结构

好的，这下算是说到根上了。VPN server的PPP上发现DNS明码是正常的，但如果是在PPPoE的PPP上发现了明码，那基本就是security leak了。为了确认真的是这样，我在本地搭建环境重现了一下，在PPPoE server中抓到了这个结果，可以肯定DNS leak确实发生了。

图5 抓到的数据包

2. 问题的定位

印度同事终于提供了全套数据给我，可以详细分析一下问题背后的原因了。首先查路由相关信息。在他们提供的信息中我没有看到PPPoE的信息，但确实看到了DNS leak。看来leak和网络拓扑没有关系。路由表也没有发现明显问题，根据路由表，即使发给11.22.33.44 DNS Server的数据报也应被发送到VPN Server才对。

图6 client端路由表

图7 client端IP

图8  client端DNS leak query

这就有点麻烦了，问题可能是有几个原因导致的：

（1） 路由代码有问题；

（2） 路由查找中使用cache导致的；

（3） DNS代码的问题。

经研究发现，这个问题在IP层是解决不了的。因为有一种特殊情况，就是如果DNS Server和client是在同一网段的话，按照路由表，DNS query是一定要被直接路由到物理网卡而不是PPP的网卡。因此最终决定在应用层搞定，当发送DNS query时，首先判断是否存在VPN interface，如果有则所有DNS query都经过VPN interface发送，否则正常发送。