2020年3月

2020-03-12T08:12:19.png

我的 mbp 是 15款 13寸的，已经用了快 5 年了，最近想着把小本存在的问题都修复一下，就全方位检查了一下。

  • 第一个问题是后背板螺丝损坏，由于螺丝很小而且在当时拆机时由于使用了劣质螺丝刀，导致大部分螺丝都花了。
  • 第二个问题是 USB 接口，在购买一年后因为故障到售后维修后，就出现右边的 USB 无法识别的问题，但当时着急用就没有送到售后去一直将就使用左边的 USB 口。

阅读全文

对于没有连代理访问网站的用户或者没有加 CDN 的网站，可以直接在 Nginx 中用 deny 命令来拒绝某个 IP 的访问，$remote_addr 存储了当前链接用户的 IP:https://nginx.org/en/docs/http/ngx_http_access_module.html#deny

location / {
    deny  192.168.1.1;
    allow 192.168.1.0/24;
    allow 10.1.1.0/16;
    allow 2001:0db8::/32;
    deny  all;
}

如果用户访问时加了代理或者网站有 CDN，$remote_addr 的值就不是用户真实 IP 了。

$remote_addr 变量默认读取 $proxy_add_x_forwarded_for 变量最后一个 IP 地址，一般情况下这个就是客户端原始 IP，但当网站加了 CDN，最后一个 IP 就成了 CDN 分配的 IP，如用户本地 IP为：1.81.218.204，访问没有加 CDN 的网站：

$remote_addr：1.81.218.204
$http_x_forwarded_for: 1.81.218.204
$proxy_add_x_forwarded_for: 1.81.218.204

如果网站加了 CDN 返回信息如下：

$remote_addr：172.69.34.194
$http_x_forwarded_for: 1.81.218.204
$proxy_add_x_forwarded_for: 1.81.218.204, 172.69.34.194

可以看到 $remote_addr 发生了变化。$http_x_forwarded_for 的值没有包含 CDN 代理 IP。

客户端也可以伪造 X-Forwarded-For 信息，如下使用 curl -H 参数设置头信息：

curl https://info.niekun.net -H 'X-Forwarded-For: 2.2.2.2' -H 'X-Forwarded-For: 3.3.3.3'

这时候 nginx 的变量就发生了变化：

$remote_addr：172.69.34.194
$http_x_forwarded_for: 2.2.2.2, 3.3.3.3, 1.81.218.204
$proxy_add_x_forwarded_for: 2.2.2.2, 3.3.3.3, 1.81.218.204, 172.69.34.194

可以看到 $http_x_forwarded_for 和 $proxy_add_x_forwarded_for 变量值都附加上了伪造的信息。

根据观察 $http_x_forwarded_for 的最后一个 IP，永远是真实的用户 IP，可以进行提取。

使用 map 指令提取用户真实 IP，注意 map 指令要写在配置文件的 http 段：

map $http_x_forwarded_for  $client_real_ip {
    default                         $remote_addr;
    ~^(([0-9\.]+),\s?)*([0-9\.]+)$  $3;
}

如果 $http_x_forwarded_for 没有匹配到则赋值为 $remote_addr，如果匹配到了则提取最后一个 IP。$client_real_ip 变量就是真是客户端的 IP 地址。

在安装 wordpress 后遇到一个问题，打开后台的 theme 页面后，一直无法加载出来内容，查看后台 nginx 的日志，发现如下错误：

[error] 10929#10929: *337 upstream timed out (110: Connection timed out) while reading upstream, client: 127.0.0.1, server: 127.0.0.1, request: "GET /wp-admin/theme-install.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.3-fpm.sock:", host: "127.0.0.1", referrer: "http://127.0.0.1/wp-admin/themes.php"

大概是处理 php 页面的时候 timeout 了，Google 了发现问题出在转发到代理服务器 fastCGI 时超时了:https://talk.plesk.com/threads/upstream-timed-out-110-connection-timed-out-randomly.350497/
解决方案就是在 nginx 配置文件内定义一下相关超时时间设定：

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

将上述内容加入 config 文件，reload nginx 测试页面加载是否正常：

sudo service nginx configtest
sudo service nginx reload

在使用 WSL 中发现无法使用 systemd 指令，会有如下报错信息：System has not been booted with systemd as init system (PID 1). Can't operate

查询后发现 WSL 的确有这个问题：https://github.com/MicrosoftDocs/WSL/issues/457

解决方法是用管理员权限打开 WSL，然后使用 sudo service 来控制进程，如：

sudo service nginx start

升级到 wsl2 可以通过安装 genie 来激活 systemd：https://blog.niekun.net/archives/1805.html