这应该是一个非常简单的：
在Windows Server 2008+上的高级 Windows 防火墙中，属性 > 高级，“边缘遍历”是什么意思？
当然，我在谷歌上搜索过，但无法给出具体的答案，尤其是在Thomas Schinder 的博客上看到以下内容时，我感到非常震惊：
Edge traversal 选项是一个有趣的选项，因为它没有很好的记录。以下是帮助文件中的内容：
“Edge traversal 这表示是否启用了边缘遍历（Yes）或禁用了（No）。启用边缘遍历后，应用规则的应用程序、服务或端口可全局寻址，并可从网络地址转换 (NAT) 或边缘设备外部访问。”
你认为这可能意味着什么？通过在服务器前面的 NAT 设备上使用端口转发，我们可以使服务跨 NAT 设备可用。这可能与IPsec有关吗？它可能与NAT-T有关吗？难道这个功能的帮助文件编写者也不知道，并且编造了一些代表同义反复的东西？
我不知道这是做什么的，但如果我发现了，我会确保将这些信息包含在我的博客中。
我很欣赏他的诚实，但如果这家伙不知道，谁知道呢？！
一旦机器位于路由器的另一端，我们就很难连接到 VPN，我想知道这是否有帮助？所以我非常渴望听到对“边缘遍历”的正确描述！
在这个问题的末尾添加了新的细节；我可能正在关注原因。
我有一个基于 UDP OpenVPN 的 VPN 设置tap模式（我需要，tap因为我需要 VPN 来传递多播数据包，这在tun网络中似乎是不可能的）与互联网上的少数客户端。我在 VPN 上经常遇到 TCP 连接冻结的情况。也就是说，我将建立一个 TCP 连接（例如一个 SSH 连接，但其他协议也有类似的问题），并且在会话期间的某个时刻，流量似乎将停止通过该 TCP 会话传输。
这似乎与发生大数据传输的点有关，例如我是否ls在 SSH 会话中执行命令，或者我是否cat是一个长日志文件。一些 Google 搜索在 Server Fault上找到了许多类似上一个这样的答案，表明可能的罪魁祸首是 MTU 问题：在高流量期间，VPN 试图发送数据包，这些数据包在两个管道之间的某处被丢弃VPN 端点。上面链接的答案建议使用以下 OpenVPN 配置设置来缓解问题：
fragment 1400
mssfix
这应该将 VPN 上使用的 MTU 限制为 1400 字节，并修复 TCP 最大段大小以防止生成任何大于该值的数据包。这似乎稍微缓解了这个问题，但我仍然经常看到冻结。我尝试了许多大小作为fragment指令的参数：1200、1000、576，所有结果都相似。我想不出两端之间有什么奇怪的网络拓扑结构会引发这样的问题：VPN 服务器运行在直接连接到 Internet的pfSense机器上，而我的客户端也在另一个位置直接连接到 Internet。
另一个奇怪的难题：如果我运行该tracepath实用程序，那么这似乎可以解决问题。示例运行如下所示：
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms …当使用client-to-client禁用的 TUN（第 3 层）OpenVPN 服务器时，我的客户端仍然可以相互通信。
根据文档，客户端到客户端的配置应该防止这种情况：
如果您希望连接客户端能够通过 VPN 相互联系，请取消注释客户端到客户端指令。默认情况下，客户端只能访问服务器。
为什么禁用此选项后客户端可以继续相互通信？
这是我的服务器配置：
port 443
proto tcp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh4096.pem
topology subnet
server 10.10.201.0 255.255.255.128
ifconfig-pool-persist ipp.txt
crl-verify /etc/openvpn/keys/crl.pem
push "route [omitted]"
push "dhcp-option DNS [omitted]"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so login
cipher AES-256-CBC
tls-auth /etc/openvpn/keys/pfs.key 0
verb 4
在 XP Pro 工作站中，有没有办法启动本机 Windows VPN 客户端并从命令行打开/关闭连接，以便可以在批处理文件中编写脚本？
Windows 用户有一个新的客户端“Juniper Pulse”来连接到 Juniper VPN 服务器。
在 Linux 上，我们必须以最大兼容性连接到该 Juniper VPN 的哪个 VPN 客户端？
请提及必须提供的必要参数。
我正在使用openconnect连接到 VPN。当以 启动客户端时sudo openconnect -v -u anaphory vpn-gw1.somewhere.net，我可以在输入 GROUP 和密码后连接。
# openconnect -v -u anaphory vpn-gw1.somewhere.net
[…]
XML POST enabled
Please enter your username and password.
GROUP: [Anyconnect-VPN|CLUSTER-DLCE|Clientless]:CLUSTER-DLCE
POST https://vpn-gw1.somewhere.net
Got HTTP response: HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
[…]
但是，当我在命令行上指定相同的组名时，连接失败并显示“无效主机条目”消息。
# openconnect -v -g CLUSTER-DLCE -u anaphory vpn-gw1.somewhere.net
[…]
XML POST enabled
Please enter your username and password.
Password:XML POST enabled
Invalid host entry. Please re-enter.
Failed to obtain WebVPN cookie
我是否需要对组名做任何魔术，或者我如何找出如何使其工作？
我无法找到有关如何设置strongswan 或openswan 以供iphone 的VPN 客户端使用的具体、最新信息。我的服务器在一个廉价的 linksys NAT 路由器后面。
我找到了这个，但它提到了一大堆 .pem 文件，但没有关于如何创建它们的参考。不幸的是，这两个软件包的“精美”手册对新手来说非常难懂且不友好。我之前设置过 OpenVPN 并设法很快获得了可用的结果，但是在阅读了一天半的过时文档后，我几乎不知道从哪里开始。
任何帮助将不胜感激！
我通过远程桌面连接到本地网络上的服务器。然后，我需要从该远程桌面会话中建立到 Internet 的 VPN 连接。但是，这会立即断开我的远程桌面会话。
这里发生了什么，有什么方法可以解决它？
额外的信息：
本地计算机 #1：
本地计算机 #2：
面向公众的 ADSL 路由器：
我可以毫无问题地从我的 PC 建立 VPN 连接（不涉及 RDP）。
汤姆建议在下面的评论中使用双网卡。我的盒子里有双网卡（上面的#2），但我不确定如何正确设置它们，或者如何分配 VPN 使用一个而不是另一个。
我尝试将额外的 NIC 设置在同一个专用网络 (10.1.1.200/24) 上，启动 VPN，然后尝试将 RDP 连接到 NIC 10.1.1.132 或 10.1.1.200，但没有任何运气。有什么方法可以告诉 VPN 使用一个网卡而不是另一个网卡吗？
根据要求 - 这是我来自 PC#2 的路由表：
在连接 VPN 之前：
IPv4 …我在我们公司的网络上有一台 Windows 7 PC（它是我们 Active Directory 的成员）。一切正常，直到我打开与客户站点的 VPN 连接。
当我连接时，我失去了对网络共享的网络访问权限，包括我们有文件夹重定向策略的“应用程序数据”等目录。可以想象，这使得在 PC 上工作变得非常困难，因为桌面快捷方式停止工作，软件由于从其下方拉出“应用程序数据”而停止正常工作。
我们的网络路由 (10.58.5.0/24)，其他本地子网存在于 10.58.0.0/16 的范围内。远程网络位于 192.168.0.0/24。
我已经将问题归结为与 DNS 相关的问题。一旦我打开 VPN 隧道，我所有的DNS 流量都会通过远程网络，这解释了本地资源的丢失，但我的问题是，我如何强制本地 DNS 查询转到我们的本地 DNS 服务器而不是我们的客户?
ipconfig /all未连接到 VPN 时的输出如下：
Windows IP Configuration
Host Name . . . . . . . . . . . . : 7k5xy4j
Primary Dns Suffix . . . . . . . : mydomain.local
Node Type . . . . . . . . . . . . …