除非 OpenVPN 连接在 Mac OS X 上使用 pf.conf 处于活动状态，否则防止传出流量

Question

我已经能够拒绝所有与外部网络的连接，除非我的 OpenVPN 连接使用 pf.conf 处于活动状态。但是，如果通过关闭和打开笔记本电脑盖或关闭和重新打开 Wi-Fi 来断开连接，我将失去 Wi-Fi 连接。

• 我使用的是 Mac OS 10.8.1。
• 我通过 Wi-Fi（从不同位置，包括公共 Wi-Fi）连接到网络。
• OpenVPN 连接是使用 Viscosity 设置的。

我设置了以下数据包过滤规则 /etc/pf.conf

# Deny all packets unless they pass through the OpenVPN connection
wifi=en1
vpn=tun0

block all

set skip on lo
pass on $wifi proto udp to [OpenVPN server IP address] port 443
pass on $vpn

我用 启动包过滤服务sudo pfctl -e并加载新规则sudo pfctl -f /etc/pf.conf。

我还编辑/System/Library/LaunchDaemons/com.apple.pfctl.plist并更改了<string>-f</string>要读取的行，<string>-ef</string>以便数据包过滤器在系统启动时启动。

这一切一开始似乎都很好：如果 OpenVPN 连接处于活动状态，应用程序只能连接到网络，所以我从不通过不安全的连接泄漏数据。

但是，如果我关闭并重新打开笔记本电脑盖或关闭并重新打开 Wi-Fi，Wi-Fi 连接就会丢失，并且我会在状态栏中的 Wi-Fi 图标中看到一个感叹号。单击 Wi-Fi 图标会显示“警报：无 Internet 连接”消息：

要重新连接，我必须断开并重新连接 Wi-Fi，有时需要五到六次，然后“警报：无 Internet 连接”消息消失，我才能再次打开 VPN 连接。其他时候，Wi-Fi 警报自动消失，感叹号消失，我可以再次连接。无论哪种方式，重新建立连接可能需要五分钟或更长时间，这可能令人沮丧。

删除线路block all解决了问题（但允许不安全的连接），因此似乎我阻止了 Apple 需要的一项服务，以便重新获得和确认 Wi-Fi 连接。我试过了：

• 通过添加pass on $wifi proto icmp all到 pf.conf 来启用 icmp
• 通过添加启用 DNS 解析 pass on $wifi proto udp from $wifi to any port 53
• 试图通过记录被阻止的数据包（通过更改block all为block log all）来了解更多信息，但在 OS X 下似乎禁用sudo tcpdump -n -e -ttt -i pflog0了日志记录，因为查看日志会导致“tcpdump: pflog0: No such device exists”。

这些都无助于更快地重新建立 Wi-Fi 连接。

我还能做些什么来确定需要哪些服务才能重新获得 Wi-Fi 连接，或者我应该向 pf.conf 添加什么规则以使 Wi-Fi 重新连接更可靠？

Answer 1

通过使用 Little Snitch 监控网络连接，我发现 Apple 在后台使用 mDNSResponder 应用程序来检查 Wi-Fi 连接是否可用。mDNSResponder 将 UDP 数据包发送到名称服务器以检查连接性并将主机名解析为 IP。

更改我之前允许所有UDP 数据包通过 Wi-Fi的 UDP 规则允许 mDNSResponder 连接，这意味着 Wi-Fi 现在在断开连接后第一次重新连接。以防将来对其他人有帮助，我的最终 pf.conf 包括 Apple 对 Mountain Lion 的默认规则如下所示：

#
# com.apple anchor point
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"as
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"

#
# Allow connection via Viscosity only
#
wifi=en1 #change this to en0 on MacBook Airs and other Macs without ethernet ports
vpn=tun0
vpn2=tap0

block all

set skip on lo          # allow local traffic

pass on p2p0            #allow AirDrop
pass on p2p1            #allow AirDrop
pass on p2p2            #allow AirDrop
pass quick proto tcp to any port 631    #allow AirPrint

pass on $wifi proto udp # allow only UDP packets over unprotected Wi-Fi
pass on $vpn            # allow everything else through the VPN (tun interface)
pass on $vpn2           # allow everything else through the VPN (tap interface)

这意味着数据现在可以通过使用 UDP 协议的少数应用程序通过 Wi-Fi 泄漏，不幸的是，例如 ntpd（用于时间同步）和 mDNSResponder。但这似乎仍然比允许数据在不受保护的情况下通过 TCP 传输要好，这是大多数应用程序使用的。如果有人对改进此设置有任何建议，欢迎发表评论或进一步回答。

Answer 2

您不需要允许所有UDP。mDNS 中的“m”表示“组播”，它使用称为“链路本地组播地址”的特定组播目标 IP 地址和UDP端口号5353。

这意味着在您的上述解决方案中，您不必要地允许所有 65535 个 UDP 端口的流量绕过您的 VPN。您会惊讶于有多少应用程序使用 UDP，因此您在 VPN 关闭时阻止传出流量的最初想法大大违背了初衷。

为什么不改用这个规则：

pass on $wifi proto udp to 224.0.0.251 port 5353

防火墙配置的一个非常重要的经验法则 - 通过防火墙设置例外时，请始终尝试使用最具体的规则。特殊性有时是以牺牲便利性和易用性为代价的，即您可能会发现有一些其他的本地链路协议需要通过，并添加另一个特定的规则。

如果您交换上述规则并发现原来的 wifi 问题又回来了，那么您的 PF 可能阻止了 DHCP，该协议用于自动配置您的网络设备的 IP 地址。（在家庭网络中，通常您的宽带路由器将是您的 DHCP 服务器）。您需要允许 DHCP 的规则是：

pass on $wifi proto udp from 0.0.0.0 port 68 to 255.255.255.255 port 67

*注意：您可能需要替代0.0.0.0的any。DHCPREQUEST您的计算机首先发送的数据包具有源地址，0.0.0.0因为在那个阶段，您的计算机还没有 IP 地址。
老实说，我更倾向于使用any. 另一种选择是删除任何源规范，即pass on $wifi proto udp to 255.255.255.255 port 67，但这意味着我们失去了规则的源端口部分，并且尽可能具体始终是最安全的选择。

希望有帮助。以下是一些有用的链接：

mDNS：http : //en.wikipedia.org/wiki/Multicast_DNS#Packet_structure

DHSP：http : //en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_discovery