例行安全檢測 — 加固WordPress

因為我正在使用 cloudflare 提供的內網穿透服務, 相當於整個服務器只對外開放了 Web 服務, 所以我基本是圍繞 Web 服務在加固. 如果讀者的 wordpress 跑在租用的 VPS 上, 極有可能同時開放了數據庫、SSH、FTP 服務, 對這些的防護不在本文討論範圍內.

本文主要是參考了這篇官方教程. 如果你英文好的話, 不妨自己讀一讀這篇教程, 寫的很詳細, 基本每一個改動都有解釋.

檢測手段

https://github.com/wpscanteam/wpscan

下載 wpscan, 然後在終端敲入

wpscan --url https://example.com

可能需要關閉 CF 防火牆.

刪除無關文件

cd /www/wordpress

# 刪除根目錄下無關文件
rm readme.html
rm license.txt

# 遞歸刪除插件、主題 Readme
find . -name readme.txt -type f -print -exec rm -rf {} \;

檢查用戶權限

關於用戶權限說明, 請跳轉至 wordpress 官方教程

默認情況下, 目錄權限應當是 755 (drwxr-xr-x), 文件權限 644 (-rw-r–r–), 由一個專門的非管理員帳戶管理 (通常是www).

要更改權限, 請使用以下命令:

# 對於目錄
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; 

# 對於文件
find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \; 

保護 wordpress 文件

所謂的保護 wordpress 文件, 並不是防止訪客訪問這些文件, 而是防止出內鬼. ( PHP 腳本 ) 訪客在訪問這些文件時要麽是 403 要麽就是空白, 而網站內的 PHP 腳本則可能有權限讀取並修改它們.

下述的 .htaccess 只存在於使用 Apache 提供服務的服務器中. 如果你是使用 Nginx 或者其他軟件, 下述教程並不適合你.

保護 wp-includes

wp-includes 的概念類似頭文件, 屬於 include-only, 這一整個文件夾的內容都不應該被修改. 為了防止惡意插件或者惡意主題搞破壞, 可以在 .htaccess 中添加如下幾行:

# Block the include-only files.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

注意把上述內容添加在 BEGIN...END... 之外, 不然可能遭到複寫.

保護 wp-config.php

在 .htaccess 文件的開頭添加如下內容:

<files wp-config.php>
order allow,deny
deny from all
</files>

關閉編輯文件功能

我因為可以使用 ftp、vscode 遠程編輯, 並沒有怎麼在意過 wordpress 自帶的 「主題編輯器」和「插件編輯器」, 所以關掉也無所謂. 如果你對這些功能重度依賴, 我並不推薦關閉: 因為這項設置是防止已經獲得後台訪問權限的黑客亂改文件, 而都能進入後台的黑客估計也不是非要通過圖形編輯器來幹掉你的網站.

要關閉這項功能, 在 wp-config.php 中加入

define('DISALLOW_FILE_EDIT', true);

這個設置並沒有關掉插件對文件的寫入權限, 所以插件應該都還能正常工作.

保護 wp-admin.php

被 Cloudflare 防火牆擋下來一大部分攻擊都是針對 wp-login.php

所謂的攻擊, 大多數都是在暴力枚舉密碼, 比如說 admin/123456 這樣子.
當然我不怕這樣的攻擊, 首先我的用戶名就不是 admin, 其次我有自信自己的密碼在互聯網上是獨一無二的 ( cat /proc/sys/kernel/random/uuid ). 只不過煩倒是蠻煩的, 帶寬本身就有限還要和這群工具小子打交道?

解決方案就是編輯 .htaccess , 添加訪問口令.

通過直接編輯 .htaccess

  1. 狂戳這個鏈接, 根據 apache 版本生成 .htpasswd 文件.
  2. 它會生成一個字符串. 在網站根目錄創建一個 .htpasswd 文件站貼進去.
  3. 在 .htaccess 中添加如下內容 (仍然在 BEGIN 和 END 之外)
# Stop Apache from serving .ht* files
<Files ~ "^\.ht">
  Order allow,deny
  Deny from all
</Files>
# Protect wp-login.php
<Files wp-login.php>
  AuthUserFile [path]/.htpasswd
  AuthName "Private access"
  AuthType Basic
require user [username]
</Files>

注意修改框出來的內容, [path] 填網站根目錄絕對路徑, [username] 填認證的用戶名.

這樣就 OK. 這樣子如果不通過驗證, 訪問 wp-login.php 就顯示 500 錯誤.
另外, 那個 .htpasswd 文件是允許多行的, 一行對應一個用戶, 就這個樣子.

阻止垃圾留言

點擊提交留言的按鈕, WordPress 會跳轉到 wp-comments-post.php 來提交留言. 但是直接 POST 到這個地址也可以提交留言. (機器人) 但是直接 POST 沒有 referrer, 下面這個方法可以阻擋沒有 referrer 的 POST 操作.

# Stop spam attack logins and comments
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} .(wp-comments-post|wp-login)\.php*
	RewriteCond %{HTTP_REFERER} !.*[example.com].* [OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule (.*) http://%{REMOTE_ADDR}/$1 [R=301,L]
</ifModule>

同樣, 替換 [example.com] 為實際網址.

做完了之後不要忘記開隱私模式測試一下.

WordPress + Cloudflared + V2ray 異地組網並隱藏流量

目標

  • 異地組網, 遠程訪問家中環境
  • 結合海外 VPS 翻牆 ( 不在此篇討論 )
  • 使用 V2Ray TLS 加密流量
  • 將 TLS 流量隱藏在正常的 HTTPS 流量中達到混淆目的
  • 使用 Cloudflare 的內網穿透服務, 達到防探測目的 ( 服務器直接和 CF 溝通, 沒有端口暴露 )
  • 使用 Cloudflare 的 CDN 服務, 達到防牆、加速作用

如果你並不是想要做異地組網, 而是想要在 VPS 上跑 (Nginx/Caddy/Apache) + WP + V2Ray, 那麼你其實用不著這麼複雜. 你只需要看這篇文章就可以了.

(這篇博文主要是討論一個沒多少人做過的方案的可行性, 所以你會看到後面還有一大通廢話; 作為教程本文是不合格的, 如果想要尋找教程請出門右轉谷歌搜索. )

網絡拓墣示意圖

準備環境

  • 一台聯網、24×7 運行的機器, 內存 4G+, 空間 8G+
  • 安裝有 Linux 系統 ( 推薦 Openwrt, 或者 樹莓派安裝 PiOS )
  • Cloudflare 帳戶, 託管在 CF 上的域名

執行以下操作準備所需鏡像.

docker pull wordpress
docker pull mariadb
docker pull teddysun/v2ray

使用以下 Dockerfile 構建 Cloudflared 鏡像

FROM debian:latest
VOLUME ["/etc/cloudflared"]
WORKDIR /etc/cloudflared
RUN ln -s /etc/cloudflared /root/.cloudflared
RUN apt update && apt install wget -y
RUN wget https://github.com/cloudflare/cloudflared/releases/download/2021.5.10/cloudflared-linux-amd64 \
    && mv cloudflared-linux-amd64 /usr/local/bin/cloudflared \
    && chmod +x /usr/local/bin/cloudflared

配置 Nginx + WordPress

如果你已經配置好了, 可以直接跳過. 我在這裡貼出我的啟動參數:

docker run --name wordpress \
-v /www/wordpress:/var/www/html \
-p 443:443/tcp \
-p 80:80/tcp \
--net wpblog \
--restart always \
-h wordpress \
--expose 443/tcp \
--expose 80/tcp \
-e 'WORDPRESS_TABLE_PREFIX=wp_' \
-e 'WORDPRESS_DB_HOST=db' \
-e 'WORDPRESS_DB_USER=root'\
-e 'WORDPRESS_DB_PASSWORD=password' \
-e 'WORDPRESS_DB_NAME=wordpress' \
-d wordpress:latest
docker run --name wordpressdb \
-v wordpressdb_data:/var/lib/mysql \
-p 3306:3306/tcp \
--net wpblog \
--restart always \
-h db \
--expose 3306/tcp \
-e 'MARIADB_ROOT_PASSWORD=password' \
-e 'MARIADB_DATABASE=wordpress' \
-d mariadb:latest

V2Ray

V2Ray 啟動參數:

docker run --name v2ray \
-v /etc/v2ray:/etc/v2ray \
--net host \
--restart always \
-d teddysun/v2ray

V2Ray 配置文件:

{
  "inbounds": [
    {
      "port": 9999,
      "listen":"127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "myawesomepassword",
            "alterId": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "/myawesomepath"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

Cloudflared

Cloudflared 的配置有一點點煩. 我先開了一個 Debian 容器生成了 Cloudflared 的配置文件:

docker run --rm \
-v /etc/cloudflared:/root/.cloudflared \
-it debian:latest

然後在 Debian 中執行:

apt update && apt install wget -y
wget https://github.com/cloudflare/cloudflared/releases/download/2021.5.10/cloudflared-linux-amd64 \
    && mv cloudflared-linux-amd64 /usr/local/bin/cloudflared \
    && chmod +x /usr/local/bin/cloudflared
cloudflared login
cloudflared tunnel create mytunnel
exit

/etc/cloudflared 中新建 config.yml, 寫入:

tunnel: tunnel-id-here
credentials-file: /etc/cloudflared/tunnel-id-here.json

ingress:
  - hostname: myawesomesite.com
    path: /myawesomepath
    service: http://localhost:9999
  - hostname: myawesomesite.com
    service: http://localhost:80
  - service: http_status:404

使用如下啟動參數啟動容器:

docker run --name cloudflared \
-v /etc/cloudflared:/etc/cloudflared \
--net host \
--restart always \
-d cloudflared:latest '/usr/local/bin/cloudflared' '--no-autoupdate' '--config' '/etc/cloudflared/config.yml' 'tunnel' 'run' 'tunnel-id-here'

DNS 配置

打開 Cloudflare, 新建一條 CNAME 紀錄, 如下配置:

| TYPE  | NAME |            CONTENT              | TTL |  Proxy State|
| CNAME |  @   | tunnel-id-here.cfargotunnel.com | auto|   Proxied   |

驗證

$ curl https://myawesomesite.com/myawesomepath                             
Bad Request

後記

使用場景

之所以會有這樣的主意, 是因為我早就將所有文件都掛在 NAS 中了, 我隨身攜帶的筆記本、手機裡面基本沒有任何文件. 那麼當我出遠門的時候, 如果沒有一個可靠的組網方案, 難不成我還得把硬盤拆下來帶著走? ( 主要是留學場景 )

那麼只有 VPN 方案了. 眾所週知天朝的網絡環境超級奇葩, 要滿足搭建 VPN 的條件得開放公網 IP、配置 DDNS、配置端口轉發等一系列操作, 搞不好哪天運營商給妳封了還得重搞. 而且明擺著 VPN 流量流進流出也很不放心.

所以要配置這樣一個 VPN 還是得靠內網穿透. 問題是自己配 VPS + FRP 會被牆, 購買現成的方案性價比低, 好像真的走到僵局了. 當 4月份 CF 宣布 Argo Tunnel 開放之後我就一直在尋找利用它的方法: Cloudflare 現在遍地開花, 和 Cloudflare 長期的 TLS 流量是唯一不會被懷疑 + 不會被牆掉的. 而且有 CF 的 Edge Network 加持, 網絡延遲可能還比自己搭建 VPS 搞內網穿透要小.

剩下的問題就是偽裝問題了. 自然而然的, 我想到了流量 TLS 加密後混在正常的 HTTPS 流量中, 那麼 V2 + WP + CF 的方案就確定下來了.

注意事項

我在網絡拓墣圖裡並沒有畫出來, 那個 Home Lan 其實是走過一個 Openwrt 網關的, Openwrt 上有配置 Passwall 鏈接到我的翻牆 VPS 來保證速度. (大部分配置有軟路由的人也基本就是這麼玩的, 保證全家翻牆)

既然有翻牆這一個環節, 那麼就肯定要注意被牆的問題. 首先我們複習一下牆的手段: 針對網站有 DNS 污染和匹配SNI, 針對 IP 就比較簡單, 直接截下流量就可以了.

因為我們使用 Cloudflared 做內網穿透, 針對 IP 的威脅可以忽視. DNS 污染可以使用 DoH、DoT、dnsProxy, 匹配 SNI 我們可以用 ESNI 嘛. 而且如果是海外訪問(留學), 連牆都不用過.

要在家啟用 dnsProxy, 可以在 Openwrt 中配置 dns2socks ( dns 流量走代理 ); 要使用 DoH、DoT, 參考 Cloudflare 的這篇教程; 配置 ESNI 得先配置加密 DNS, 然後在瀏覽器裡找到對應選項開啟.

推薦的作法

剩下就是路由器用來翻牆的 VPS 會不會被牆. 因為很多沒有被牆的網站 (如 Github ) 訪問速度也和被牆了差不多, 所以我默認是開啟 IP 白名單的. 就是說, 如果 VPS 失效, Cloudflare 也會訪問不了. 如果人在家當然很好辦, 如果人在遠門或者在國外 (留學場景), 要注意把路由器設為 GFWlist 模式.

另外, 在牆內老是訪問同一個域名可能會導致身份關聯 ( 盡量不要在牆內這麼用 ). 如果非要這麼做, 建議配合 Tor 使用或者確保 DoH、ESNI 工作正常. (就是絕對不要在手機上亂用的意思)

定期批量刪除图片 EXIF

EXIF 元信息是一種圖片的附加信息, 一般在拍攝的時候就已經寫進圖片, 而圖片被上傳到 WordPress 之後也會留在裡面.我剛剛看完幾篇關於網絡安全的文章, 於是去查詢了一下維基百科看一看 EXIF 到底有沒有這麽恐怖. 很不幸, 確實有.

圖片可以暴露拍攝的時間和地點, 精確到 GPS 坐標

雖然我的網站並不是非常 Secure, 而我使用密碼的習慣也並不是非常 Solid, 但是修復已經注意到的漏洞, 減少攻擊面總是一件好事. 所以我就設置了一個 Cron, 定時刪除 WordPress 中儲存的所有圖片元信息.

怎麼做到

首先安裝 ExifTool, 一個以 Perl 寫成的開源圖片 EXIF 信息處理工具. 樹莓派是基於 Debian, 所以直接 apt 就可以了

apt update && apt install exiftool

然後定位到 /mnt/data/wordpress/ , 這裡是 WordPress 的根目錄. 我先執行一次清除試一下:

( 方法來自 這個討論串 )

$ find -type f -iname '*.jpg' -exec exiftool -all= {} \;

1 image files updated
1 image files updated
...

然而, 除了修改文件以外, 這個工具還產生了 *.jpg_original 格式的備份, 這些備份我並不需要.

find . -name "*.jpg_original" | xargs rm -rf   

寫進 Cron

明確了作法之後, 就可以將任務寫進 Cron 了.

touch /etc/cron.daily/rm_exif
cat > /etc/cron.daily/rm_exif <<EOF
#!/bin/sh
find /mnt/data/wordpress -type f -iname '*.jpg' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.jpg_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.jpeg' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.jpeg_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.png' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.png_original" | xargs rm -rf
find /mnt/data/wordpress -type f -iname '*.gif' -exec exiftool -all= {} \;
find /mnt/data/wordpress -name "*.gif_original" | xargs rm -rf
EOF
chmod +x /etc/cron.daily/rm_exif

完成了!

Cloudflare Tunnel Self WebHosting

由於不習慣用 Hugo 管理內容, 且文章漸漸多了起來, 我在家中的樹莓派上跑起了一個 WordPress. 一切都進行的很順利, 直到我發現發佈這個網站並不是我想像中的那麼容易.

這篇文章是一篇踩坑文, 就是說我會把我在設置中遇到的一切困難完整的紀錄在文章中, 因此你不應當將其當作教程來看. 如果需要教程的話, 我推薦 官方文檔 , 或者 土豆不好吃 的教程.

前言

失敗的嘗試

首先, 我的樹莓派跑在內網, 我需要在路由器上配置一個端口轉發. 借助 Openwrt 的圖像介面, 我輕鬆的完成了轉發.

其次, 我還需要一個公網 IP. 撥打了電信的電話, 我成功的要到了公網 IP.

因為 “維穩” 需求, 電信是封殺 80, 443, 等常見的端口的. 因此我將 443 端口轉發到了 2053 端口上. ( HTTPS 證書是 Cloudflare 的原站證書 ) 2053 端口確定可以訪問.

在然後, 每次撥號的時候 IP 都會改變, 我需要配置一個 DDNS. 為了解決這個問題, 我找到了一個 Cloudflare DDNS 腳本跑在 Openwrt 裡來動態更新我的 IP.

一個類似 ip.justin.education:2053 的地址為免有些太過不友好, 於是我使用 CF-Workers 反向代理網站到 proxy.justin-zhang.workers , 再將其 CNAME 到 justin.education.

如果是靜態頁面這個時候已經可以訪問了, 但是 WordPress 並不支持多個域名, 一直在執著的 301 重定向. 我不能配置其地址為 justin.education, 因為那樣我就沒辦法登錄後台: CF 反代不支持保存 Cookies.

我於是在 Openwrt 上用 Docker 跑了一個 Nginx 來反代網站, 放棄了簡單的端口轉發的方案. 這次成功了, 不過我遇到了一些圖片和CSS不能加載的問題. 安裝插件之後我配置了替換 Header 的規則, 總算是可以看了.

但是由於 CF Workers 的緣故, 評論還是不工作. 而且攻擊者只要知道了我的端口是 2053, 他可以全網搜索 ip.justin.education:2053 的證書來找到我的真是 ip; 這顯然太冒險.

這個方案失敗之後, 還剩下的就是使用 frp 內網穿透的方案. 然而我並不想用我的翻牆服務器來代理網站, 我經常換 ip, 而且不安全, 而且效率太低.

看起來我已經被逼到絕路了.

柳暗花明

CF 經常被戲稱為做公益. 確實, 免費 CDN、雲端運行JS、免費證書、DDOS防護都看起來太美好了一點; 而且這些技術在捍衛隱私、對抗專制方面有奇效. 比如說: CDN可以用於隱藏翻牆服務器IP, 雲端 JS 可以做反向代理瀏覽器, 而且都完全不需要備案.

而就在 4月, CF 把 Argo Tunnel 免費對公眾開放 ( Tunnels for everyone ), 正好解決了我用樹莓派在家 Host Web 的需求! 說幹就幹, 立馬上手玩起來吧!

安裝 Cloudflared

樹莓派架構問題

我的是樹莓派 4B, 但是下載 Arm64 的版本跑不起來, 提示 “可執行檔格式錯誤”, 應當是說架構不對.

$ uname -m
armv7l

$ getconf LONG_BIT
32

$ cat /proc/cpuinfo

processor	: 3
model name	: ARMv7 Processor rev 3 (v7l)
BogoMIPS	: 270.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

Hardware	: BCM2711
Revision	: d03114
Serial		: 1000000038a6ce51
Model		: Raspberry Pi 4 Model B Rev 1.4
截取自 樹莓派官網
截取自 Arm 官網

這就有一點迷糊了, 我的樹莓派明明是 64 位的 Armv8, 為什麼顯示是 32 位的 Armv7 ?

經過一番搜索之後, 我發現我通過 Rpi-Imager 刷入的系統默認是32 位的. 根據 樹莓派官網, 我嘗試修改系統架構.

摘自 樹莓派官網
rpi-update # 先更新樹莓派固件
reboot
echo 'kernel=kernel8.img' &gt;&gt; /boot/config.txt
echo 'arm_64bit=1' &gt;&gt; /boot/config.txt
reboot

要完成上述操作並保證可以正常啟動, 你需要滿足所有以下條件:

  • /boot 非只讀 ( 你可以在
  • 保證 /boot/kernel8.img 存在
  • /boot/condfig.txt 不存在衝突的配置

然而, 失敗了. LONG_BIT 提示 32.
我嘗試下載 文件之後運行, 結果提示找不到文件. I beg your parden ? 大白天活見鬼.

我只好重裝了 64bit 的 PiOS, 現在運行這個程序應該沒有問題了.

下載並配置 Cloudfalred

wget https://github.com/cloudflare/cloudflared/releases/download/2021.5.6/cloudflared-linux-arm64
chmod +x ./cloudflared-linux-arm64
mv ./cloudflared-linux-arm64 /usr/local/bin/cloudflared

執行以下命令並將提示的 URL 複製到瀏覽器中打開, 點擊授權按鈕.

$ cloudflared tunnel login

Please open the following URL and log in with your Cloudflare account:

https://dash.cloudflare.com/argotunnel?callback=https%3A%2F%2Flogin.argotunnel.com%2FFFFFFFFFFFFFFFFFF-FFFFFFFFFFFFFFFFFFFFFF%3D

Leave cloudflared running to download the cert automatically.
You have successfully logged in.
If you wish to copy your credentials to a server, they have been saved to:
/root/.cloudflared/cert.pem

創建並配置 Tunnel

創建 Tunnel

$ cloudflared tunnel create wpblog

Tunnel credentials written to /root/.cloudflared/00000000-aaaa-bbbb-1111-000000000000.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.

Created tunnel blog with id 00000000-aaaa-bbbb-1111-000000000000

配置 Tunnel

touch /root/.cloudflared/config.yml
cat > config.yml <<EOF
tunnel: 00000000-aaaa-bbbb-1111-000000000000
credentials-file: /root/.cloudflared/00000000-aaaa-bbbb-1111-000000000000.json

ingress:
  - hostname: justin.education
    service: http://localhost:80
  - service: http_status:404
EOF

根據 Cloudflare 文檔 的解釋, 最後這一條是一個 “catch-all rule”, 也就是保底規則. 當有流量被導到我的樹莓派這裡, cloudflared 會一條條匹配 hostname, 如果都沒匹配到, 就返回 404. ( 你可以在樹莓派上跑其他服務比如說 gitlab, 郵件服務器之類的, 這個時候就更凸顯出 catch-all rule 的意義. )

設置 Cloudflare DNS

5 月 23 日 更新:
請直接跳過這一步. 最新版的 Cloudflare 已經無需手動配置 DNS, 如果配置了還會要求你刪除.

根據 官方文檔 , 接下來需要將要配置 Tunnel 的域名解析到 [id].cfargotunnel.com 來讓配置生效.

代理狀態勾選已代理來獲得 HTTPS 以及 CDN

由於我的 WordPress 是跑在 Docker 裡面的, 要配置 HTTPS 需要掛上一層 Nginx 的反向代理. 而 CF 正好解決了這個問題 ( Cloudflare -> SSL -> 完全 ), 而且還附帶了免費無需備案的 CDN, 說他做公益真的不是玩笑啊🤔

還可以額外配置一個重定向, 讓 www.justin.education 重定向到 justin.education . 因為前者真的很醜…

註冊服務並運行

在執行以下操作之前, 先保證 DNS 服務器設置為 1.1.1.1 . 用 Openwrt 可以在 網絡/接口/Wan/高級設置 處取消勾選 “使用對端通告的 DNS 服務器” (即運營商提供的 DNS), 然後寫上 1.1.1.1 . 普通路由器可以按照型號在網上搜索.
理想狀態是執行以下命令之後返回 _origintunneld._tcp.argotunnel.com.

$ dig srv _origintunneld._tcp.argotunnel.com

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> srv _origintunneld._tcp.argotunnel.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36844
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_origintunneld._tcp.argotunnel.com. IN	SRV

;; ANSWER SECTION:
_origintunneld._tcp.argotunnel.com. 300	IN SRV	2 1 7844 region2.argotunnel.com.
_origintunneld._tcp.argotunnel.com. 300	IN SRV	1 1 7844 region1.argotunnel.com.

;; Query time: 156 msec
;; SERVER: 192.168.10.1#53(192.168.10.1)
;; WHEN: 日 5月 16 22:48:51 CST 2021
;; MSG SIZE  rcvd: 147

滿足以上條件之後, 運行以下命令註冊 cloudflared 為 service

cloudflared service install

在我的這個版本, cloudflared.service 的啟動參數實際上是設置 /etc/cloudflared/config.yaml 為其配置文件的. 所以如果某一天你想添加一個服務, 然後不管怎麼改 ~/.cloudflared/config.yaml 都是 404, 那就是你沒有改對地方. 你可以通過 cat /etc/systemd/system/cloudflared.service 來檢查啟動參數, 如果確實是這樣的話, 直接將 home 目錄下的配置文件軟鏈接過去就可以了.

rm /etc/cloudflared/config.yml
ln -s $HOME/.cloudflared/config.yml /etc/cloudflared/config.yml

然後應該可以使用 systemctl 來控制 cloudflared 的運行和停止了.

systemctl enable cloudflared
systemctl start cloudflared
systemctl status cloudflared

成功!

做完以上所有步驟之後等待 3 -5 分鐘, 應該已經可以透過無痕模式看到網站了. 這個時候設置就基本成功了.
由於我正在使用 WordPress, 我碰到了幾個問題, 羅列如下:

問題解決方案
圖片路徑不正確在數據庫中查找替換掉舊的網址
網頁加載太慢啟用 Cloudflare 插件和 Jetpack 插件
準備將圖片批量轉化爲 Webp 格式
郵件發不出去Docker中跑 Mailu 郵件服務器
安裝 WP Mail 插件
首頁顯示錯誤
(把電腦端當成移動端處理)
自己好了
可能是缓存没刷过来的问题

WordPress Enligher 插件適配主題

感覺博客缺少一個代碼高亮插件, 所以我就挑了一個免費的, 功能比較多的插件 Enligher 安裝到博客.

好用但是挺好用, 但是好像和當前的主題不太兼容, 具體症狀請見下圖:

可以看見, 不管是編輯器還是實際文章, 這個插件都有兼容性問題.

所以我馬上要做的事情, 就是找出問題並自己解決掉.

我沒有學過任何關於 CSS 或者 JS 的知識, 以下所有紀錄都來源於常識… 如果我有哪邊做錯, 歡迎在評論區指正😄

(下文所有的修改都會寫在文末的 patch 文件中)

編輯器部分

錯位修正

margin 的左右都是 0

這個比較簡單, 修改 enlighter/resources/gutenberg/enlighterjs.gutenberg.min.css , 如下所示:

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	/* max-width: 100%; */
	padding: 15px
}

刪除/移動 干擾信息

右下角的提示 “EnligherJS Syntax Highlighter” 一直都在那裡, 非常佔空間而且還會產生打擾的效果, 所以我們不能讓它達到目的, 可以直接把它刪掉. 另外, 左上角的粗體字提示 Highlighting 種類未免有些太過喧賓奪主, 要是可以把它移到右下角的話豈不完美.

所以我就將 enlighter-footer 的部分刪掉, 然後將 enlighter-title 的部分移到 原來的 footer 的部分. 目前一切進行的都比較順利.

wp.element.createElement("div", {
                    className: "enlighter-header"
                },
                    /*wp.element.createElement("div", {
                        className: "enlighter-title"
                    }, (e = t.language, s()[e] || "Unknown language"))), wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }),*/
                    /*wp.element.createElement("div", {
                        className: "enlighter-footer"
                    },
                        wp.element.createElement("div", {
                            className: "enlighter-footer-label"
                        },
                            wp.element.createElement("strong", null, "EnlighterJS"), " Syntax Highlighter"))*/
                    wp.element.createElement(u, {
                        value: t.content,
                        onChange: function (e) {
                            return n({
                                content: e
                            })
                        },
                        placeholder: "Insert Sourcecode..",
                        "aria-label": "Code"
                    }), wp.element.createElement("div", {
                        className: "enlighter-footer"
                    }, wp.element.createElement("div", {
                        className: "enlighter-footer-label",
                    }, (e = t.language, s()[e] || "Unknown language")))),

美化

到這一步, 編輯器 Enlighter 區塊的效果是這個樣子的:

不夠完美啊!

從使用的角度來說, 它已經夠用了.
但是右下角的那一行字總覺得有點不和諧.

所以我就把它往下移動了一點點, 並且加粗.

div[data-type="enlighter/codeblock"] {
	border: 1px solid #cccbcb;
	border-radius: 5px;
	padding: 15px;
	padding-block-end: 1px /* New */
}
div[data-type="enlighter/codeblock"] .enlighter-footer-label {
	text-align: right;
	font-size: 10px;
	font-family: Menlo,Consolas,monaco,monospace;
	color: #23282d;
	cursor: pointer;
	padding-top: 3px; /* New */
	font-weight: 800 /* New */
}

( 以上所有代碼全部由我目測得到, 且並不理解其含義, 均未考慮兼容性. 使用前請再三考慮 )

最終效果

現在感覺好多了 👌

網頁展示部分

EnlighterJS 官網按鈕倒不難去掉, 插件提供了開關可以直接把它關掉.

將 EnlighterJS website button 設為 Disable 就可以了

那麼接下來要做到就是適配暗黑模式.

適配暗黑模式的話… (撓頭) 要改的變量好像有點太多了, 暫時就不寫了吧.
本身 MDX 的暗黑模式就不太好看, 我的解決方法就是 徹 . 底 . 不 . 開 ! 這下不會有問題了吧?

Patch via Gist