☰

如何在 OSX（BSD）上使用 pf 防火墙打开 OpenVPN 隧道外的服务器端口

tag-icon • tag-icon macos firewall routing openvpn pf
如何在 OSX（BSD）上使用 pf 防火墙打开 OpenVPN 隧道外的服务器端口

我有一台 Mac mini，我将其用作运行 XBMC 的媒体服务器，并将 NAS 中的媒体传输到我的立体声音响和电视（已使用 Spyder3Express 进行了颜色校准，很开心）。这台 Mac 运行 OSX 10.8.2，互联网连接通过 Tunnelblick 通过 OpenVPN 隧道传输，以保护一般隐私。我相信我的匿名 VPN 提供商将“redirect_gateway”推送到 OpenVPN/Tunnelblick，因为当它打开时，它会有效地将所有非 LAN 流量传输到出站和出站。但有一个不良副作用，那就是将盒子的服务器端口向外界开放，不受保护，并绕过我的防火墙路由器（Netgear SRX5308）。我已经在 VPN IP 上从 LAN 外部运行了 nmap，mini 上的服务器端口清晰可见且可连接。

mini 打开了以下端口：ssh/22、ARD/5900 和 8080+9090，用于 XBMC iOS 客户端 Constellation。

我还有一个 Synology NAS，除了通过 AFP 和 WebDAV 提供 LAN 文件服务外，它还为 WAN 提供 OpenVPN/1194 和 PPTP/1732 服务器。在 LAN 之外时，我通过 OpenVPN 从笔记本电脑连接到它，通过 PPTP 从 iPhone 连接到它。我只想通过 AFP/548 从 mini 连接到 NAS。

边界防火墙 (SRX5308) 运行良好，稳定，在从各种 VOD 服务流式传输时具有非常高的吞吐量。我的连接是 100/10，接近理论最大吞吐量。规则集如下

Inbound:
PPTP/1723        Allow always to 10.0.0.40 (NAS/VPN server)
                 from a restricted IP range matching the cell phone provider range
OpenVPN/1194     Allow always to 10.0.0.40 (NAS/VPN server) from any

Outbound: Default outbound policy: Allow Always
OpenVPN/1194     TCP Allow always from 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
OpenVPN/1194     UDP Allow always to 10.0.0.30 (mini) to a.b.8.1-a.b.8.254 (VPN provider)
Block always from 10.0.0.30 (mini) to any

在 Mini 上，我禁用了 OSX 应用程序级防火墙，因为它会弹出不记得我每次选择的弹出窗口，这对媒体服务器来说很烦人。相反，我运行 Little Snitch，它可以在应用程序级别很好地控制传出连接。我已配置出色的 OSX 内置防火墙 pf（来自 BSD），如下所示

配置文件（苹果应用防火墙插件已移除）

### macro names for external interface.
eth_if = "en0"
vpn_if = "tap0"
### wifi_if = "en1"
### %usb_if = "en3"

ext_if = $eth_if

LAN="{10.0.0.0/24}"

### General housekeeping rules ###
### Drop all blocked packets silently
set block-policy drop

### all incoming traffic on external interface is normalized and fragmented
### packets are reassembled.
scrub in on $ext_if all fragment reassemble
scrub in on $vpn_if all fragment reassemble

scrub out all

### exercise antispoofing on the external interface, but add the local
### loopback interface as an exception, to prevent services utilizing the
### local loop from being blocked accidentally.
### set skip on lo0
antispoof for $ext_if inet
antispoof for $vpn_if inet

### spoofing protection for all interfaces
block in quick from urpf-failed

#############################

block all

### Access to the mini server over ssh/22 and remote desktop/5900 from LAN/en0 only
pass in on $eth_if proto tcp from $LAN to any port {22, 5900, 8080, 9090} 

### Allow all udp and icmp also, necessary for Constellation. Could be tightened.
pass on $eth_if proto {udp, icmp} from $LAN to any

### Allow AFP to 10.0.0.40 (NAS)
pass out on $eth_if proto tcp from any to 10.0.0.40 port 548

### Allow OpenVPN tunnel setup over unprotected link (en0) only to VPN provider IPs
### and port ranges
pass on $eth_if proto tcp from any to a.b.8.0/24 port 1194:1201 

### OpenVPN Tunnel rules. All traffic allowed out, only in to ports 4100-4110 (rtorrent)
### Outgoing pings ok
pass in on $vpn_if proto {tcp, udp} from any to any port 4100:4110
pass out on $vpn_if proto {tcp, udp, icmp} from any to any

那么我的目标是什么？上述设置能实现什么？（直到你告诉我其他的:)

1）对迷你/媒体服务器上上述端口进行完全 LAN 访问（包括通过我自己的 VPN 服务器）2）来自迷你/媒体服务器的所有互联网流量都是匿名的，并通过 VPN 进行隧道传输

3) 如果 mini 上的 OpenVPN/Tunnelblick 断开连接，则不会因为 pf 和路由器传出规则集而泄露任何信息。它甚至无法通过路由器进行 DNS 查找。

那么我有什么可隐瞒的呢？其实没什么，我只是一时兴起试图阻止通过 VPN 隧道进行端口扫描 :)

无论如何，这种设置运行完美，并且非常稳定。

问题终于出现了！

我想运行一个 minecraft 服务器，我将其安装在迷你服务器上的单独用户帐户 (user=mc) 上，以保持分区。我不希望通过匿名 VPN 隧道访问此服务器，因为通过该隧道进行的端口扫描和黑客攻击比通过我的常规 IP 进行的端口扫描和黑客攻击要多得多，而且我一般不信任 java。因此，我在迷你服务器上添加了以下 pf 规则：

### Allow Minecraft public through user mc
pass in on $eth_if proto {tcp,udp} from any to any port 24983 user mc
pass out on $eth_if proto {tcp, udp} from any to any user mc

And these additions on the border firewall:
Inbound: Allow always TCP/UDP from any to 10.0.0.30 (mini with mc server)
Outbound: Allow always TCP port 80 from 10.0.0.30 to any (needed for online account checkups)

这可以正常工作，但前提是 OpenVPN/Tunnelblick 隧道关闭。当隧道打开时，无法从 LAN 外部连接到 minecraft 服务器，而 LAN 内部的访问始终正常。其他一切都按预期运行。我相信 redirect_gateway 推送可能接近问题的根源，但我想保留该特定的 VPN 提供商，因为它具有出色的吞吐量、价格和服务。

解决方案？

我如何打开隧道外的 minecraft 服务器端口，以便它只能通过 en0 而不是 VPN 隧道使用？

我应该使用静态路由吗？但我不知道要连接哪些 WAN IP... 很困惑

您认为这种设置的安全性如何？您是否还有其他改进可以分享？

答案1

本文 ——似乎回答了你的核心问题。它解释了你如何忽略来自Redirect_Gateway Push您的 ISP。

忽略重定向网关

如果您以客户端身份运行 OpenVPN，而您使用的服务器使用推送“ redirect-gateway”，则您的客户端会将所有互联网流量重定向到 VPN。有时客户端不希望这样，但他们无法更改服务器的配置。本页解释了如何覆盖重定向网关，这样即使服务器要求，客户端也不需要重定向互联网。

方法一：忽略

有两个选项可用于忽略服务器推送的路由：

--route-noexec

不要自动添加或删除路由。而是使用环境变量将路由传递给 --route-up 脚本。

 --route-nopull

与 --client 或 一起使用时--pull，接受服务器推送的选项，但路由和 dhcp 选项（如 DNS 服务器）除外。在客户端上使用时，此选项可有效禁止服务器向客户端的路由表添加路由，但请注意，此选项仍允许服务器设置客户端 TUN/TAP 接口的 TCP/IP 属性。

方法 2：覆盖

在这里，我们将简单地添加覆盖的路由--redirect-gateway。这将与def1标志的--redirect-gateway工作方式非常相似。如果服务器使用标志或不def1使用选项--redirect-gateway（通过在连接时检查日志），情况可能会有所不同。请注意，这net_gateway是 openvpn 的内部变量，不需要更改为任何内容。如果您不知道您的服务器是否使用def1并且不想检查日志来弄清楚，只需假设他们确实使用def1并使用这 4 条路由。无论如何，这都会起作用。

def10.0.0.0/1-- 使用此标志通过使用和128.0.0.0/1而不是 来覆盖默认网关0.0.0.0/0。这样做的好处是可以覆盖但不会消除原始默认网关。如果服务器不使用，def1请将以下选项添加到客户端配置中：

route 0.0.0.0 128.0.0.0 net_gateway
route 128.0.0.0 128.0.0.0 net_gateway

如果服务器确实使用def1或者您不知道，请将以下选项添加到客户端配置中：

route 0.0.0.0 192.0.0.0 net_gateway
route 64.0.0.0 192.0.0.0 net_gateway
route 128.0.0.0 192.0.0.0 net_gateway
route 192.0.0.0 192.0.0.0 net_gateway

相关内容