Linux VPN 伪装 HOWTO：故障排除

5.1 测试

要测试 VPN 伪装

从您的 Linux 机器上启动 ISP 连接，并验证它仍然正常工作。
验证常规伪装仍然正常工作，例如，尝试从本地网络上的一台伪装机器浏览一个网站或访问一个 FTP 服务器。
PPTP：验证您已正确配置 PPTP 控制通道的伪装：尝试从 PPTP 客户端系统 telnet 到您的 PPTP 服务器的 1723 端口。不要期望看到任何东西，但是如果您收到超时或连接失败的错误消息，请查看您的 Linux 机器上的伪装规则，以确保您确实将来自 PPTP 客户端到 PPTP 服务器 TCP 端口 1723 的流量进行了伪装。
PPTP：尝试建立 PPTP 连接。我建议您也运行 RASMON（如果可用），因为这将为您提供有关连接状态的最少量信息。如果您第一次尝试就建立了 PPTP 连接，那么恭喜您！您完成了！
IPsec：尝试建立 IPsec 连接。

5.2 可能的问题

有几种情况可能会阻止 VPN 会话的建立。我们将从客户端到服务器再返回来逐一排查。我们将假设您使用基于 Windows 的客户端作为示例，因为这是最常见的情况。

连接信息：VPN 拨号配置中的“电话号码”必须是 VPN 服务器的 Internet IP 地址，或者如果服务器正在被伪装，则是防火墙的 IP 地址。
PPTP 和强加密：除非客户端和服务器都拥有 128 位的 NDISWAN.SYS 或 W'95/'98 PPTP 软件，否则您将无法建立强加密会话。不幸的是，根据我的经验，这个问题不会产生任何明显的错误消息，它只是不断地尝试、尝试、再尝试... 强加密更新可以从“配置 MS 客户端”部分中给出的 Microsoft 安全站点 URL 获取。
如果 IPsec 客户端使用 MS 提供的加密库而不是使用自己的库，这也可能会影响 IPsec 客户端。
路由：验证您的 VPN 客户端上的默认路由是否指向 Linux 伪装机器。运行 route print 命令并查找 0.0.0.0 条目。
如果其他伪装服务（例如 HTTP、FTP、IRC 等）从您的 VPN 客户端系统工作正常，那么这可能不是问题所在。
伪装：VPN 会话分为两个部分。
对于 IPsec，身份验证和密钥交换服务 (ISAKMP) 是到远程 IPsec 主机的 500 端口的正常 UDP 会话，必须配置为像任何其他 UDP 服务（例如 DNS）一样进行伪装。
对于 PPTP，控制通道是到 PPTP 服务器的 1723 端口的正常 TCP 会话，必须配置为像任何其他 TCP 服务（例如 HTTP）一样进行伪装。
IPsec 中的加密数据通道通过 ESP（IP 协议 50）传输。PPTP 中的加密数据通道通过 GRE（IP 协议 47）传输。（请注意，这些不是 TCP 或 UDP 端口号！）由于 2.0 Linux 内核只允许您在创建伪装规则时指定 TCP、UDP、ICMP 和 ALL IP 协议，如果您仅伪装特定服务，则还必须伪装 ALL 协议流量。如果您伪装所有内容，则无需担心这一点。
为了将防火墙规则与内核伪装代码隔离，请尝试在防火墙完全打开的情况下建立 VPN 连接，如果它工作正常，则收紧防火墙规则。
2.0.x ipfwadm 完全打开防火墙
```
ipfwadm -I -p accept
ipfwadm -O -p accept
ipfwadm -F -a accept -m
```
2.2.x ipchains 完全打开防火墙
```
ipchains -P input   ACCEPT
ipchains -P output  ACCEPT
ipchains -P forward MASQ
```
不要让您的防火墙完全打开的时间超过证明可以建立伪装 VPN 连接所需的时间！
中间跃点和 Internet：您的 Linux 防火墙和远程 IPsec 主机之间的所有路由器都必须转发携带 IP 协议 50 的数据包。您的 Linux 防火墙和 PPTP 服务器之间的所有路由器都必须转发携带 IP 协议 47 的数据包。如果当您的 VPN 客户端系统直接拨号连接到您的 ISP 时，IPsec 或 PPTP 工作正常，那么这可能不是问题所在。
为了隔离中间跃点是否阻止 GRE 流量，请使用已修补的 traceroute 来跟踪 GRE 数据包的进度。有关 traceroute 补丁的信息，请参阅资源部分。ESP 的类似补丁正在开发中。
远程防火墙：服务器端的防火墙必须允许具有您的 ISP 分配给您的 Linux 机器的 IP 地址的系统连接到 IPsec 主机上的 500/udp 端口或 PPTP 服务器上的 1723/tcp 端口。如果当您的 VPN 客户端系统直接拨号连接到您的 ISP 时，VPN 工作正常，那么这可能不是问题所在。
服务器防火墙和 ESP：IPsec 加密数据通过 IP 协议 50 传输。如果远程 IPsec 主机后面的防火墙不双向转发 ESP 流量，则 IPsec 将无法工作。同样，如果当您的 IPsec 客户端系统直接拨号连接到您的 ISP 时，IPsec 工作正常，那么这可能不是问题所在。
服务器防火墙和 GRE：PPTP 数据通道作为 GRE 封装的（IP 协议 47）PPP 会话传输。如果您的 PPTP 服务器后面的防火墙不双向转发 GRE 流量，则 PPTP 将无法工作。同样，如果当您的 PPTP 客户端系统直接拨号连接到您的 ISP 时，PPTP 工作正常，那么这可能不是问题所在。
补丁：如果您的 IPsec 客户端成功验证了您的身份，但无法建立网络连接，则该补丁可能没有正确伪装 ESP 流量。如果您的 PPTP 客户端建立了控制通道（RASMON 发出哔哔声，小电话灯亮起）并发送 GRE 流量（RASMON 中的上部灯闪烁），但没有收到 GRE 流量返回（RASMON 中的下部灯没有响应闪烁），则该补丁可能没有正确伪装 GRE 流量。
查看 /var/log/messages 以查找显示 VPN 流量被看到的日志条目。启用 VPN 调试可能有助于您确定补丁是否是故障原因。还要在您的互联网连接上运行嗅探器，并查找出站 VPN 流量（见下文）。
多个客户端：较旧的 PPTP 补丁不支持伪装多个尝试访问同一 PPTP 服务器的 PPTP 客户端。如果您尝试这样做，您应该查看您的网络设计，并考虑是否应该为您的本地客户端设置 PPTP 路由器。2.0 补丁包含了呼叫 ID 伪装，这允许多个并发会话。注意：如果您正在伪装 PPTP 服务器，请不要启用 PPTP 呼叫 ID 伪装。目前，这将阻止服务器的出站流量被伪装。

5.3 故障排除

大多数问题可以通过在您的 VPN 防火墙上运行数据包嗅探器（例如，带有 -v 选项的 tcpdump）来定位。如果一切工作正常，您将看到以下流量

客户端本地网络
IPsec：从您的 IPsec 客户端本地 IP 到远程 IPsec 主机的 Internet IP 的 UDP（目标 UDP 端口 500）和 ESP（IP 协议 50）流量。如果您没有看到这个，您的 IPsec 客户端配置错误。
PPTP：从您的 PPTP 客户端本地网络 IP 到 PPTP 服务器的 Internet IP 的 TCP（目标 TCP 端口 1723）和 GRE（IP 协议 47）流量。如果您没有看到这个，您的 PPTP 客户端配置错误。
客户端防火墙的 ISP 侧：从客户端防火墙 Internet IP（记住 - 我们正在伪装）到 VPN 服务器的 Internet IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您没有看到这个，您的伪装配置错误或补丁没有工作。
服务器防火墙的 ISP 侧：从客户端 Internet IP 到 VPN 服务器的 Internet IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您没有看到这个，互联网已关闭 :) 或某些中间设备正在阻止 ESP 或 GRE 流量。
服务器防火墙的边界网络 (DMZ) 侧：从客户端互联网 IP 到服务器 IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您没有看到这个，请检查您的防火墙规则，以转发 UDP 端口 500 和 IP 协议 50 或 TCP 端口 1723 和 IP 协议 47，以及 ipportfw 和 ipfwd 的配置（如果您正在伪装服务器）。
服务器防火墙的边界网络侧：从 VPN 服务器 IP 到客户端互联网 IP 的 UDP（源端口 500）和 ESP 或 TCP（源端口 1723）和 GRE 流量。如果您没有看到这个，请检查 VPN 服务器配置，包括 VPN 服务器上的数据包过滤规则。
服务器防火墙的 ISP 侧：从 VPN 服务器 IP（或防火墙 IP，如果服务器被伪装）到客户端互联网 IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您没有看到这个，请检查您的防火墙规则，以转发 UDP 端口 500 和 IP 协议 50 或 TCP 端口 1723 和 IP 协议 47。
客户端防火墙的 ISP 侧：从 VPN 服务器 IP 到客户端防火墙互联网 IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您没有看到这个，互联网又出问题了。
客户端本地网络：从 VPN 服务器互联网 IP 到 VPN 客户端本地网络 IP 的 UDP 和 ESP 或 TCP 和 GRE 流量。如果您看到 UDP 流量但没有看到 ESP 流量，或者看到 TCP 流量但没有看到 GRE 流量，则补丁没有工作或未正确安装。

您可能会发现启用 VPN 调试并重新编译您的内核很有帮助。将以下内容添加到 /etc/syslog.conf

# debugging
*.=debug           /var/log/debug

并查看 /var/log/messages 和 /var/log/debug 以查找有关 VPN 流量的日志消息。请注意，日志记录 - 尤其是详细日志记录 - 将导致大量的磁盘活动，并导致日志文件快速增长。除非您需要，否则不要启用调试，并在完成后将其关闭。

5.4 MS PPTP 客户端和域名问题

感谢 Charles Curley <ccurley@trib.com> 提供以下信息

如果您使用 PPTP（点对点隧道协议）访问 Microsoft 网络 (SMB) 环境，并且在您的本地私有网络（Samba 或 Windows）中拥有自己的 Microsoft 网络环境，请为您的本地工作组命名一个不会在远程环境中显示出来的名称。原因是当您的 PPTP 客户端登录到远程环境时，它将看到远程环境的域名服务器，并且只会看到该工作组中的远程计算机。
您应该避免偷懒的选项。Microsoft 出厂的 Windows 默认工作组名称设置为 WORKGROUP。有些人会偷懒，并在设置计算机时接受 WORKGROUP 作为他们的工作组。因此，远程环境很可能有一个名为 WORKGROUP 的工作组，无论管理员是否愿意。

我认为这适用于任何 VPN，因为名称服务不依赖于传输。如果您的客户端可以看到远程网络上的 WINS 服务器，那么您可能会遇到这种情况，无论是否使用 PPTP。

5.5 MS PPTP 客户端和 Novell IPX

如果您在使用 PPTP 链接上的 IPX 流量时遇到问题，请参阅此 MS 知识库文章中的 3.5 和 5.2 节：http://microsoft.com/ntserver/nts/downloads/recommended/dun13win95/ReleaseNotes.asp

相同的考虑可能也适用于 Win'98。

感谢 David Griswold <dgriswol@ix.netcom.com>

5.6 MS 网络密码问题

当您使用 VPN 访问 MS 网络时，您应该记住，您将必须提供两个不同的身份验证令牌 - 一个用于连接到 VPN 服务器（VPN 密码），另一个用于在连接建立后访问远程网络上的资源（网络密码）。

VPN 密码 - 您在启动与 VPN 服务器的呼叫时输入到 VPN 客户端中的用户名和密码 - 仅由 VPN 服务器用于授予您通过 VPN 连接到网络的权限。一旦您连接上，它将不再用于任何其他用途。

VPN 密码不用于向远程网络上的其他计算机证明您的身份。您必须为此提供另一对用户名/密码 - 您的网络密码。

有两种方法可以提供网络密码。您的网络密码可能与您在启动计算机时登录到本地网络时提供的用户名/密码对相同。如果它不同，您可以配置您的 VPN 客户端，以便在 VPN 连接建立后，要求您提供远程网络的网络密码。

如果您成功连接到 VPN 服务器，但无法访问远程网络提供的任何资源，那么您没有为远程网络提供有效的网络用户名/密码对。验证您本地网络的用户名和密码是否也适用于远程网络，或者将您的 VPN 客户端设置为提示您输入在远程网络上使用的用户名和密码，并在 VPN 连接建立后“登录”到远程网络。

5.7 如果您的 IPsec 会话总是在一定时间后死亡

如果您在使用 IPsec 隧道时经常遇到隧道定期断开的问题，特别是如果检查防火墙上的系统日志显示看到带有“零 cookie”值的 ISAKMP 数据包，那么这就是正在发生的事情

早期版本的 IPsec Masq 补丁没有更改 ISAKMP UDP 数据包的 masq 表条目的超时时间。ISAKMP UDP 流量的 masq 表条目会相对较快地（相对于数据通道）超时并被删除；如果远程 IPsec 主机随后决定在本地 IPsec 主机之前启动重新密钥，则用于重新密钥的入站 ISAKMP 流量将无法路由到伪装主机。重新密钥流量将被丢弃，远程 IPsec 主机会认为链接已失败，并且连接最终将被终止。

2.0.x 补丁已从其原始版本修改，以增加 ISAKMP UDP masq 表条目的超时时间。获取当前版本的补丁，该补丁可通过资源部分中给出的站点获得，并重新打补丁并重新编译您的内核。

还要验证您的 IPsec Masq 表生存期参数配置为与您的重新密钥间隔相同或稍长。

5.8 如果 VPN 伪装在您重新启动后无法工作

如果您将 VPN Masq 支持编译为模块，您是否记得将 modprobe ip_masq_pptp.o 或 modprobe ip_masq_ipsec.o 命令放入您的 /etc/rc.d/rc.local 启动脚本中？

5.9 如果您的第二个 PPTP 会话杀死了您的第一个会话

PPTP RFC 规定，在两个系统之间可能只有一个控制通道。这可能意味着一次只有一个伪装客户端能够联系给定的 PPTP 服务器。有关更多详细信息，请参阅 multiclientpptp。