我使用OpenVPN设置这些指示,目的是使用AWS地址连接到外部世界,而不是我的ISP分配的IP。
连接成功。当我在连接到VPN时(从客户端)进行ping (例如,google.com )时,我会得到
Pinging google.com [172.217.9.174] with 32 bytes of data:
Reply from 172.217.9.174: bytes=32 time=122ms TTL=45
Reply from 172.217.9.174: bytes=32 time=262ms TTL=45
Reply from 172.217.9.174: bytes=32 time=119ms TTL=45
Reply from 172.217.9.174: bytes=32 time=121ms TTL=45与不使用VPN连接时速度稍快的ping相比,
Pinging google.com [172.217.6.174] with 32 bytes of data:
Reply from 172.217.6.174: bytes=32 time=84ms TTL=52
Reply from 172.217.6.174: bytes=32 time=85ms TTL=52
Reply from 172.217.6.174: bytes=32 time=89ms TTL=52
Reply from 172.217.6.174: bytes=32 time=82ms TTL=52但是,当我试图在客户端的浏览器中加载网站(例如cnn.com)时,加载几乎总是超时。
我试着添加
sndbuf 0
rcvbuf 0对于客户机和服务器上的OpenVPN配置,结果相同。
客户端是Windows 10,服务器Ubuntu16.04运行在AWS实例上。在尝试连接期间,top不会显示服务器上的任何重要负载。
客户端的连接是300 Mbps下降/ 30 Mbps向上。
我还能尝试在OpenVPN上实现可用的速度吗?
发布于 2017-05-23 19:10:41
我不能对此发表评论,因为我目前缺乏声誉。
首先,在AWS中您在哪个可用性区域上设置了EC2实例?我猜是离你最近的?你在AWS中运行VPC吗?这两种方法都引入了许多其他变量,这些变量可能导致网络性能差。
我的怀疑是,对于OpenVPN设置来说,t2.nano还不够强大。您所遵循的说明具体说明使用t2。据我的经验,t2.nano的网络性能非常差,尽管t2. much并没有那么好。
因此,我建议的解决方案是将实例提高到t2.microor,甚至是t2.media(暂时),以排除AWS中的网络性能。
考虑到上述问题不能解决这个问题,我下一次的怀疑将是分裂隧穿的一个可能的问题。你的客户是否强迫所有车辆通过你的隧道?您可以通过发出route PRINT或tracert google.com来检查这一点。如果使用route选项,那么您应该看到所有的流量都指向隧道。如果使用tracert选项,那么您应该可以看到您的第二次或第三次跳通过您的虚拟专用网。
考虑到上面两个选项中的一个显示了通过VPN的流量路由,那么您知道分割隧道是禁用的。然而,这并不意味着DNS将像预期的那样工作。尝试执行nslookup google.com 8.8.8.8。这迫使Google的公共DNS服务器(8.8.8.8)执行域名解析,而不是本地网络,或者AWS中的DNS。现在发布nslookup google.com 192.168.1.1,用本地网关(通常是路由器)的IP地址替换192.168.1.1。如果这是可行的,那么最后一个选项是将SSH放入EC2实例并只发出nslookup google.com。
如果在执行完上述所有操作后,您仍然会遇到此问题,请在执行上述步骤时回复您所做的任何进一步发现。
https://serverfault.com/questions/850822
复制相似问题