脚本【系统工具合集】折腾记录

2026年6月5日 950点热度 0人点赞 0条评论

Github持续更新,通过训练 ChatGPT 不断打磨脚本工具,初衷是可以快捷运行某些常用命令和程序。看似当前功能不多,实则每个细节都需要反复推敲。

从最终脚本使用感受和终端交互体验来看,目前尚可中意。脚本每个细节交互逻辑层次、菜单上下先后顺序,这些都需要考虑到,每当新增菜单项目后,都需要确保尽可能无纰漏、无 BUG 问题。感觉还是很需要费些心力和时间。

项目地址,名称:【System Tools Collection】ㅤㅤ地址:https://github.com/iptsh/system_toolsㅤㅤ脚本:https://raw.githubusercontent.com/iptsh/system_tools/main/system_tools.shㅤㅤ安装使用方法:

为什么会有这个脚本?日常中发现很多命令每次都需要手动输入,非常不方便,所以整合到脚本中,易于维护和查看。这是一个非常简易化的系统工具合集,目前是初步版本,方便自己使用。全部来自 ChatGPT 的训练结果,逐步添加更多常用功能,环境为 Debian 12/13 系统。

更新日志

【v1.1】 第一版,查看防火墙现有入站规则,包括 Docker 端口规则和转发规则。(2024.08.16午)

【v1.2】 第二版,防火墙 SSH 管理、更新菜单、更新日志、整合 ipset 地址、删除宿主规则。(2024.08.16夜)

【v1.3】 第三版,调整细节,优化色彩,增强易读性,关键信息突出显示,会话 screen 管理,修复选择 N/n 依然更新。(2024.08.17午)

【v1.4】 第四版,修复无法完成脚本更新问题,提醒删除更新临时文件,细节美观优化,作者网站添加显示。(2024.08.17夜)

【v1.5】 第五版,添加脚本显示语言切换功能,支持中文和英文切换,脚本外观显示优化。(2024.08.20夜)

【v1.6】 第六版,管理 Docker 防火墙规则,管理单纯支持 IPv4 访问的 Docker 服务,管理同时支持 IPv4 访问和 IPv6 访问的 Docker 服务,如果是后者,需要开启 Docker 自定义网络,并且配置 IPv6 转发和访问,本脚本不会强制去要求用户如何去完成这些配置,不过就目前来看,通过 Docker 项目 robbertkl/ipv6nat 实现 Docker 网络的 IPv6 转发和访问,是比较推荐的做法,当然也可以采取别的方法。这个脚本的 Docker 服务防火墙管理功能,其实也是作者制作这个脚本的最初目的,同时也是作者认为非常有必要实现脚本化的 Docker 维护策略。两个非常重要的事情,一个是限制外界对 Docker 搭建服务的访问,另一个是实现 Docker 服务的 IPv6 访问。(2024.08.21午)

【v1.7】 第七版,修正 Docker 防火墙管理选项逻辑错误,增加询问是否创建配置文件的判断环节,增加常用系统命令子菜单,主菜单增加显示 Docker 容器信息选项,显示容器名称、容器所在网络名称、IPv4地址、IPv6地址、容器运行状态、容器端口映射信息,优化 Docker 容器信息显示的可读性以及信息输出的美观性。(2024.08.22夜)

【v1.8】 第八版,变更 Docker 容器信息显示的容器状态内容为白色,以避免手机客户端代码自动换行后,视觉上与容器名称不好区分,变更 Docker 容器信息获取的内容为空时,能够显示字符 N/A ,以代表未获取到任何信息,防止可能会造成的信息列的错乱。(2024.08.23午)

【v1.9】 第九版,修正创建 Docker 防火墙配置文件时,未判断 ipset 是否已经安装的问题,优化以及变更管理 SSH 防火墙规则以及管理 Docker 防火墙和规则时终端交互的逻辑层次,当选择未创建配置时会首先判断系统中是否已经存在配置文件,这是一种质疑逻辑,避免选择失误进而造成直接进入创建配置文件的环节,显然直接进入下一环节并不是最佳的终端交互体验方式,另外,当选择修改相应的配置文件时,也会首先判断系统中是否已经存在对应的配置文件,同样也是质疑性质的逻辑,之前的版本中,在最终创建配置文件的之前才会检测系统是否已经存在配置文件,现在这种检测被提前到交互询问的环节,这一切都时为了在创建任何配置文件之前,都能确保系统中确实没有相应的配置文件,而不是直接盲目的创建任何文件,一切都需要在透明的逻辑环境下进行脚本的敏感操作,至于之前的检测环节,变更为相应的提示语。(2024.08.25夜)

【v2.0】 第十版,查看 iptables IPv4 Docker NAT 规则和查看 ip6tables IPv6 Docker NAT 规则,在最新的Debian版本中,无法通过POSTROUTING显示端口NAT转发明细,此版本增加DOCKER明细以显示转发。(2025.04.17午)

【v2.1】 第十一版,新版本哪吒监控服务端和被监控端共用相同的端口,本脚本设置的IP地址防火墙规则更新匹配方法,同时保留新旧版本的端口匹配。(2025.04.18午)

【v2.2】 第十二版,修正新建ssh防火墙规则脚本内容错误,原脚本没有定义丢弃规则,这属于严重功能错误,如果仅仅定义允许的规则,将毫无意义。(2025.04.21午)

【v2.3】 第十三版,删除首次创建以及修改ssh规则之后显示ip地址集相关的代码,原因是无法显示,属于无效代码。(2025.04.23午)

【v2.4】 第十四版,修复新建 ssh 脚本以及 docker ip 脚本时的三处核心关键错误,分别是网络名称获取的错误、获取容器名称的错误、ipset地址集合服务的错误。脚本作者迁移至新的 iptsh.com 网址。修复几处细节的显示颜色无效问题。(2025.05.06午)

【v2.5】第十五版,修复screen工具代码中包含sudo导致的错误,添加卸载脚本菜单选项,卸载脚本时也同时卸载快捷方式。(2026.05.21午)

以下内容是脚本形成之前的探索,按照时间倒序排列。

禁止〖 IP + 端口 〗访问〖 Docker 〗〖 规则优化版 〗

复盘所有规则过程中,发现有一个规则顺序有概率会在服务器重启后颠倒,这是严重的问题,会直接导致放行的地址无法访问到服务,询问 ChatGPT 多次后,没有真正解决,原因不明,然后就想着是否可以接着这个思路继续往前走走看,是否能够解决每次添加新的容器到各种脚本之后,都要重启服务器才能避免重复添加之前已经存在的规则,经过多次尝试之后,最终选择 ChatGPT 提供的循环删除已存在的规则这种方法,然后顺便莫名其妙的解决了刚才说的规则顺序颠倒的问题。同样的,适用于 SSH 、X-UI 的规则脚本。(2024.08.02)

禁止〖 IP + 端口 〗访问〖 Docker 〗〖 纯 IPv4 版 〗

这就又回到不可避免的情况,之前 Searxng 和 Seafile 就属于这种,无论怎么弄,都无法从本地服务器的 IPv6 地址把服务构建出去,只能通过另外一台服务器反向代理实现 IPv6 访问,当然反代服务器必须支持 IPv6 地址才行,通过 NAT 映射出去的 IPv6 可以通过反代 upstream 块的方式负载均衡到 IPv6 或者 IPv4 地址,而且不浪费本地服务器原生支持 IPv6 的现状,而且由于是 NAT 转发 IPv6 地址,自然安全方面更容易管理,通过〖 非纯 IPv6 版 〗方式的话,也可以负载均衡,也没有浪费原生现状,但是安全方面天生不具备优势,那么,〖 纯 IPv4 版 〗相比较而言,无法负载均衡,而且浪费原生现状,安全的话可以直接选择不去映射 IPv6 端口,也就是通过 "0.0.0.0:映射端口:容器端口" 的方式实现仅暴露 IPv4 地址的效果,从而避免可能存在的潜在安全隐患,这也算是唯一的可圈之处,防火墙规则的话,只需要设定 IPv4  iptables DOCKER-USER 规则即可,不用再去考虑 IPv6 规则,同时获取 IP 地址时,不需要再指定容器所在的网络,因为是直接默认网络启动的容器,这种情况,有可能容器启动后是 Docker 默认的 bridge 网络,也可能会自动创建一个基于 bridge 的网络,无论哪种情况,都只会造成容器启动后仅有一个网络,所以,不用在脚本中指定网络名称。但是话说回来,除非是特别中意的容器项目,否则真心不想这样使用,太浪费原生 IPv6 地址的支持。(2024.08.02)

禁止〖 IP + 端口 〗访问〖 Docker 〗〖 非纯 IPv6 版 〗

之前提到过 Seafile 不支持原生形式的 IPv6 地址访问,类似的容器肯定不在少数,这些容器只能使用默认 Docker bridge 网络,然后借助服务器公网 IPv6 地址加端口的方式,可以实现 IPv6 访问,但是容器内部没有 IPv6 内网地址,这种方式,如果要实现禁止〖 IP + 端口 〗访问〖 Docker 〗之目的,就比较特殊,所以叫〖 非纯 IPv6 版 〗,因为尽管不是纯的,但是变相的可以通过 IPv6 访问。在定义规则时,需要把 IPv4 和 IPv6 分开处理,对于 IPv4 需要定义 iptables DOCKER-USER 规则,而 IPv6 需要直接定义 iptables INPUT 规则。关键点在于,需要定义容器的端口和宿主的端口,用来分别用于 DOCKER-USER 规则和 INPUT 规则。(2024.08.02)

禁止〖 IP + 端口 〗访问〖 Docker 〗〖 IPv6 优化版 〗

由于 Seafile 不能原生支持 IPv6 访问,决定不再使用,用了这么多年,终于还是说再见,通过尝试得知 Nextcloud 符合需求,通过第三方脚本里面的自动安装,是非常轻量,但是会提示数据库不推荐,最终决定使用 Nextcloud All-In-One 版本,这中间需要按照官方操作,反向代理在另外一台机子上,所以采取的是反代途径安装,经过一番周折搞定之后,发现,并不能固定自动安装容器的 IP 地址,除了第一个容器可以,其余几个,不知道如何去固定 IP 地址,因为是通过 WEB 端点击的安装,都是后台自动进行的,所以,就引出一个问题,无法通过防火墙去设定规则,经过反反复复磨合 ChatGPT 之后,最终优化出合适的脚本内容,通过自动获取各个容器的 IP 地址,然后自动设定容器防火墙的规则,由于是多个容器,需要设定名称和端口的键值合集,以解决 IPv6 规则有些容器不生效的问题,最大的难点,在于有一个容器,确切的说是 Nextcloud 反代的容器,无论怎么尝试,就是不能自动生效 IPv4 规则,排查原因,可是费了大力气,最后发现,之所以不生效,是因为同时连接两个容器网络导致,无法自动识别到底需要哪个 IP 地址,然后尝试退出容器默认网络,发现不行,必须得保留,只能想办法让脚本自动识别需要的那个 IP 地址,这个过程及其难受、及其折磨,通过不断训练磨合 ChatGPT 之后,得到了满意答案。目前的脚本版本,可以说非常满意。在没有遇到其他另类情况之前,这个脚本可以完美开机自动获取各个容器的 IP 地址,然后自动归类设定防火墙规则,以达到限制外界通过 IP + 端口的形式直接访问容器提供的各类服务。(2024.08.01)

禁止〖 IP + 端口 〗访问〖 Docker 〗〖 汇总版 〗

分为以下几种情形。第一种,使用 host 网络模式,则直接通过 iptables INPUT 规则即可限制,缺点很明显,容器越来越多,则必然端口冲突。第二种,服务器厂家自带外置防火墙,例如 linode 防火墙,可以直接定义端口的规则,可以无视容器规则带来的控制问题,缺点的话,不是每一个厂家都提供这种服务。第三种,直接不暴露端口,改用 Nginx 容器所在网络,必须反代使用,缺点几乎没有,非常特殊的需求下会有冲突,例如这几天鼓捣的最终目的就是把反代迁移出去,因为 44380 端口需要让位给 X-UI 使用。第四种,使用 bridge 网络模式,包括自定义 bridge 网络,需要定义 iptables DOCKER-USER 规则,特别重要的是屏蔽端口不能是映射到宿主的端口,必须是容器内部端口,这是核心关键点所在,还需要固定容器 IP 地址,不然的话多个容器同时存在时会开机打乱地址,而且开机自启动需要晚于系统创建 DOCKER-USER 规则链的时间,否则不生效,这一种可以说是最完美的方案,没有任何缺点,硬要说,也只有一点,就是必须手动创建规则,不过可以借助脚本,同时可以开机自动运行,因为每次重启,Docker 都会自动重新创建规则。大致无外乎就是这四种情形。第三种之前文章已经记录过,前两种不需要刻意记录,搜索即可看到大把教程。说是〖最终汇总版〗,其实重点就是记录最后一种情况的步骤,也算是这几天没有白忙活,翻遍各种网络教程,结合 ChatGPT 之助攻,感觉自己有所收获。下面开始记录,同时把 IPv6 一起涵盖记录。(2024.07.30)

第 1 步,由于把 IPv6 情形涵盖在内,首先部署 robbertkl/ipv6nat 容器,实现 IPv6NAT 转发功能,分配内部 IPv6 地址,创建自定义 Docker 网络,把容器加入到这个自定义网络中。同时需要定义固定的 IP 地址,包括 IPv4IPv6 两者。

第 2 步,创建规则脚本,并创建开机自启动服务,其中规则脚本开机自启动需要晚于系统创建 DOCKER-USER 规则链的时间,否则不生效。故需要定义脚本中循环等待检查的参数。另外 IPv4IPv6 需要分别定义。屏蔽端口不能是映射到宿主的端口,必须是容器内部端口,这是核心关键点所在。同样是不定义本地 IP 地址,但是,通过 iptables INPUT 规则限制的端口,就算是本地节点,亦不能访问,而,通过 iptables DOCKER-USER 规则限制的端口,外界无法访问,本地节点可以访问,这类似于 linode 商家的外置防火墙给我的感觉。

命令备忘

限定 IP 连接 SSH

一切出于安全,参照上一篇 仅允许特定 IP 访问特定端口 达到限定 IP 连接 SSH ,换言之,只有指定的 IP 地址才可以访问 SSH 服务。在原来基础上加了一道安全防线。(2024.07.13)

仅允许特定 IP 访问特定端口

尽管最终目标“禁止 IP + 端口访问”未实现,不过也算是已经变相满足安全诉求。这是第三种用来屏蔽外界直接访问特定服务之解决方案,之前两种,一种是直接不暴露 Docker 容器端口借助反代从根源上达到目的,另一种是通过自定义容器内配置文件以达到屏蔽外界通过 IP 地址直接访问服务之可能性,这第三种比较特殊,不能通过上述那两种方法达到目的,必须要暴露并映射端口才能使用,也无法通过自定义配置文件去屏蔽。具体策略就是,仅允许特定 IP 访问某个端口且开机自动运行,尽管无法通过反代访问,不过就算是没有 ssl 配置之安全加持,外界也无法访问特定端口之服务。最终,特定之服务,只能通过特定 IP 地址访问,其实就是代理地址。(2024.07.19)

第 1 步,安装ipset工具,并新建add_ips.sh脚本。

第 2 步,在add_ips.sh脚本中添加以下内容。

第 3 步,赋予add_ips.sh执行权限,并新建add_ips.service开机自动运行服务文件。

第 4 步,在add_ips.service文件中添加以下内容。

第 5 步,重新加载配置,设置开机自动运行,启动服务,查看运行状态。验证配置是否已经生效。

第 6 步,重启服务器,验证是否开机自动运行。

命令备忘

鸣谢:所有解决思路和方案探讨,以及最终诉求达成,全部来自 ChatGPT 之建议。

禁止〖IP + 端口〗访问〖Docker〗〖不暴露端口〗(再续)

重新安装 Joplin 过程中,询问 ChayGPT 得知,定义 Docker YML 网络属性,需要单独定义。然后 app 和 db 分别引用定义的网络属性即可。(2024.06.18)

禁止〖IP + 端口〗访问〖Docker〗〖不暴露端口〗(续)

按照套路重新安装 recketchat 之后,发现并不能正常访问,经过排查,是 db 也需要定义网络参数,确保都在同一网络下,才可以。(2024.06.18)

禁止〖IP + 端口〗访问〖Docker〗〖不暴露端口〗

这一切诉求之来源,皆由 VPS 无防火墙造成。目的无非是,规避暴露端口,禁止外界直接访问 IP + 端口。各种防火墙方法,及各种咨询 ChatGPT 之后,均无效。可仍有执念。最终受一篇教程启发,当然关键还是 ChatGPT 立功,再稍作变通,如得所愿。幸甚,幸甚。关键就在于,既然要禁止外界通过 IP + 端口直接访问 Docker 内某项服务,那么从根源上来讲,启动 Docker 内某项服务时,不去定义 -p 参数,不去定义运行端口,转而由 --net 参数代替,定义  Docker 内 Ningx 所在网络,这样一来,在启动服务后,倘若不去反代,则无法访问此项服务,反代参数定义服务名称 + 所在 Docker 内端口。所有关键信息点均来自 ChatGPT 之答案,不过有所变通,答案告知定义新网络,服务和 Nginx 分别在启动时定义到这个新网络,然后反代。变通以后,直接让服务加入到现有 Nginx 之网络,进而反代出去。(2024.06.14)

配置 iptables 禁止 IP + 端口访问〖此方法无效〗

又又新入手一个 VPS 机子,之前,应该是很早之前就用过这家,现在算是又回归,反代之后想着禁止直接通过 IP +端口形式访问特定的 Docker 服务,但是这家没有后台防火墙,不像 LN 商家那么贴心周到。网上搜索很多途径没有成功,什么 UFW 也好,还是 firewalld 也好,都不能起到作用,最后通过和 ChatGPT 若干回合的过招,最终达到目的。就算是通过 ChatGPT 也是费好大劲才搞定,如果单纯靠网络搜索,不知何时才能搞定。总结,走了很多弯路,好在最后可以了,不过和 LN 直接在后台一分钟搞定结果不同,通过 ChatGPT 搞定后,只能通过域名访问服务,就连自己本地 IP 节点通过 IP + 端口的方式也不能访问。当然,我个人还是喜欢现在的方式。都不能访问就对了。正是我要的结果。提问,以下是我向 ChatGPT 询问的所有问题,问了这么多才找到正确答案。说明太小白。每一次回答之后,都要尝试一遍,然后没达到效果,就需要全部推倒重来,这整个过程非常需要耐心,好在我很有耐心。耐心的源动力来自兴趣使然。(2024.06.07)

将军赶路,不追小兔。

文章评论