我的办公室有一台服务器麦克风，通过VPN与远程服务器通信。 有一些似乎与MTU大小有关的各种问题。 Mike是RHEL 3服务器，客户服务器是CentOS 5.我使用tracepath工具尝试查找最大MTU并得到这个奇怪的结果 [root@mike root]# tracepath 192.168.1.4 1: mike (192.168.100.1) 0.170ms pmtu 552 1: mike (192.168.100.1) 0.011ms pmtu 552 1: mike (192.168.100.1) 0.010ms pmtu 552 snip – thousands of lines of the same output 1: mike (192.168.100.1) 0.025ms pmtu 552 1: 192.168.100.252 (192.168.100.252) 0.405ms 2: 192.168.100.253 (192.168.100.253) 0.876ms 3: 192.168.1.4 (192.168.1.4) 97.1000ms reached […]
我尝试在vps上设置openvpn，并且能够build立到服务器的连接，但网关没有分配给客户端。 这是我的configuration文件： 客户端configuration： client dev tun proto udp remote foo.bar 1194 resolv-retry infinite nobind persist-key persist-tun ca ca.crt cert client1.crt key client1.key ns-cert-type server redirect-gateway comp-lzo verb 3 pull 服务器configuration： port 1194 proto udp dev tun ca easy-rsa/2.0/keys/ca.crt cert easy-rsa/2.0/keys/server.crt key easy-rsa/2.0/keys/server.key dh easy-rsa/2.0/keys/dh2048.pem server 172.30.90.0 255.255.255.192 ifconfig-pool-persist ipp.txt push "redirect-gateway def1" push "dhcp-option DNS […]
我有OpenVPN的一个非常奇怪的问题。 大多数VPN工作正常，除了这一个。 在这里，我从TCP连接性能非常低，但CPU负载很低（所以，不是CPU问题）。 OpenVPNconfiguration了UDP，AES-256-CBC密码，SHA256authentication和不压缩。 这里是我用iperf做的一些测量： 没有VPN的networking连接： iperf -c external.ip result:300 – 500mbps (good) iperf -c vpn.int.ip result: 20-30mbps (not good) 两端的CPU使用率很低。 好的，也许一些ISP形状或过滤UDP数据包。 iperf -c external.ip -b 500M result: no packet loss 嗯…如果我强迫UDPstream槽VPN iperf -c vpn.int.ip -b 100M result: no packet loss iperf -c vpn.int.ip -b 180M result: packet loss ~0.1% 所以，根据UDP的结果，我的VPN连接应该达到180mbps，但是不会。 我也用tcptrace得到很奇怪的图。 这是好的testing（不使用VPN，使用外部IP）的方式： 如您所见，发送的数据包保持在黄线附近，这意味着接收窗口几乎保持满。 这部分graphics接近连接的开始，稍后，发送的数据包实际上位于黄线之上。 […]
我已经configuration了一个VPN服务器 local 192.168.0.250 dev tun proto udp port 1194 ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/server-vpn.crt key /etc/openvpn/easy-rsa/keys/server-vpn.key dh /etc/openvpn/easy-rsa/keys/dh1024.pem server 10.8.0.0 255.255.255.0 ifconfig 10.8.0.1 10.8.0.2 push "route 10.8.0.1 255.255.255.255" push "route 10.8.0.0 255.255.255.0" push "route 192.168.0.250 255.255.255.0" push "dhcp-option DNS 8.8.8.8" push "redirect-gateway def1" client-to-client duplicate-cn keepalive 10 120 tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 cipher AES-128-CBC comp-lzo user nobody […]
问题几乎说明了一切。 从我所发现的看来，1723港口似乎是主要的港口，但我也看到其他港口的许多参考。 承载VPN的服务器是Windows 2008 Server。
所以，我有一个build立的IPSec站点到站点隧道。 站点A有一个SonicWall，站点B有一个EdgeRouter。 第一条隧道由Site A的NATed ips到Site B的NATed ips组成。 一切都按预期工作。 接下来，我有一个公共的IP范围，站点B需要访问，但是请求需要看起来像是来自站点A.当我build立这个隧道时，我只能看到网关的stream量下降。 我无法访问这些ips。 由于它在局域网到局域网的configuration工作正常，我相信这可能是一个NAT问题 – 但我不确定，也不知道如何进一步诊断。 这可能是一个红鲱鱼，因为我不是很有信心…我曾尝试在VPN> WAN / WAN> VPN中放入“允许所有”规则，然后过滤到一个单独的IP，然后从站点B ping它。我看到丢包。 任何人都可以提供任何build议吗？
我有以下设置 2 x linode vps 1 x lab (physical) running 4 vps 我的目标是让所有的节点都像在同一个局域网上一样。 这将允许我改变IPTable规则，只允许本地stream量，而不必为每个需要访问目标节点端口的服务器添加一个新的IPTable条目。 我已经做了一些初步的研究和testing，似乎无法find我正在努力完成的最佳解决scheme。 在开始configuration实际生产VPS之前，我一直在使用位于不同子网上的两个实验室VPS进行实践。 实验机有两个物理的nics; eth0和eth1。 eth1被设置为为VPS提供虚拟nics的桥梁。 安装如下 service-a-1 (physical node): eth0: 192.168.0.1 eth1: br0 br0: 192.168.0.2 service-a-2 (vps): eth0: 192.168.0.3 eth0:0 10.0.0.1, 255.255.192.0 eth0:1 10.0.1.1, 255.255.192.0, gw 10.0.0.1 service-a-3 (vps): eth0: 192.168.0.4 eth0:0 10.0.64.1, 255.255.192.0 eth0:1 10.0.65.1, 255.255.192.0, gw 10.0.64.1 我使用192.168.0.x的 ip […]
我正尝试使用OpenVPN连接到服务。 有许多configuration文件（ .OVPN ）共享一个证书（ ca.crt ）; 全部位于相同的目录中。 Canada.ovpn，例如： client dev tun proto udp remote ca.#########.com 443 resolv-retry 5 nobind fast-io float tun-mtu 1500 tun-mtu-extra 32 mssfix 1450 persist-key persist-tun ca ca.crt auth-user-pass comp-lzo route-delay 5 30 script-security 3 system ping-restart 0 mute-replay-warnings verb 3 当我尝试连接时： sudo openvpn –config ./configs/canada.ovpn –auth-user-pass ./credentials.txt 我得到一个错误，内容如下： 选项错误：-ca以'ca.crt'失败：没有这样的文件或目录选项错误：请更正这些错误。 使用–help获取更多信息。 看来openvpn与相对path有着难度。 […]
我正在尝试连接两个AWS区域。 AWS的文档build议启动一个双方的实例来运行软件IPSec（OpenSWAN或StrongSWAN），为这两个实例提供一个弹性IP并将其用作隧道。 这一切都很好，但现在我们双方都有一个单一的失败点。 AWS在七月份发布了VPC连接指南 ，详细介绍了将两个VPC连接在一起的可能选项。 我已经将该PDF深入链接到了第15页，其中解释了选项。 它列出的每个选项都有明显的缺点，因为在大多数情况下，所有的stream量都是通过一个单独的（可被破坏的）实例。 到目前为止，似乎最好的select是在一侧使用软件隧道，而在另一侧使用虚拟专用网关。 他们说，至less你会在一方面得到冗余。 这似乎还不是最理想的。 有没有办法将两个虚拟专用网关连接在一起，这样我就可以两全其美了 – 亚马逊pipe理的冗余以及在VPCconfiguration中保留所有这一切的简单性？ 还是VGW本质上是客户端？
我想概念化如何networking在使用TUN接口的Linux VPN的底层工作。 我目前最好的猜测如下（请纠正我）： build立到远程客户端/服务器的连接。 TUN界面创build并提出 更新路由表以将默认网关设置为TUN接口 但是，到远程客户端/服务器的数据包不会进入TUN接口并形成一个循环？ VPN系统如何解决这个问题？ 我的理解有什么差距？