f78fk的博客: 运维

显示标签为“运维”的博文。显示所有博文

2025年8月1日星期五

Nginx Support for QUIC and HTTP/3

首先确保:

1 nginx 升级到 1.28.0 或者更新 .

2 防火墙放行 udp 443.

配置文件修改:

第一个 server 增加:

listen 443 quic reuseport;
listen [::]:443 quic reuseport;

ssl_protocols TLSv1.2 TLSv1.3;

http2 on;
http3 on;
add_header Alt-Svc 'h3=":443"; ma=86400';

完整示例:

server {
    listen 443 ssl ;
    listen [::]:443 ssl ;
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;
    server_name example.com;
    ssl_certificate /path/fullchain.pem;
    ssl_certificate_key /path/key.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

    http2 on;
    http3 on;
    add_header Alt-Svc 'h3=":443"; ma=86400';

    root /var/www/html;
    index index.html index.htm index.php;
...
}

如果有多个 server 的话不允许再次

listen 443 quic reuseport;

否则会端口冲突。所以其余的 server 使用:

listen 443 quic;

例如:

第二个 server 增加:

listen 443 quic;
listen [::]:443 quic;
ssl_protocols TLSv1.2 TLSv1.3;
http2 on;
http3 on;
add_header  Alt-Svc 'h3=":443"; ma=86400';

更多的 server 同上。

BIND 9 CVE-2025-40777 漏洞分析与修复建议

最近关注到 BIND 9 中的一个较严重漏洞，编号为 CVE-2025-40777。
通过查阅文档，这个漏洞主要在递归服务器中出现，在特定配置下，遇到某些 CNAME 解析请求时，named 进程因断言失败崩溃，造成 DNS 服务不可用。

漏洞背景

漏洞出现在 BIND 的 serve-stale 功能上。serve-stale 作用是当上游服务器响应失败时，
允许使用过期缓存应答，从而保证解析的连续性和稳定性。

然而当配置文件中设置了 stale-answer-client-timeout 为 0，同时启用了 serve-stale，
遇到某些特殊的 CNAME 链解析请求时，named 进程会触发断言失败崩溃。

影响范围

BIND 9.20.0 到 9.20.10
BIND 9.21.0 到 9.21.9
BIND 9.20.9-S1 到 BIND 9.20.10-S1
9.18.0之前和9.18.11-S1之前的版本官方没有测试

默认情况下，serve-stale 是关闭的，且 stale-answer-client-timeout 也不是 0，
因此如果没有手动设置，一般不会受到影响。

如果没有开启递归，纯权威服务器不会受此漏洞的影响。

漏洞等级与风险

CVSS v3.1 基础分数：7.5（高危）
攻击者无需认证即可远程触发 DoS 攻击
攻击结果为 DNS 服务进程崩溃，导致解析中断
影响依赖该服务的系统和应用，可能造成网站访问失败、邮件中断、微服务不可用

漏洞原理简述

在处理递归查询时，serve-stale 允许返回过期的缓存答案以提高容错性。
但当 stale-answer-client-timeout 设置为 0，表示客户端不等待任何上游响应，
这与内部对 CNAME 链的处理逻辑发生冲突，最终导致断言失败。

临时解决办法

如果暂时无法升级，建议修改配置关闭此功能，避免崩溃：

options {  
  stale-answer-client-timeout off;  
  // 或者直接关闭 serve-stale  
  stale-answer-enable no;  
};

改完后请重启 named 服务生效。

漏洞来源

该漏洞最初由 ISC 官方披露，相关安全咨询也已提交至 GitHub Advisory 数据库，
详情见：https://github.com/advisories/GHSA-4x4c-8qp9-8ggh

2025年6月19日星期四

主权威DNS

# 生成共享密钥

tsig-keygen sync-key

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指示从 DNS1 更新zone需要共享密钥

server x.x.x.1 {    
     keys { sync-key ;}; 
};

# 指示从 DNS2 更新zone需要共享密钥

server x.x.x.2 { 
     keys { sync-key ;}; 
};

 zone "f78fk.net" { 
     type master; file "/etc/bind/zones/f78fk.net.zone"; 
     allow-transfer { 
            x.x.x.1;           //允许从 DNS1 更新zone
            x.x.x.2;           //允许从 DNS2 更新zone
         }; 
         also-notify {
             x.x.x.1;          //rndc reload后主动通知一次 DNS1 更新zone
             x.x.x.2;          //rndc reload后主动通知一次 DNS2 更新zone
         }; 
 };

从权威DNS 1

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指定向主 DNS 更新 zone 时使用的共享密钥

server x.x.x.m {    
     keys { sync-key ;}; 
};

zone "f78fk.net" { 
     type slave; masters {
             x.x.x.m;    // 主 DNS 的 IP 地址
}; 
     file "/etc/bind/zones/f78fk.net.zone"; 
};

从权威DNS 2

# 加载新密钥
vim named.conf

key "sync-key" {
    algorithm hmac-sha256; 
    secret               "DAopyf1mhCbFVZw7pgmNPBoLUq8wEUT7UuPoLENP2HY="; 
};

# 指示服务器使用密钥
vim named.conf.local

# 指定向主 DNS 更新 zone 时使用的共享密钥

server x.x.x.m {    
     keys { sync-key ;}; 
};

zone "f78fk.net" { 
     type slave; masters {
                 x.x.x.m;    // 主 DNS 的 IP 地址
}; 
     file "/etc/bind/zones/f78fk.net.zone"; 
};

官网文档:

https://downloads.isc.org/isc/bind9/9.20.10/doc/arm/html/chapter7.html#generating-a-shared-key

2025年6月10日星期二

bind创建文件失败

今天新增加从权威DNS，发现了bind无法写入文件/etc/bind/zones/tmp-rYrjupIEmc，

明明已经给与bind读写权限了，结果依然报错。

仔细分析日志
--------------------------------------------------------------------------------------------------------
10 10:56:09 DNS-SERVER-UBUNTU named[540]: dumping master file: /etc/bind/zones/tmp-rYrjupIEmc: open: permission denied Jun 10 11:02:06 DNS-SERVER-UBUNTU named[540]: no longer listening on 10.1.1.6#53 Jun 10 11:02:06 DNS-SERVER-UBUNTU named[540]: no longer listening on 2404:f800:8000:122::4#53 Jun 10 11:02:07 DNS-SERVER-UBUNTU named[540]: listening on IPv4 interface eth0, 10.1.1.6#53 Jun 10 11:02:07 DNS-SERVER-UBUNTU named[540]: listening on IPv6 interface eth0, 2404:f800:8000:122::4#53 Jun 10 11:06:18 DNS-SERVER-UBUNTU named[532]: starting BIND 9.18.30-0ubuntu0.22.04.2-Ubuntu (Extended Support Version) <id:> Jun 10 11:06:18 DNS-SERVER-UBUNTU kernel: [ 7.794237] audit: type=1400 audit(1749553573.618:45): apparmor="DENIED" operation="mknod" class="file" profile="named" name="/etc/bind/zones/managed-keys.bind.jnl" pid=532 comm="isc-net-0001" requested_mask="c" denied_mask="c" fsuid=114 ouid=114 Jun 10 11:06:18 DNS-SERVER-UBUNTU kernel: [ 8.471870] audit: type=1400
------------------------------------------------------------------------------------------------------

发现这台ubuntu22.04的apparmor正在阻止bind创建文件，

解决方法：

sudo vim /etc/apparmor.d/usr.sbin.named

/etc/bind/** r,

修改为

/etc/bind/** rw,

/etc/bind/zones/** rwk,

# 重新载入配置
sudo systemctl reload apparmor

sudo systemctl restart named

dig查询胶水记录方法

查询胶水记录（Glue Record）是否生效可以直接从TLD 服务器查询A记录。
如.top域的其中一个权威服务器是 a.zdnscloud.cn，所以就指定从它查。

dig @a.zdnscloud.cn ns1.f78fkdns.top A

结果：

—————————————————————————————————————————

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @a.zdnscloud.cn ns1.f78fkdns.top A

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64857

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;ns1.f78fkdns.top. IN A

;; AUTHORITY SECTION:

f78fkdns.top. 3600 IN NS ns1.f78fkdns.top.

f78fkdns.top. 3600 IN NS ns2.f78fkdns.top.

;; ADDITIONAL SECTION:

ns1.f78fkdns.top. 3600 IN A x.x.x.x

ns2.f78fkdns.top. 3600 IN A x.x.x.x

;; Query time: 209 msec

;; SERVER: 203.99.24.1#53(a.zdnscloud.cn) (UDP)

;; WHEN: Tue Jun 10 22:18:21 JST 2025

;; MSG SIZE rcvd: 109
————————————————————————————————————————

我们可以看到结果是直接来自上级a.zdnscloud.cn而不是递归到f78fkdns.top，所以胶水记录已经生效。

2025年6月9日星期一

Ubuntu 24.04 安装 bind-9.20.9

# 添加 isc/bind 源

sudo add-apt-repository ppa:isc/bind

sudo apt update

sudo apt upgrade

sudo apt install bind9

# 检查版本信息

named -v

rndc -v

named-checkconf -v

named-checkzone -v

# 禁止 systemd-resolved 53端口被它占用

sudo systemctl stop systemd-resolved

sudo systemctl disable systemd-resolved

sudo systemctl mask systemd-resolved

sudo rm -f /etc/resolv.conf

sudo vim /etc/resolv.conf

nameserver 2606:4700:4700::1001

nameserver 2620:fe::fe

nameserver 1.1.1.1

nameserver 1.0.0.1

options edns0 trust-ad

sudo netplan apply

# 启动 BIND

sudo systemctl start named

# 设置开机自启

sudo systemctl enable named

# 重启 BIND

sudo systemctl restart named

# 检查状态

sudo systemctl status named

# 查看日志

journalctl -u named -n 50 --no-pager

journalctl -xeu named.service

通过apt install 包管理工具安装的bind9，可能会出现重启named阻塞很久的情况，原因是systemd 单元等待 BIND 向 systemd 报告 READY，但 BIND 并没有发出通知。

解决方法：

vim /lib/systemd/system/named.service

[Service] 部分的

Type=notify

改为：
Type=simple

然后重启服务
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl restart named

# 卸载

sudo apt remove bind9

sudo add-apt-repository --remove ppa:isc/bind

sudo apt autoremove

2025年6月7日星期六

自建权威DNS,托管域名与记录管理

自建权威DNS的过程有时间整理后再写吧，先写一下如何托管别人的域名，如何新增加zone，如何新增A记录，AAAA记录等。

环境准备：

由于是自己编译的最新稳定版bind 9.20.9，所以和使用apt-get工具安装的bind路径完全不一样，我安装的路径和版本如下：

DNS服务器：bind-9.20.9
源码路径：/opt/bind-9.20.9
编译后生成的可执行文件路径：/opt/bind-9.20.9/bin/
named路径：/opt/bind-9.20.9/bin/named/named
named-checkconf 工具路径：/opt/bind-9.20.9/bin/check/named-checkconf
named-checkzone 工具路径：/opt/bind-9.20.9/bin/check/named-checkzone
rndc 工具路径：/opt/bind-9.20.9/bin/rndc/rndc
配置文件路径：/etc/bind/

这里托管的新域名是 liuyu.us.kg

主权威DNS配置：

1 named配置里新增zone

sudo vim /etc/bind/named.conf.local

追加下面的配置

zone "liuyu.us.kg" {
type master;
file "/etc/bind/zones/liuyu.us.kg.zone";
allow-transfer { 203.0.113.46;2001:0db8:85a3:0000:0000:8a2e:0370:7334; };

also-notify{ 203.0.113.46;2001:0db8:85a3:0000:0000:8a2e:0370:7334; };

};

allow-transfer里面填写的是[从权威DNS服务器]的IP，表示允许 [从权威DNS服务器] 同步的IP。 also-notify 表示有更新的话会主动通知[从权威DNS服务器]。

2 创建新增zone的配置文件

sudo vim /etc/bind/zones/liuyu.us.kg.zone

新增加下面的配置：

$TTL 604800 ;
@ IN SOA ns1.f78fkdns.top. admin.f78fk.com. (
2025060601 ; serial
3600 ; refresh
600 ; retry
604800 ; expire
3600 ) ; minimum

IN NS ns1.f78fkdns.top.
IN NS ns2.f78fkdns.top.

@ IN A 198.51.100.23
@ IN AAAA 2001:0db8:85a3::8a2e:0370:7335

www IN A 192.0.2.101
www IN AAAA 2001:0db8:85a3::8a2e:0370:7336

这里自描述了ns1.f78fkdns.top. 和 ns2.f78fkdns.top. 是liuyu.us.kg的权威DNS服务器，增加了liuyu.us.kg的A记录和AAAA记录，增加了子域www.liuyu.us.kg的A记录和AAAA记录。
refresh 1小时，retry 10分钟，expire 7天，minimum 一小时，其余项保持默认7天。
serial 2025060601，代表今天的日期，最后的01代表首次修改，以后每次更新一次数字手动+1，比如下次新增加了MX记录，这个数字就改成2025060602.

3 使配置生效

# 1. 检查 BIND 主配置文件语法
named-checkconf

# 2. 检查 zone 文件语法
named-checkzone liuyu.us.kg /etc/bind/zones/liuyu.us.kg.zone

# 3. 重新载入配置文件，识别新 zone

rndc reconfig

# 4. 加载zone

rndc reload liuyu.us.kg

# 5. 确认zone 是否加载成功 (可选)
rndc zonestatus liuyu.us.kg

# 6. 之后修改了 zone 文件只需要重新加载当前 zone
rndc reload liuyu.us.kg

从权威DNS配置：

1 named配置里新增zone

sudo vim /etc/bind/named.conf.local

追加下面的配置

zone "liuyu.us.kg" {
type slave;
masters { 203.0.113.66;2001:0db8:85a3::8a2e:0370:7337; }; // 主权威DNS 的 IP
file "/etc/bind/zones/liuyu.us.kg.zone";
};

2 使配置生效

# 1. 检查 BIND 主配置文件语法
named-checkconf

# 2. 重新载入配置文件，识别新 zone

rndc reconfig

# 3. 确认zone 是否加载成功 (可选)
rndc zonestatus liuyu.us.kg

# 4. 主动发起 zone 拉取 (可选，一般会自动)
rndc retransfer liuyu.us.kg

域名注册商设置：

去该域名的所属注册服务商管理平台，比如NameSilo官网，登录后更改该域名的NS为ns1.f78fkdns.top和ns2.f78fkdns.top即可。

验证：

使用在线工具dig https://ip.f78fk.com/dig，输入域名liuyu.us.kg，递归服务器随便选一个，查询类型先选择A记录，勾选trace，点击查询，可以看到最终A记录确实是由权威DNS ns2.f78dkdns.top回复的，也看到了上级域us.kg回复ns1.f78dkdns.top和ns2.f78dkdns.top是liuyu.us.kg的权威服务器，说明域名托管成功。

常用命令：

# 启动 BIND
sudo systemctl start named

# 设置开机自启
sudo systemctl enable named

# 重启 BIND
sudo systemctl restart named

# 检查状态
sudo systemctl status named

# 查看日志
journalctl -u named -n 50 --no-pager
journalctl -xeu named.service

2025年6月4日星期三

acme.sh申请https证书

之前用过dns方法验证，最后发现其实兼容性不好，比较麻烦，每家dns托管服务商申请api令牌的方法也不同，之后再增加新的域名部署不太方便。

经过试验发现最终其实还是用Http Web服务器的方式验证域名所有权的兼容性最好，速度也快，不容易出现什么奇奇怪怪的bug，所以最近统一把几台服务器的ssl证书申请都部署了 webroot的验证方式。

1 首先安装

curl https://get.acme.sh | sh -s email=my@example.com

邮箱填写自己的常用邮箱，之后续订时失败会发邮件给这个邮箱。安装后会自动把脚本放到这个目录: ~/.acme.sh/ 我用的root账户，所以也就是/root/.acme.sh/acme.sh

2 首次申请证书

~/.acme.sh/acme.sh --issue -d geoip.qzz.io -d jpliuyu.duckdns.org --webroot /var/www/html --server letsencrypt

命令中，我指定了申请多域名 geoip.qzz.io 和 jpliuyu.duckdns.org，也就是 SAN 证书(Subject Alternative Name）。最终生成的是一套证书，但是支持多域名, jpliuyu.duckdns.org和geoip.qzz.io都能访问我的网站，这样不会影响老用户使用旧的域名访问。

执行这条命令前，这2个域名都需要在DNS托管服务商那里设置好A记录和AAAA记录，首先确保这2个域名都能成功解析到服务器IP。

参数--server letsencrypt 是可选的，如果不指定默认是ZeroSSL的CA服务商，我个人喜欢letsencrypt，所以这里指定了。

--webroot 指定你的http服务器根目录，我这里是/var/www/html，确保你的服务器可以从外部80端口访问到，如果配置了http 301跳转的话，记得先配置放行/.well-known/acme-challenge路径，nginx的例子：

server {
listen 80;
listen [::]:80;
server_name geoip.qzz.io;
# 放行 Let's Encrypt 验证请求
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/html;
allow all;
try_files $uri =404;
}
# 其他所有请求都重定向到 HTTPS
location / {
return 301 https://$host$request_uri;
}
}

3 安装证书

第二步申请成功后，证书是保存到/root/.acme.sh目录下的，但是这个证书是给acme.sh内部使用的，接下来我们还要安装证书。

~/.acme.sh/acme.sh --install-cert -d geoip.qzz.io \
--cert-file /home/ubuntu/ssl_file/geoip.qzz.io/cert.pem \
--key-file /home/ubuntu/ssl_file/geoip.qzz.io/key.pem \
--fullchain-file /home/ubuntu/ssl_file/geoip.qzz.io/fullchain.pem \
--reloadcmd "systemctl reload nginx"

这样证书就被安装到指定的/home/ubuntu/ssl_file/geoip.qzz.io目录下了，安装成功后这里指定了执行命令 systemctl reload nginx ，这样之后脚本自动更新时，也会自动执行这条命令使http服务器生效。

接下来nginx的配置文件里指定ssl证书路径即可。

ssl_certificate /home/ubuntu/ssl_file/geoip.qzz.io/fullchain.pem;
ssl_certificate_key /home/ubuntu/ssl_file/geoip.qzz.io/key.pem;

4 验证

crontab -l

这里会发现自动添加到了定时任务，之后脚本会自动更新证书，并且使用第三步执行过的命令来安装证书。

43 18 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null

这里看到，脚本自动加入的crontab 的规则，不是标准的语法，很有可能解析错误，所以我们执行命令 crontab -e 修改这行为正确的语法：

43 18 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh > /dev/null

然后使用这2个域名访问网站吧，浏览器提示连接安全，证书有效，Firefox访问的话，可以点击小锁标志，更多信息-查看证书-主题替代名称(SAN字段)里显示了此证书覆盖的所有域名，正是前面申请的那2个域名。

之后就等待到期后自动更新并部署吧，最后附上此项目的官方网站。

https://acme.sh/

2025年6月2日星期一

甲骨文VPS,无法获取到IPV6地址

折腾了好几个小时，无论如何IPV6都无法通信。

面板已经分配了IPV6 , 配置子网，默认路由，但是VPS上总是无法获取到IPV6的地址。

手动配置IPV6地址也无法通信，耗费了半天时间，最后偶然想起来，放行546，547端口竟然一下子就成功了，这个iptables真是坑死我了。

# 清空规则

sudo ip6tables -F

sudo ip6tables -X

# 设置默认策略（DROP）

sudo ip6tables -P INPUT DROP

sudo ip6tables -P FORWARD DROP

sudo ip6tables -P OUTPUT ACCEPT

# 本地回环

sudo ip6tables -A INPUT -i lo -j ACCEPT

# 允许已建立连接的数据流

sudo ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# ICMPv6 必须全部放行

sudo ip6tables -A INPUT -p ipv6-icmp -j ACCEPT

sudo ip6tables -A OUTPUT -p ipv6-icmp -j ACCEPT

# DHCPv6（服务器端口 547，客户端端口 546）

sudo ip6tables -A INPUT -p udp --dport 546 --sport 547 -j ACCEPT

sudo ip6tables -A OUTPUT -p udp --dport 547 --sport 546 -j ACCEPT

# SSH、HTTP、HTTPS、其他自定义端口

sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

sudo ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# 确认是否放行成功

sudo ip6tables -L INPUT -n --line-numbers

# 保存防火墙配置

sudo netfilter-persistent save

# 申请IP吧，一下子就成功了

dhclient -v -6 enp0s6

Ubuntu24.04配置IPV6防火墙

# 查看当前规则

sudo ip6tables -L INPUT -n --line-numbers

# 放行 SSH (22)

sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT

# 放行 HTTP (80)

sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# 放行 HTTPS (443)

sudo ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# 放行自定义端口（TCP 和 UDP 的 10000）

sudo ip6tables -A INPUT -p tcp --dport 10000 -j ACCEPT

sudo ip6tables -A INPUT -p udp --dport 10000 -j ACCEPT

# 放行已经建立的连接

sudo ip6tables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# 最后拒绝其他

sudo ip6tables -P INPUT DROP

# 保存规则

sudo netfilter-persistent save

# 如果提示未安装:

sudo apt install iptables-persistent

sudo netfilter-persistent save

2025年5月27日星期二

Ubuntu24.04 服务器防火墙配置记录

今天家里的服务器，SSH在日本可以成功访问，

在中国的内网中却访问不了。

查看下防火墙配置

sudo iptables -L -n -v

Chain INPUT (policy ACCEPT 43M packets, 81G bytes)

pkts bytes target prot opt in out source destination

0 0 ACCEPT 6 -- * * 192.168.3.223 0.0.0.0/0 tcp dpt:8888

34623 2312K ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m geoip --source-country CN,JP

385 17628 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m geoip ! --source-country CN,JP

0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888

Chain FORWARD (policy ACCEPT 27M packets, 23G bytes)

pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 40M packets, 71G bytes)

pkts bytes target prot opt in out source destination

root@linux:~#

想起来之前配置了防火墙规则，允许CN和JP的IP访问，并且只允许了内网的192.168.3.223一台主机访问。

这下好办了，把192.168.3.0/24整个子网全部允许

sudo iptables -I INPUT -p tcp -s 192.168.3.0/24 --dport 8888 -j ACCEPT

root@linux:~# sudo iptables -L -n -v

Chain INPUT (policy ACCEPT 43M packets, 81G bytes)

pkts bytes target prot opt in out source destination

38 7792 ACCEPT 6 -- * * 192.168.3.0/24 0.0.0.0/0 tcp dpt:8888

0 0 ACCEPT 6 -- * * 192.168.3.223 0.0.0.0/0 tcp dpt:8888

34629 2312K ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m geoip --source-country CN,JP

385 17628 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m geoip ! --source-country CN,JP

0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888

Chain FORWARD (policy ACCEPT 27M packets, 23G bytes)

pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 40M packets, 71G bytes)

pkts bytes target prot opt in out source destination

root@linux:~#

配置成功，保存配置

sudo netfilter-persistent save

测试，内网的另外一台电脑SSH成功登录。

对了，把以前那条老的规则应该删掉

sudo iptables -D INPUT -p tcp -s 192.168.3.223 --dport 8888 -j ACCEPT

sudo iptables -L -n -v

Chain INPUT (policy ACCEPT 43M packets, 82G bytes)

pkts bytes target prot opt in out source destination

44 8176 ACCEPT 6 -- * * 192.168.3.0/24 0.0.0.0/0 tcp dpt:8888

34662 2315K ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m ge oip --source-country CN,JP

385 17628 DROP 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888 -m ge oip ! --source-country CN,JP

0 0 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8888

Chain FORWARD (policy ACCEPT 27M packets, 23G bytes)

pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 40M packets, 71G bytes)

pkts bytes target prot opt in out source destination

root@linux:~#

成功，保存。

sudo netfilter-persistent save

订阅：博文 (Atom)

2025年8月1日星期五

2025年7月19日星期六

漏洞背景

影响范围

漏洞等级与风险

漏洞原理简述

临时解决办法

推荐修复方案

漏洞来源

2025年6月19日星期四

主权威DNS

从权威DNS 1

从权威DNS 2

2025年6月10日星期二

查询胶水记录（Glue Record）是否生效可以直接从TLD 服务器查询A记录。如.top域的其中一个权威服务器是 a.zdnscloud.cn，所以就指定从它查。

我们可以看到结果是直接来自上级a.zdnscloud.cn而不是递归到f78fkdns.top，所以胶水记录已经生效。

2025年6月9日星期一

2025年6月7日星期六

环境准备：

主权威DNS配置：

1 named配置里新增zone

2 创建新增zone的配置文件

3 使配置生效

从权威DNS配置：

1 named配置里新增zone

2 使配置生效

域名注册商设置：

验证：

常用命令：

2025年6月4日星期三

2025年6月2日星期一

2025年5月27日星期二

查询胶水记录（Glue Record）是否生效可以直接从TLD 服务器查询A记录。
如.top域的其中一个权威服务器是 a.zdnscloud.cn，所以就指定从它查。