Reading view

There are new articles available, click to refresh the page.

【立此存照】湖北一日两起翻墙处罚:一人罚200元一人罚500元

3月11日,湖北省接连曝出两起因使用VPN翻墙被处罚的事件。在鄂州市,一名男子因使用翻墙软件浏览TikTok和X(原Twitter),被梁子湖区公安局处以200元罚款。同日在孝感市,孝南区公安局新华派出所出动十余名警力,查处一名使用VPN访问境外网站的网民,对其处以500元罚款。

以下为推特用户@李老师不是你老师 发布的相关爆料截图:

CDT 档案卡
标题:【立此存照】湖北一日两起翻墙处罚:一人罚200元一人罚500元
作者:中国数字时代
发表日期:2025.3.18
来源:网络
主题归类:翻墙
CDS收藏: 版权说明:该作品版权归原作者所有。中国数字时代仅对原作进行存档,以对抗中国的网络审查。详细版权说明

3月11日,湖北省鄂州市,一男子因使用翻墙软件,浏览Titok和X被梁子湖区公安局罚款200元。

file

根据湖北公安执法公开平台,徐某在家中,未经批准擅自使用一部荣耀手机通过“Clash”软件进行国际联网,浏览并使用境外软件“Titok”及“X”,许某的行为已构成未经批准擅自进行国际联网,根据《中华人民共和国计算机信息网络国际联网管理暂行规定》第六条、第十四条之规定,现决定给予许某处以警告并处罚款200元的行政处罚。执行方式和期限:责令被处罚人停止联网,被处罚人自收到行政处罚决定书之日起十五日内到鄂州市农村商业银行梁子湖区支行缴纳罚款。

3月11日,湖北省孝感市,孝南区公安局新华派出所出动十余名警力,查处一名使用VPN访问境外网站的网民,对其处以500元罚款。

file

根据孝感市公安局孝南分局行政处罚决定书:2026年1月28日上午10时许,新华派出所等十余名警力集中行动,在孝南区长征南路乾坤新城4号楼5楼512室,成功捣毁已擅自接入非法信息进行国际联网非法注册使用VPN"翻墙软件"访问境外网站进行国际互联网的活动。违反法规:《中华人民共和国计算机信息网络国际联网管理暂行规定》第六条、第八条第一款、第十条、第十四条。处罚决定:警告并处伍佰元罚款(500元)。须在收到决定书起十五日内到指定的中国邮政储蓄银行孝感支行缴纳罚款。

相关阅读:【网络民议】《网络犯罪防治法》是新时代的“翻墙罪”吗?

1月31日,公安部发布《网络犯罪防治法(征求意见稿)》,向社会公开征求意见。该法案共有七章六十八条,涵盖网络基础资源管理、网络犯罪生态治理、网络犯罪防治义务等内容。它虽以“有效遏制网络犯罪源头、整治网络犯罪生态”为名,却在网民当中引发了一定的恐慌——因为条文中对“境外支付账户”和“翻墙工具”做出了前所未有的新规定新限制,且适用对象覆盖境外与境内的中国公民。

IPinfo 关于 20 家主流匿名服务平台的真实位置报告

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

IPinfo 对全球 20 款主流匿名服务进行了大规模基准测试,结果令人震惊:17 款匿名服务的流量出口与其宣称的国家不符。绝大多数所谓的“全球覆盖”实际上是将流量路由至美国或欧洲的少数几个数据中心。如果你依赖匿名服务规避地理限制或寻求特定司法管辖区的保护,你的流量可能正暴露在你最想避开的地方。

“100+ 国家”的营销谎言
许多匿名服务提供商声称拥有遍布全球的服务器网络,但通过对 150,000+ 出口 IP137 个国家 的交叉比对,事实并非如此:

下表展示了匿名服务提供商宣称的国家数量与实际测得的“虚拟/不可测”比例。
注:百分比越高,代表其宣称的“物理位置”含水量越大。

💡 专家注:Mullvad、IVPN 和 Windscribe 实现了 0% 的错位。这并不意味着它们覆盖最广,但意味着它们最诚实——所见即所得

当你在匿名服务App 中点击“🇧🇸 巴哈马”时,你以为流量进入了加勒比海。实际上,流量可能从未离开过美国迈阿密。

运作机制:

为何要这么做?

现象:NordVPN, ExpressVPN, PIA 等 5 家提供商均提供“巴哈马”节点。
真相:所有流量实测均位于美国
证据:从美国迈阿密发起的探测,RTT(往返时延)仅为 0.15ms – 0.42ms
物理常识:光速不可能在 0.2ms 内完成跨海往返。这证明服务器就在探测点隔壁(迈阿密)。

现象:NordVPN 和 ProtonVPN 声称提供索马里摩加迪沙(Mogadishu)节点。
真相:实际位于法国英国
风险:用户可能为了特定的非洲地缘需求连接,却被路由到了欧洲监控体系下。

为什么很多 IP 查询工具也会显示错误位置?
因为传统数据库(Legacy IP Datasets)依赖**“自述数据”(Self-reported data)**。如果匿名服务服务商在 WHOIS 信息里填了“索马里”,由于没有主动验证机制,传统数据库就会盲目采信。

误差有多大?
IPinfo 将其实测数据与传统数据库对比:

可视化证据:
ProtonVPN 的某个 IP,传统数据库认为是 🇲🇺 毛里求斯,ProbeNet 实测是在 🇬🇧 英国(距离偏差 9691 公里)。

这为何是一个严重问题?
虽然虚拟定位在工程上有其合理性(如在缺乏基础设施的地区提供服务),但核心问题在于透明度

✅ 最佳实践方案 (Actionable Advice)

本次调查采用了**“测量优先”(Measurement-first)**的工程方法,而非依赖文档。

注:本报告采取了保守统计,仅统计了明确的国家级错位。如果计入城市级错位,数据将更加惊人。

IPinfo 关于 20 家主流匿名服务平台的真实位置报告

DUN.IM BLOG

DUN.IM BLOG

我们还年轻,可不想看到这个世界处在毫无自由、隐私的边缘。

IPinfo 的深度审计揭露,17/20 (85%) 的主流匿名服务声称的服务器位置与实际物理位置不符,实际流量出口位置也存在差异。部分服务商的错误位置超过 40 个,而且超过 8000 个 IP 地址与第三方数据集的定位不符。这些被称为虚拟服务器,大多数匿名服务商都或多或少存在这种情况。

这些厂商不愿多花成本在目标的物理地区部署实体服务器,转而选择在成本更低廉的地区架设服务器,仅通过技术手段给 IP 地址贴上任意国家的虚拟标签。

照此逻辑,任何人都完全可以在香港、日本或美国某数据中心租用 195 台服务器,为每台配置不同国家的 IP 标签,就能宣称服务覆盖全球所有国家。

听起来很荒谬,但这恰恰是许多匿名服务的运营方式。这只是为提升官网数据、促进销售的手段。

不要盲目信任服务宣称的地区。如果你是为了规避审查或保护人身安全,必须假设所有节点都是不可信的,并应通过测试验证物理距离。

DUN.IM 拥有实际国家或地区物理服务器数量为 68 个 (最新数据会随着时间变化) ,连接指定区域时,数据流真正抵达的就是该国家。相较于其他提供商,我们自信为用户提供了实际国家区域覆盖范围最广的匿名服务。

我们希望能帮助大家了解到一些自身权益和隐私相关的信息。DUN.IM 始终坚持公开和真诚,所有宣传都力求准确。

我们还年轻,可不想看到这个世界,处在毫无自由、隐私的边缘

IPinfo 发现20 款热门匿名服务中有 17 款流量出口位置与其宣称的国家不符。尽管部分服务商声称拥有覆盖“100 多个国家”的服务器网络,但数据表明,其中许多流量实际上指向了位于美国或欧洲的少数几个物理数据中心。

这意味着,绝大多数匿名服务商并没有按照他们承诺的国家区域路由你的流量,其实际支持的国家数量远少于营销宣传。

通过分析遍布 137 个潜在出口国家的超过 150,000 个出口 IP 地址,并将服务商的宣称与 IPinfo 的实测数据进行对比, IPinfo 得出了以下结论:

本报告将详细梳理 IPinfo 在匿名服务和 IP 数据服务商中观察到的现象,深入剖析两个极具代表性的国家案例,探讨为何基于实测的 IP 数据对于流量溯源至关重要,并公开 IPinfo 的调查方法。

下图展示了各匿名服务商宣称的国家数量与 IPinfo 在实际流量中测得的国家数量之间的重合度。百分比越低,表示该服务商的宣称列表与 IPinfo 的实测数据越吻合:

注:为了确保服务商之间的比较尽可能公平,并获得足够的数据进行分析, IPinfo 在研究中使用了最通用和广泛支持的技术。但这可能并不代表每个服务商的全部覆盖范围。

这些都是匿名服务行业中最著名的平台,它们的网站上通常列有长长的国家列表。仅有三家在 IPinfo 测试的所有国家中均未发现不匹配物理位置情况:Mullvad、IVPN 和 Windscribe

国家位置的不匹配意味着:如果你选择某个匿名服务,是因为它宣称覆盖“100+ 国家”,你需要知道,这些区域中有很大一部分不是真实物理位置所在,即“虚拟位置”。

当匿名服务允许你连接到例如“巴哈马”或“索马里”时,意味着流量并不真的经过那里。在许多情况下,服务器位于完全不同的地方,比如迈阿密或伦敦,但在界面上却显示为你的流量位于你选择的国家。

这种设置被称为虚拟位置(Virtual Location):

如果没有主动的网络测量,大多数 IP 数据库只能依赖 IP 所有者自行通知互联网注册机构,或在 WHOIS/Geofeeds 中发布信息:这是一个自述的国家标签。如果该记录是错误的或过时的,错误就会广泛传播。

这正是 IPinfo 的 ProbeNet 发挥作用的地方:通过从全球 1,200 多个接入点运行实时的 RTT(往返时间)测试, IPinfo 将每个 IP 锚定到其现实世界的物理位置,而不仅仅是它宣称的位置

在整个数据集中, IPinfo 发现有 97 个国家 至少在某一家匿名服务品牌中仅作为虚拟位置出现,或者无法在 IPinfo 的数据中测量到。换句话说,对于世界地图上相当大的一部分,匿名服务平台中的某些“位置”,从未在 IPinfo 的测量中显示为真实的出口。

IPinfo 还发现 38 个国家 的情况更为极端:至少有一家匿名服务宣称支持这些国家,但在 IPinfo 的样本中,没有任何一家服务商在这些国家产生过稳定、可测量的出口流量。

你可以将这 38 个国家视为本研究中的“不可测量”区域,它们存在于服务器列表、配置文件和 IP 地理位置信息流中,却从未作为实际的出口国家出现在 IPinfo 的测量中。它们并非随机分布,而是集中在地图的特定区域。按区域划分如下:

IPinfo 关于 20 家主流匿名服务平台的真实位置报告

这并不能证明这些国家在全球范围内完全没有匿名服务基础设施。但这确实表明,在 IPinfo 测量的服务商和位置中,主流模式是从其他地方为这些位置提供服务。

为了更具体地说明这一点,让 IPinfo 看看在 IPinfo 的数据集中,所有服务商都显示为虚拟位置的两个国家:巴哈马索马里

在 IPinfo 的测量中,有五家服务商提供标为“巴哈马”的节点:NordVPN、ExpressVPN、Private Internet Access、FastVPN 和 IPVanish

对于所有这些服务商,实测流量均位于美国,且通常与美国探测点的 RTT(往返延迟)都在亚毫秒级(小于 1ms)。

索马里仅出现在两家服务商的样本中:NordVPN 和 ProtonVPN

两家都在命名中明确标注了“摩加迪沙”,但这些 RTT 数据完全符合西欧流量的特征,与东非的流量特征完全不符。

尽管两家服务商都在标签上做足了功夫(例如“SO, Mogadishu”),但实际流量却位于尼斯伦敦,而非索马里。

到目前为止, IPinfo 讨论的是匿名服务的宣称与 IPinfo 实测数据的对比。但其他 IP 数据服务商通常不运行主动的 RTT 测试。它们依赖于自述的 IP 数据源,并通常假设如果一个 IP 被标记为“X 国”,那它一定就在那里。

在这些情况下,传统的 IP 数据库通常会“追随”匿名服务商的说辞:如果匿名服务将端点营销为 X 国,传统 IP 数据库也会将其放置在 X 国。

为了量化这一点, IPinfo 查看了 736 个匿名服务出口节点,其中 ProbeNet 的实测国家与一个或多个广泛使用的传统 IP 数据库不一致。

IPinfo 将 IPinfo ProbeNet 测得的国家(由 RTT 和路由支持)与其他 IP 数据库报告的国家进行比较,并计算了它们之间的距离。差距是巨大的:

ProbeNet 与传统数据集之间的中位误差约为 3,100 公里

在 ProbeNet 方面, IPinfo 拥有更强有力的延迟证据证明 IPinfo 测量的位置是正确的:

这正是当流量真正位于该国时你应该看到的数据,而不是相隔数千公里。

如果你能在一个具体的 IP 上看到这种行为,它会变得更加直观。

这是一个 匿名服务的出口 IP,ProbeNet 将其服务器定位在英国,且有本地探针的亚毫秒级 RTT 支持;而其他广泛使用的传统 IP 数据库将同一个 IP 定位在 9,691 公里之外的毛里求斯

🇬🇧 英国 vs 🇲🇺 毛里求斯 (ProtonVPN)

如果你想亲自验证,可以将该 IP 输入到像 ping.sx 这样的公共测量工具中,从不同地区运行 Ping 或 Traceroute。这类工具可以直观地展示延迟最低的位置。

ProbeNet 使用相同的基本原理,但在规模上有所不同: IPinfo 在全球维护着 1,200 多个观测点(PoP),因此 IPinfo 通常比网络较小的公共工具更能接近真实的物理位置。

如果你想体验更多真实的 IP 案例(不一定是 VPN),即 ProbeNet 和 IPinfo 定位正确而其他数据库错误的情况,可以在 IPinfo 的 IP 地理位置准确性页面找到更完整的示例集。

值得将技术原因与信任问题区分开来。使用虚拟或集中式基础设施确实存在技术上的合理性

从这个角度来看,虚拟位置可以是一种合理的妥协:你获得了区域性的 IP 和内容解锁能力,而服务商无需承担在脆弱环境中托管的负面影响。

有三件事改变了性质:

最后一点直接引出了 IPinfo 致力于解决的 IP 数据问题。

如果你是匿名服务用户,以下是本次研究的一些实用建议:

归根结底,这并不是反对匿名服务,甚至不是反对虚拟位置。这是对诚实和证据的呼吁。如果匿名服务商希望你信任那张区域位置地图,他们应该愿意并且能够证明它与底层的真实网络相符。

大多数传统 IP 数据提供商依赖于区域互联网注册管理机构(RIR)的分配数据,以及围绕路由和地址块的启发式方法。这些提供商通常会接受自述数据,如客户反馈、更正和 Geofeeds,而没有明确的验证方法。

IPinfo 采用测量优先的方法:

这种测量优先的方法在 IP 数据领域是独特的。一旦 IPinfo 意识到自述数据带来了多少不准确性, IPinfo 就开始大力投资研究并构建 ProbeNet,以大规模使用主动测量。 IPinfo 的目标是使 IP 数据尽可能基于证据,并通过观察互联网的实际行为进行验证。

IPinfo 像一个怀疑但技术资源充足的用户一样,处理这项匿名服务调查:从匿名服务自己的宣称开始,然后测试它们。

对于 20 家匿名服务商中的每一家, IPinfo 汇总了三类数据:

接下来, IPinfo 使用 IPinfo 基础设施和 ProbeNet 拨入这些位置并观察实际发生的情况:

现在 IPinfo 对每个位置有了两个视图:

对于每个明确指定了国家的位置, IPinfo 要问一个非常简单的问题:预期国家与实测国家是否匹配?

如果是, IPinfo 将其计为匹配。如果不是,它就变成了不匹配:即应用程序说是一个国家,但流量在其他地方流出。

IPinfo 特意使用了非常狭义的“不匹配”定义。要计入不匹配,必须满足两个条件:服务商必须明确宣称特定国家(在其网站、应用程序或配置中),并且 IPinfo 拥有 ProbeNet 对该位置背后出口 IP 的直接主动测量数据。

IPinfo 忽略了任何营销模棱两可的位置、 IPinfo 未直接测量到出口的位置,或者 IPinfo 只有较弱提示(如主机名字符串、注册数据或第三方 IP 数据库)的位置。这些信号可能是有用且真实的,但 IPinfo 希望 IPinfo 的数字尽可能无懈可击。

结果是, IPinfo 在此展示的不匹配率是保守的如果采用更宽松的方法并依赖那些额外的提示,数字几乎肯定会更高,而不是更低。

微型 VPN

(Abstract)对于只能暴露 SSH 端口、不能开放其他端口的设备来说,想要通过它进行 VPN 服务的话,SOCKS 代理是一个不错的选择,但是要注意安全。我总结出了一套组合方案:PAC 文件放公网 URL,而 SOCKS 代理地址使用内网,做到效率和安全两不误。

在 VPN 场景下的跨子网通信防火墙配置方法

这篇文章介绍手搓 Site-to-Site 组网的方法。

1 场景简述

假设我们有两个机器 A 与 B,其中 A 和 B 在各自的局域网中的网段分别是 192.168.2.0/24 和 192.168.3.0/24。A 和 B 都接入了一个 VPN 网络,其内网地址是 10.0.0.0/16。那么,如何让 A 访问 B 所在局域网内的另一台机器 C 呢?注意 C 是没有接入到 VPN 私有网络的。一个办法是直接让 C 也接入到 VPN 网络中,但是如果 B 的局域网中有众多设备需要被 A 访问时,将这些节点都加入 VPN 网络配置会非常麻烦。在一些场景下,VPN 的连接数量有限制(例如 Zerotier)。因此我们需要新的方案。这篇文章我们介绍通过巧妙地配置路由表和防火墙来实现。

我们假定 A 的地址是 192.168.2.2/24 和 10.0.0.2/16,B的地址是 192.168.3.2/24 和 10.0.0.3/16,C 的地址是 192.168.3.3/24。我们这里介绍的是让 A 访问 B 所在的子网。反过来让 B访问 A的子网的设置方法是类似的。进行双向设置以后就可以实现完整的 Site-to-Site 组网。这里我们假设 A 和 B 都安装了 Ubuntu 操作系统。

2 路由配置

首先我们需要进行路由表的配置,让 A 知道应该以 B 为网关来来访问 192.168.3.0/24 子网。在 A 上运行

1
sudo ip route add 192.168.3.0/24 via 10.0.0.3

然后,我们需要在 B 上启用 IP 转发。在Linux系统中开启IP转发功能,可以通过以下步骤:

  1. 临时开启(系统重启后失效)
    • 对于基于Debian或Ubuntu的系统,可以使用以下命令:
      • 查看当前IP转发状态:cat /proc/sys/net/ipv4/ip_forward,如果输出为0,则表示IP转发功能是关闭的;如果输出为1,则表示IP转发功能是开启的。
      • 开启IP转发:sudo sysctl -w net.ipv4.ip_forward=1。这条命令会在运行时修改内核参数,使系统能够进行IP转发。
    • 对于基于Red Hat或CentOS的系统,操作如下:
      • 查看IP转发状态:cat /proc/sys/net/ipv4/ip_forward
      • 开启IP转发:sudo sysctl -w net.ipv4.ip_forward=1。这会立即生效,但是在系统重启后会恢复到原来的设置。
  2. 永久开启(系统重启后依然有效)
    • 在Debian或Ubuntu系统中:
      • 编辑/etc/sysctl.conf文件:sudo nano /etc/sysctl.conf
      • 在文件中找到#net.ipv4.ip_forward=1这一行(如果没有这一行,可以添加),将前面的#去掉,使这一行变为net.ipv4.ip_forward = 1。保存并退出文件。
      • 使配置生效:sudo sysctl -p。这条命令会重新加载sysctl.conf文件中的配置,使IP转发功能在系统重启后依然有效。
    • 在Red Hat或CentOS系统中:
      • 编辑/etc/sysctl.conf文件:sudo vi /etc/sysctl.conf
      • 找到net.ipv4.ip_forward = 0这一行,将0改为1。保存并退出文件。
      • 执行sudo sysctl -p命令,让配置生效,这样在系统重启后IP转发功能也会开启。

3 防火墙配置

完成路由配置之后,A 机器能够知道到达 192.168.3.0/24 子网的路由路径,但是此时让 A 直接访问 C 的地址会失败,因为他们之间的通信会被 B 的防火墙拦截。因此我们需要对防火墙进行进一步配置。防火墙的配置分为两个主要的步骤:首先我们需要允许经过 B进行路由的数据包经过防火墙。在 B 上运行下面的代码:

1
2
sudo iptables -A FORWARD -i tun0 -o enp2s0 -s 10.0.0.0/16 -d 192.168.3.0/24 -j ACCEPT
sudo iptables -A FORWARD -i enp2s0 -o tun0 -s 192.168.3.0/24 -d 10.0.0.0/16 -j ACCEPT

注意其中的 -i -o 指定的接口名称需要针对你的服务器的实际情况调整。这里我们进行的往返路由路径的分别配置,将路由策略都设置为 ACCEPT 使得数据包能够通过 B 的防火墙。

对防火墙进行配置的第二个步骤是在 B 上开启地址伪装,即 MASQUERADE 机制。注意到我们在 A 上配置了路由表,但是没有作为访问目标的 C 则并不知道通向 A 的路由路径(A 和 B 之间在的 VPN 私有网络中是直通的,不需要额外路由)。因此我们需要配置进行一个额外的配置,即在 B 中开启地址伪装,此时 B 会将来自 A 的,以 C 为目标的数据包的源地址修改为自身的地址,那么 C 会认为这个包来自 B,响应也会被发送给 B,B 再将包转发回到 A。要开启地址伪装,需要在 B 上开启 iptables 配置:

1
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o enp2s0 -j MASQUERADE

注意上面的命令结果会在重启后失效。要持久化 iptables 命令的配置,可以采用下面的方法:

  1. 使用iptables - save和iptables - restore命令(适用于大多数Linux发行版)
    • 保存配置
      • 首先,使用iptables - save命令可以将当前的iptables规则保存到一个文件中。例如,可以将规则保存到/etc/iptables.rules文件中,命令如下:sudo iptables - save > /etc/iptables.rules
      • 这个命令会将当前活动的iptables规则以文本格式输出并保存到指定的文件。输出的内容包含了表(如filternatmangle)以及每个表中的链(如INPUTOUTPUTFORWARD)的规则。
    • 恢复配置
      • 要在系统启动时自动恢复这些规则,可以在合适的启动脚本中添加iptables - restore命令。例如,在基于Debian或Ubuntu的系统中,可以创建一个脚本文件(如/etc/network/if - post - up.d/iptables - restore),并在其中添加以下内容:
        1
        2
        #!/bin/sh
        iptables - restore < /etc/iptables.rules
        然后给这个脚本文件添加可执行权限:sudo chmod +x /etc/network/if - post - up.d/iptables - restore
      • 在基于Red Hat或CentOS的系统中,可以将iptables - restore命令添加到/etc/rc.d/rc.local文件中(不过要确保rc.local文件有可执行权限),如:iptables - restore < /etc/iptables.rules。这样,在系统启动后,iptables规则就会根据保存的文件进行恢复。
  2. 使用iptables - persistent工具(适用于Debian和Ubuntu系统)
    • 安装iptables - persistent
      • 在Debian或Ubuntu系统中,可以使用以下命令安装iptables - persistent工具:sudo apt - get install iptables - persistent
      • 这个工具会自动在安装过程中保存当前的iptables规则,并且会创建一些系统服务相关的配置来确保规则在系统启动时自动加载。
    • 保存和恢复规则
      • 安装完成后,iptables规则会被自动保存到/etc/iptables目录下的文件中(/etc/iptables/rules.v4用于IPv4规则,/etc/iptables/rules.v6用于IPv6规则)。
      • 在系统启动时,iptables - persistent服务会自动读取这些文件中的规则并恢复iptables配置。如果后续修改了iptables规则,想保存新规则,可以使用sudo iptables - save > /etc/iptables/rules.v4(对于IPv4)和sudo iptables - save > /etc/iptables/rules.v6(对于IPv6)命令手动保存,或者使用dpkg - reconfigure iptables - persistent命令重新配置并保存规则。
  3. 使用systemd服务(适用于有systemd的Linux发行版)
    • 创建systemd服务单元文件
      • 可以创建一个自定义的systemd服务单元文件来保存和恢复iptables规则。例如,创建一个名为iptables - save - service.service的文件,内容如下:
        1
        2
        3
        4
        5
        6
        7
        8
        [Unit]
        Description=Save iptables rules
        After=network.target
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/iptables - save > /etc/iptables.rules
        [Install]
        WantedBy=multi - user.target
      • 将这个文件保存到/etc/systemd/system/目录下,然后使用systemd命令来管理这个服务。
    • 启用和启动服务
      • 执行sudo systemd - enable iptables - save - service.service命令来设置服务在系统启动时自动运行。
      • 可以使用sudo systemd - start iptables - save - service.service命令来手动启动服务,保存当前的iptables规则。
      • 同时,还需要创建一个用于恢复规则的服务单元文件,例如iptables - restore - service.service,内容如下:
        1
        2
        3
        4
        5
        6
        7
        8
        [Unit]
        Description=Restore iptables rules
        After=network.target
        [Service]
        Type=oneshot
        ExecStart=/usr/bin/iptables - restore < /etc/iptables.rules
        [Install]
        WantedBy=multi - user.target
      • 同样将这个文件保存到/etc/systemd/system/目录下,然后使用systemd - enable iptables - restore - service.service命令来设置在系统启动时自动恢复规则,并且可以使用systemd - start iptables - restore - service.service命令手动启动恢复规则的服务。

解决在 Openvpn 客户端中部署的 Web 服务不可用的问题

遇到这样一个蛋疼的问题,我有一台服务器,上面部署了一个 web 服务,同时我也想把这个服务器作为客户端连入一个 OpenVPN 虚拟网络,并且我希望服务器上的程序能够通过 OpenVPN 的网关来访问外部网络,这主要是为了隐藏服务器的身份。但是在 OpenVPN 连接之后,原有的 Web 服务将无法访问。通过调试分析可以法线,造成这一现象的原因是 Web 服务的响应包也被路由配置路由到 OpenVPN 的 tun0 接口中。这导致响应无法返回给原来的请求服务器。如何解决这个问题呢?

如果你在网络上搜索这类问题你会发现各种文章给出的方案一般都是为 OpenVPN 的配置文件添加 route-nopull 选项来阻止 OpenVPN 设置客户端路由,但是这会导致客户端的对外访问无法通过 VPN 进行。事实上,从 IP 路由的角度来看,如果我的服务器是 A,而某个访问 Web 服务的 IP 是 B,同时 B 也可能是 A 试图访问的外部的目标服务提供者。对传输层路由而言,A 给 B 的 Web 服务响应和 A 主动发往 B 的请求是无法区分的。从这个角度来看,要达成 inbound 和 outbound 流量分别路由似乎是不可能的。

但是其实我们有一个突破点:那就是 Web 服务总是在本机使用固定的端口和请求者通信,我们可以通过端口来区分 inbound 和 outbound 流量。首先我们输入下面的命令:

1
iptables -t mangle -A OUTPUT -p tcp -m multiport --sports 80,443 -j MARK --set-mark 1

在这个命令中,我们会让路由表观察从本地的 80 和 443 端口发出的包,并给这些包打上一个特定的标签(--set-mark 1 的作用)。然后输入下面的命令:

1
ip route add default via [gateway addr of eth0] dev eth0 table 100

这个命令会创建一个新的路由表 table 100,然后在这个表中加入一个默认路由,将流量送往原有的网关。然后再运行下面的命令:

1
ip rule add fwmark 1 table 100

这个命令会让带有标记 1 的包使用 table 100 路由表进行路由。运行完上面的配置后,web 服务就可以正常访问呢了。


以上方法是在 ChatGPT 的协助下摸索出来的,我的提问是:

如何通过 iptables 或者 route 命令,让访问 80 与 443 端口的包使用 tun0 接口,而访问其他端口的包使用 eth0 接口?

GPT 的回答是

可以使用iptables和route命令结合起来实现此目的。具体操作如下:

首先需要添加一条规则,将访问80和443端口的包标记为一个特定的标记值(比如"1"),使用tun0接口发送出去。iptables规则如下:

1
iptables -t mangle -A OUTPUT -p tcp -m multiport --dports 80,443 -j MARK --set-mark 1

接着需要添加一条规则,将标记为"1"的包使用tun0接口发送出去。route命令如下:

1
2
ip route add default dev tun0 table 100
ip rule add fwmark 1 table 100

最后需要添加一条规则,将所有未被标记的包使用eth0接口发送出去。route命令如下:

1
ip route add default dev eth0

以上三个步骤分别实现了:将访问80和443端口的包标记,并使用tun0接口发送出去;将标记为"1"的包使用tun0接口发送出去;将所有未被标记的包使用eth0接口发送出去。这样就实现了访问80和443端口的包使用tun0接口,访问其他端口的包使用eth0接口的效果。

❌