reverse proxy on Wayne's blog | 偉恩的部落格 | 技術博客

Cloudflare Tunnel 介紹

Thu, 02 Mar 2023 00:00:00 +0000

以前曾經寫過一篇「透過 ngrok 產生臨時用的網址到指定機器」，這次要介紹的是類似的工具 Cloudflare Tunnel，他們有著共同的功能：

我們有個本機的服務跑在 http://localhost:5000，想讓外部訪問
Cloudflare Tunnel 產生公共網址以及 Cloudflare 節點與本機間的「tunnel」
訪客訪問網址，Cloudflare 節點把請求透過 tunnel 轉送到我們本機的服務，並且把服務的回覆也透過 tunnel 反向的回傳

Cloudflare Tunnel（也稱為 Argo Tunnel）除了名字太長這個問題外，有著這些優勢：

Cloudflare Tunnel 與 ngrok 一樣是免費增值型服務，上述基本的 Cloudflare Tunnel 功能完全免費，進階的 Argo 則是收費的
Cloudflare Tunnel 可以搭配 Cloudflare 自家的 DNS 服務使用，也就是可以用自有的網址，而這在 ngrok 是要收費的
Cloudflare Tunnel 的服務會自動就近分配節點位置，而 ngrok 需要手動指定

安裝 Cloudflare Tunnel

使用 Cloudflare Tunnel 的前提當然是要有 Cloudflare 帳號，以及以 Cloudflare DNS 託管的網域，除這兩點外，我們得在主機上安裝 Cloudflare Tunnel 的代理程式 cloudflared，安裝檔參見 cloudflared 的下載頁。

建立 Tunnel

幫 tunnel 取個名字，這裡叫 local：

1

cloudflared tunnel create local

這只是在 Cloudflare 建一個空的 tunnel 紀錄在案，還沒有真正可以連線的 tunnel。

要檢視自身旗下所有 tunnel，使用命令 list：

1

cloudflared tunnel list

會看到如下的輸出：

1
2
3
4


$ You can obtain more detailed information for each tunnel with `cloudflared tunnel info <name/uuid>`
$ ID NAME CREATED CONNECTIONS
$ e6b1ea74-e6ad-4e36-b8b5-0f8f81ccafec local 2023-02-05T16:29:33Z
$ 9ea66384-6ec7-4b6c-9a05-e57c08a32526 soda 2022-05-26T01:46:42Z

綁定 Tunnel 與網址

目前 tunnel 還沒有網址，給它一個：

1

cloudflared tunnel route dns local local.cccc.ws

那 Cloudflare 會阻止我們這麼做：

1

$ Failed to add route: code: 1003, reason: An A, AAAA, or CNAME record with that host already exists.

連接本地服務

有了 tunnel、有了網址，只剩把服務連上 tunnel 了。

假設我們的機台上有個服務跑在 http://localhost:1111，想要利用 Cloudflare Tunnel 讓外部人士用 https://local.cccc.ws 訪問，最簡單的一行指令如下：

1

cloudflared tunnel run --url http://localhost:1111 local

執行後下面會跑出一堆嘰哩呱啦的訊息，只要沒有紅字就是正常：

1
2
3
4


$ 2023-02-05T16:50:52Z INF Connection e4fe5a22-1e6e-4a05-b24c-95fc3ec62501 registered with protocol: quic connIndex=0 ip=198.41.200.23 location=TPE
$ 2023-02-05T16:50:52Z INF Connection 57570b20-0c60-472b-bfac-eeebe45912ff registered with protocol: quic connIndex=1 ip=198.41.192.227 location=HKG
$ 2023-02-05T16:50:52Z INF Connection 02f8e0ad-dfca-499b-af48-21a8bbfa1b47 registered with protocol: quic connIndex=2 ip=198.41.200.43 location=TPE
$ 2023-02-05T16:50:52Z INF Connection 39c656ce-e08d-49a7-9cfb-1d05d92228fc registered with protocol: quic connIndex=3 ip=198.41.192.27 location=NRT

照紀錄看起來，我們分配到的節點分別位於台北（TPE）、東京（NRT）、香港（HKG），如同最開始所說的，Cloudflare 會自動就近分配 tunnel 節點位置。

跑起來後在 Cloudflare DNS 頁面的確有多了一筆 local.cccc.ws 的紀錄。

關閉 Tunnel

對剛剛在跑著 cloudflared 的 terminal（或 console，不論怎麼叫）按下 CTRL+C 即可中斷 tunnel。

此時若去看 Cloudflare DNS 會發現那筆 local.cccc.ws 還是在，但是確實已經連不到了，此時需要手動砍掉這筆遺留的紀錄（或者射後不理也無妨）。

其他花式玩法

前文所提的命令列用法較適合臨時性的應用，例如開發中的專案需要給手機測試、對外展示等，從 cloudflared 的名字可以推測的出來，字尾的「d」是 daemon 的意思，因此它也可以是服務，配合 tunnel 配置文件，讓開機完就把 tunnel 跑起來，除此之外，除了最典型的轉送給本地 HTTP 服務外，Cloudflare Tunnel 也可以轉送給本地 Unix socket 或者 IP，對 Cloudflare Tunnel 的其他花式玩法有興趣的朋友可參閱〈Argo Tunnels that live forever〉一文。

Clouflare Tunnel 的安全優勢

對於展示、測試開發中專案來說，搭建的 tunnel 往往是臨時性的，可能不用太在意安全性的部份，但 Cloudflare Tunnel 的野心不僅於此，他們希望可以將此技術應用在真實的服務上，帶給服務更多的安全保護，因為覺得滿好的所以也順帶寫一下。

下面的示意圖是未使用 Cloudflare Tunnel 前的一個典型的 DNS A record 訪問模型：

正常的訪客透過 example.com 訪問我們的服務，並且透過 Cloudflare 節點對我們後端的 1.2.3.4 做到基本的防護。

但我們服務的 IP 1.2.3.4 仍然是暴露在公網的，所以有心人士有可能透過一些手段擷取到我們的真實 IP 1.2.3.4，進而展開攻擊。

而在 Cloudflare Tunnel 的連線模型中，一切的傳輸只透過 tunnel，我們的服務始終都是封閉的，不曾暴露於公網，壞人大猩猩最多只能攻擊到 Cloudflare 節點，碰不到我們機台的真身，這可以為我們帶來額外的安全優勢：

另一方面，Cloudflare 有著全球廣佈的快取節點，訪客會查詢到離他所在位置較近的 Cloudflare 節點，藉此加快訪問速度，而 Cloudflare 節點與我們 tunnel 節點間的流量，則由 Cloudflare 自行導引，就像 Cloudflare 自我宣傳的那樣：

透過 ngrok 產生臨時用的網址到指定機器

Mon, 26 Sep 2022 00:00:00 +0000

參考文章

前言

在開發的過程中，有時候會需要從另外一臺機器測試在local的網站及服務。最常見的情況就是當要測試網站在手機上看起來長什麽樣子的時候，或者有時候要讓別人連到自己local的sql serer的時候。
ngrok 就是讓這一切變得容易的工具，而且很佛心的是，免費版就夠一般使用。

特性

綁定本機的埠號並接受外部連入。
可穿透 NAT 或防火牆讓外部連入。
會拿到一個 ngork 的網址方便貼到信件或訊息內。
ngrok 產生的網址支援 HTTP / HTTPS。
有 web 界面讓我們可以監看連入的請求內容。
可加設 HTTP 帳密認證，避免被不必要的人亂連。
除了支援 HTTP 外，也支援 WebSocket 和 SSH。
可同時發布多個服務。
還支援 API，可以用 API 操控 ngork。
付費方案可以自定網址。

運作模式

ngrok 就是一個 reverse proxy 的工具，透過把 local 的 port map 到一個 public 的地址，讓外部能夠透過這個 public 地址連到，然後工具用 reverse proxy 和 local 實際的 port 取得資料。

因此有個缺點，就是速度相對較慢，尤其是 ngrok 的伺服器在美國因此也會減少一些速度。不過如果是爲了開發測試用，這個就不算缺點。
ngrok 免費版本提供了一個動態的地址，需要進階功能或者同時map多個服務就需要付費。

其實 ngrok 並未真正的穿透 NAT，它只是接受 ngork cloud 機台轉發來的請求並做出回應，而那個 ngrok 的網址其實也就是連到 ngrok cloud 的網址。

安裝與使用

需先安裝 `unzip` (解壓縮用)

1

yum install zip unzip

步驟 1 - 到官網下載相對應系統的 `ngrok` 安裝包

1
2


### 以 linux 64 為例
wget https://bin.equinox.io/c/4VmDzA7iaHb/ngrok-stable-linux-amd64.zip

步驟 2 - 解壓縮安裝包並搬移到 `/usr/bin/` 中

1

unzip ngrok-stable-linux-amd64.zip

1

mv ngrok /usr/bin/.

步驟 3 - 到 `ngrok` 官網註冊一個免費帳號

步驟 4 - 將 dashboard 上顯示的 token 設定至本機

1

ngrok authtoken XXXXXXXXXXXXXXXX

顯示此畫面代表已設定完成。

步驟 5 - 假設服務跑在本機的 port 3000，則執行以下指令

1

ngrok http 3000

顯示此畫面代表已成功跑起服務，打開網址即可。

直到 ngrok 關掉或 ngrok session 過期之前，這兩個 URL 都可以被公開存取。

進階使用

外連的 web 服務加密

有時候給別人測試的鏈接不希望任意的人都能夠開啓，ngrok非常貼心的提供了這個服務。
只需要在 mapping 的時候加上 auth 這個參數就可以設定密碼保護。例如：

1

ngrok http --auth=admin:12345 3000

意思是，賬號要是admin，而密碼是12345 map 到 3000 port。

重寫 hostname

有些服務會使用到 hostname 的值，這個時候重寫 hostname 的功能就變得很重要。可以使用 host-header 做設定。

這邊的例子用的是在 IIS 裏面設定只有 test.com 才會 binding 到 80 port，使用的指令就是：

1

ngrok http --host-header=test.com 80

nginx CORS 跨域與反向代理

Tue, 23 Aug 2022 00:00:00 +0000

參考文章

CORS跨域

跨域資源共享 - CORS

跨域資源共享(CORS)是一種機制，它使用額外的 HTTP 頭來告訴瀏覽器，讓運行在一個 origin (domain) 上的Web應用被准許訪問來自不同源服務器上的指定的資源。當一個資源從與該資源本身所在的服務器不同的域、協議或端口請求一個資源時，資源會發起一個跨域 HTTP 請求。

比如，站點 http://domain-a.com 的某 HTML 頁面通過 <img> 的 src 請求 http://domain-b.com/image.jpg。網絡上的許多頁面都會加載來自不同域的CSS樣式表，圖像和腳本等資源。

出於安全原因，瀏覽器限制從腳本內發起的跨源HTTP請求。例如，XMLHttpRequest和Fetch API遵循同源策略。這意味著使用這些API的Web應用程序只能從加載應用程序的同一個域請求HTTP資源，除非響應報文包含了正確CORS響應頭。

跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要在前端設定xmlhttprequest的withCrendetalls屬性。

「同源」定義

「同源」定義很簡單，以下三個參數都相同：

1

[protocol]://[domain]:[port]

白話說，當你在 https://www.example.com/product.html 頁面

嘗試對以下路徑發出請求，都違反同源：

http://www.example.com/api/products/40.json
https://www.example2.com/api/products/40.json
https://www.example.com:8080/api/products/40.json

乖孩子遵守同源，不會被打：

https://www.example.com/api/products/40.json

簡單請求和複雜請求

簡單請求與複雜請求的差別是複雜請求會自動發出一個 OPTIONS 的預檢請求，當請求得到確認後，才開始真正發送請求。
綜上，我們要解決兩個問題：

OPTIONS 請求的正確響應
跨域請求正確響應

`OPTIONS` 請求的正確響應

參考網址

解決的方式有多種，既可以在Web Server解決，也可以在源碼層解決。因為問題比較普遍，故我們選擇在Web Server解決，下面我們以 Nginx 為例，說明解決方案。

假設訪問的地址為 `/example` , Nginx 配置如下:

1
2
3
4
5
6
7


location /example {
 proxy_redirect off;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_pass http://127.0.0.1:8080/;
}

為了解決跨域問題，添加如下內容:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


location /example {
+ if ($request_method = 'OPTIONS') {
+ add_header Access-Control-Allow-Origin *;
+ add_header Access-Control-Max-Age 1728000;
+ add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
+ add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
+ add_header Content-Type' 'text/plain; charset=utf-8';
+ add_header Content-Length 0 ;
+ return 204;
+ }


 proxy_redirect off;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_pass http://127.0.0.1:8080/;
}

說明：

if ($request_method = 'OPTIONS') {...} 當請求方法為 OPTIONS 時:

添加允許源 Access-Control-Allow-Origin 為 * (可根據業務需要更改)
添加緩存時長 Access-Control-Max-Age，當下次請求時，無需再發送 OPTIONS 請求
添加允許的方法，允許的首部
添加一個內容長度為0，類型為 text/plain; charset=utf-8 , 返回狀態碼為 204 的首部

至此，完成 OPTIONS 請求的正確響應。

跨域請求正確響應

添加如下內容:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


location /example {
 if ($request_method = 'OPTIONS') {
 add_header Access-Control-Allow-Origin *;
 add_header Access-Control-Max-Age 1728000;
 add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
 add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
 add_header Content-Type' 'text/plain; charset=utf-8';
 add_header Content-Length 0 ;
 return 204;
 }

+ if ($http_origin ~* (https?://(.+\.)?(example\.com$))) {
+ add_header Access-Control-Allow-Origin $http_origin;
+ add_header Access-Control-Allow-Credentials true;
+ add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
+ add_header Access-Control-Expose-Headers Content-Length,Content-Range;
+ }

 proxy_redirect off;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_pass http://127.0.0.1:8080/;
}

說明：

if ($http_origin ~* (https?://(.+\.)?(example\.com$))) {...}，當 origin 為合法域名(可根據業務調整或去除合法域名驗證)時:

添加允許源 Access-Control-Allow-Origin 為 $http_origin (可根據業務需要更改)
添加允許認證 Access-Control-Allow-Credentials 為 true ，允許接收客戶端 Cookie(可根據業務需要更改。但要注意，當設置為true時，Access-Control-Allow-Origin 不允許設置為 *)
添加允許的方法，暴露的首部

至此，完成跨域請求正確響應。

以上，是對跨域請求在Web Server的解決方案，主要是通過響應 OPTIONS 方法和添加允許源來解決。

當然，如果本地開發中，可以在利用 webpack-dev-server 的 proxy 選項來快速解決跨域問題：

示例如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// webpack.congf.js

module.exports = {
 //...
 devServer: {
 proxy: {
 '/api': {
 target: 'http://localhost:3000',
 pathRewrite: {'^/api' : ''}
 }
 }
 }
}

當訪問地址如 /api/foo?q=bar 時，則通過代理訪問的實際地址是: http://localhost:3000/foo?q=bar。

Nginx反向代理

nginx反向代理，通過修改nginx配置檔案實現反向代理，請求統一通過nginx分發請求

Nginx配置（192.168.75.139）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 負載均衡
 upstream my_site {
 server 192.168.75.138:8080;
 server 192.168.75.137:8080;
 server 192.168.75.136:8080;
 }

 server {
 listen 8081;
 server_name localhost;
 location ^~ /api/ {
 proxy_pass http://my_site/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-ip $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
 location = / {
 proxy_pass http://my_site/nginx/indexNginxCrossQuest.jsp;
 }
 location = /nginx/ {
 proxy_pass http://my_site/nginx/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-ip $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
 location ~ \.(html|htm|ico|png|jpg|jpeg|js|css|bmp)$ {
 proxy_pass http://my_site;
 }
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }
 }

瀏覽器請求（192.168.75.1）

綜合對比

	CORS	Nginx反向代理
前端程式碼配置	credentials=true	無
後端程式碼配置	setHeader：Allow-Origin、Allow-Methods等	無
服務端配置	無	Nginx配置
移植靈活性	高、無額外配置	低、每增加一個環境都需要增加配置
安全性	高、來源可控、直接追溯	X-Forwarded-For追溯多級來源
安全控制	黑白名單	更新配置

nginx 設定 ssl ＋自動續約 Let’s Encrypt 免費域名證書

Tue, 23 Aug 2022 00:00:00 +0000

參考文章

版本一

步驟 1 - 下載安裝及執行的腳本

1
2
3


wget https://dl.eff.org/certbot-auto --no-check-certificate
chmod +x ./certbot-auto
./certbot-auto -n

生成證書，只需要輸入郵件地址和網站根目錄，提示以下內容，說明安裝完成

1
2
3


Saving debug log to /var/log/letsencrypt/letsencrypt.log

Missing command line flags. For non-interactive execution, you will need to specify a plugin on the command line. Run with '--help plugins' to see a list of options, and see https://eff.org/letsencrypt-plugins for more detail on what the plugins do and how to use them.

步驟 2 - nginx設定隱藏目錄訪問

1
2
3


location ~ /.well-known {
 allow all;
}

步驟 3 - 生成域名證書

1

./certbot-auto certonly --email tony@hack.idv.tw --agree-tos --no-eff-email --webroot -w /var/www/ -d hack.idv.tw

到目錄內查看

1

cd /etc/letsencrypt/live/

萬用字元的申請指令 (需要驗證dns)

1

certbot-auto certonly -d *.manpc.tk --manual --preferred-challenges dns

步驟 4 - 設定nginx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


server {
 listen 80; # IPv4
 listen [::]:80;
 server_name hack.idv.tw ;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 #rewrite ^(.*) https://$host$1 permanent;
 return 301 https://www.itnotetk.com$request_uri; #跳轉到Https
}

server {
 listen 443 ssl http2;
 server_name hack.idv.tw ;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/hack.idv.tw/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/hack.idv.tw/privkey.pem;
 client_max_body_size 256m;
 ssl_dhparam /etc/nginx/certs/dhparam.pem;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_stapling on;
 ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA";
 ssl_prefer_server_ciphers on;
 #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;preload" always;
 # ...

Let’s Encrypt憑證只有90天需要手動續約

1

0 1 * * * /root/certbot-auto renew --disable-hook-validation --renew-hook "/etc/init.d/nginx reload"

版本二

網路出處

Let’s Encrypt 是一家新的證書頒發機構（Certificate Authority，簡稱 CA），其提供免費的 TLS/SSL 憑證再配合 Certbot 這個自動化工具，讓一般的網站可以很容易地使用 HTTPS 的安全加密網頁，設定很簡單，憑證的更新也可以自動處理。
以下我以 Ubuntu Linux 14.04 的系統為例，示範 nginx 伺服器使用 Let’s Encrypt 憑證設定 HTTPS 安全加密網頁的方法。

步驟 1 - 從 `Certbot` 官方網站下載 `certbot-auto` 指令稿，並設定其執行權限

1
2


wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

`certbot-auto` 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 `/opt/letsencrypt` 目錄，把 `certbot-auto` 放在這裡

1
2


mkdir /opt/letsencrypt
mv certbot-auto /opt/letsencrypt/

步驟 2 - 執行 `certbot-auto` ，讓它自動安裝所有相依套件

1

/opt/letsencrypt/certbot-auto

執行 `certbot-auto` 時，會需要輸入密碼取得 root 權限

步驟 3：

安裝完成所有需要的系統套件後，接著我們要透過 webroot 的方式，使用既有的 nginx 網頁伺服器來向 Let’s Encrypt 取得憑證，而在認證的過程會需要在網頁根目錄中建立一個 .well-known/acme-challenge/ 目錄，讓 Let’s Encrypt 的伺服器來讀取其中的內容。
一般的 nginx 伺服器通常會設定把句點開頭的隱藏檔案都擋掉，遇到這樣的狀況就會無法進行認證，這時候可以再加一小段設定，讓 .well-known/acme-challenge/ 目錄可以被正常讀取。

1
2
3
4
5
6


location ^~ /.well-known/acme-challenge/ {
# the usual settings
}
location ~ /\. {
deny all;
}

步驟 4 - 使用 `certonly` 功能下載憑證

1

/opt/letsencrypt/certbot-auto certonly --webroot -w /var/www/blog.gtwang.org/ -d blog.gtwang.org -d gtwang.org

步驟 5 - 輸入自己的 Email 信箱

步驟 6 - 閱讀使用條款，選擇「Agree」繼續

步驟 7 - 下載完成後，會出現類似這樣的成功訊息

1
2
3
4
5
6
7
8


IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/blog.gtwang.org/fullchain.pem. Your cert will
expire on 2016-08-13. To obtain a new version of the certificate in
the future, simply run Certbot again.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

這樣就成功取得 Let’s Encrypt 的憑證了，而 nginx 用的憑證就儲存在 /etc/letsencrypt/live/blog.gtwang.org/ 目錄之下，其中 fullchain.pem 就是 nginx 需要憑證，而 privkey.pem 則是需要保護好的私鑰，關於憑證檔案的詳細說明，請參考 Certbot 的說明文件。
Certbot 還有提供另外一個 standalone 的方式來向 Let’s Encrypt 取得憑證，這種方式是由 Certbot 建立一個獨立的網頁伺服器，提供 Let’s Encrypt 讀取驗證用的資料，不過這樣的做法需要綁定 80 或 443 連接埠，所以通常還會需要暫停既有的網頁伺服器，對於一般的網站而言，會造成網站有幾秒鐘的斷線現象，所以我個人不喜歡這樣的方式。
接下來要設定 nginx 伺服器，使用這個新憑證來提供 HTTPS 的安全加密網頁。

步驟 8 - 要讓 `nginx` 啟用 `HTTPS` 安全加密網頁，只要加上 `SSL` 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 `nginx` 伺服器設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


server {
 # 傾聽 HTTPS 標準埠號 443
 listen 443;

 # 同時啟用 IPv6 的 HTTPS 安全加密網頁
 listen [::]:443;

 server_name blog.gtwang.org;
 root /var/www/blog.gtwang.org/;
 index index.php index.html index.htm;

 # 啟用 SSL
 ssl on;

 # 設定 SSL 憑證
 ssl_certificate /etc/letsencrypt/live/blog.gtwang.org/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/blog.gtwang.org/privkey.pem;

 # 其他 SSL 選項
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE-2014-3566)
 ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
 ssl_prefer_server_ciphers on;

 # ...
}

`ssl_protocols` 的部分記得要把SSLv3拿掉，避免 `POODLE` 攻擊（CVE-2014-3566）。

步驟 9 - 設定好之後，檢查一下設定檔是否正確

1

service nginx configtest

步驟 10 - 確認無誤之後，重新載入設定檔

1

service nginx reload

這樣就完成 nginx 伺服器的設定了，接著就可以開啟 HTTPS 加密的網址來測試了，正常來說，使用 Google Chrome 瀏覽器開啟自己主機的 HTTPS 加密網址，應該就會顯示一個綠色的鎖頭，這樣就代表我們安裝的 SSL 憑證是有效的。

`Let’s Encrypt` 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 `certbot-auto` 來更新憑證，在實際更新之前我們可以加入 `--dry-run` 參數，先進行測試。

1

/opt/letsencrypt/certbot-auto renew --dry-run

若測試沒問題，就可以使用正式指令來更新

1

/opt/letsencrypt/certbot-auto renew --quiet --no-self-upgrade

而為了方便起見，可以將這個更新指令寫在 /opt/letsencrypt/renew.sh 指令稿中

1
2


#!/bin/sh
/opt/letsencrypt/certbot-auto renew --quiet --no-self-upgrade --post-hook "service nginx reload"

這裡我又加上一個 --post-hook 的設定，讓憑證更新完後，可以自動重新載入 nginx 伺服器的設定，讓憑證生效。
接著把這個 /opt/letsencrypt/renew.sh 指令稿寫進 crontab 中

1
2


# m h dom mon dow command
30 2 * * 0 /opt/letsencrypt/renew.sh

reverse proxy on Wayne's blog | 偉恩的部落格 | 技術博客

Cloudflare Tunnel 介紹

安裝 Cloudflare Tunnel

登入

建立 Tunnel

綁定 Tunnel 與網址

連接本地服務

關閉 Tunnel

其他花式玩法

Clouflare Tunnel 的安全優勢

透過 ngrok 產生臨時用的網址到指定機器

參考文章

前言

特性

運作模式

安裝與使用

需先安裝 unzip (解壓縮用)

步驟 1 - 到官網下載相對應系統的 ngrok 安裝包

步驟 2 - 解壓縮安裝包並搬移到 /usr/bin/ 中

步驟 3 - 到 ngrok 官網註冊一個免費帳號

步驟 4 - 將 dashboard 上顯示的 token 設定至本機

顯示此畫面代表已設定完成。

步驟 5 - 假設服務跑在本機的 port 3000，則執行以下指令

顯示此畫面代表已成功跑起服務，打開網址即可。

直到 ngrok 關掉或 ngrok session 過期之前，這兩個 URL 都可以被公開存取。

進階使用

外連的 web 服務加密

意思是，賬號要是admin，而密碼是12345 map 到 3000 port。

重寫 hostname

這邊的例子用的是在 IIS 裏面設定只有 test.com 才會 binding 到 80 port，使用的指令就是：

nginx CORS 跨域與反向代理

參考文章

CORS跨域

跨域資源共享 - CORS

跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要在前端設定xmlhttprequest的withCrendetalls屬性。

「同源」定義

簡單請求和複雜請求

OPTIONS 請求的正確響應

解決的方式有多種，既可以在Web Server解決，也可以在源碼層解決。因為問題比較普遍，故我們選擇在Web Server解決，下面我們以 Nginx 為例，說明解決方案。

假設訪問的地址為 /example , Nginx 配置如下:

為了解決跨域問題，添加如下內容:

說明：

跨域請求正確響應

說明：

Nginx反向代理

Nginx配置（192.168.75.139）

瀏覽器請求（192.168.75.1）

綜合對比

nginx 設定 ssl ＋ 自動續約 Let’s Encrypt 免費域名證書

參考文章

版本一

步驟 1 - 下載安裝及執行的腳本

生成證書，只需要輸入郵件地址和網站根目錄，提示以下內容，說明安裝完成

步驟 2 - nginx設定隱藏目錄訪問

步驟 3 - 生成域名證書

到目錄內查看

萬用字元的申請指令 (需要驗證dns)

步驟 4 - 設定nginx

Let’s Encrypt憑證只有90天 需要手動續約

版本二

步驟 1 - 從 Certbot 官方網站下載 certbot-auto 指令稿，並設定其執行權限

certbot-auto 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 /opt/letsencrypt 目錄，把 certbot-auto 放在這裡

步驟 2 - 執行 certbot-auto ，讓它自動安裝所有相依套件

執行 certbot-auto 時，會需要輸入密碼取得 root 權限

步驟 3：

步驟 4 - 使用 certonly 功能下載憑證

步驟 5 - 輸入自己的 Email 信箱

步驟 6 - 閱讀使用條款，選擇「Agree」繼續

步驟 7 - 下載完成後，會出現類似這樣的成功訊息

步驟 8 - 要讓 nginx 啟用 HTTPS 安全加密網頁，只要加上 SSL 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 nginx 伺服器設定

ssl_protocols 的部分記得要 把SSLv3拿掉 ，避免 POODLE 攻擊（CVE-2014-3566）。

步驟 9 - 設定好之後，檢查一下設定檔是否正確

步驟 10 - 確認無誤之後，重新載入設定檔

Let’s Encrypt 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 certbot-auto 來更新憑證，在實際更新之前我們可以加入 --dry-run 參數，先進行測試。

需先安裝 `unzip` (解壓縮用)

步驟 1 - 到官網下載相對應系統的 `ngrok` 安裝包

步驟 2 - 解壓縮安裝包並搬移到 `/usr/bin/` 中

步驟 3 - 到 `ngrok` 官網註冊一個免費帳號

`OPTIONS` 請求的正確響應

假設訪問的地址為 `/example` , Nginx 配置如下:

nginx 設定 ssl ＋自動續約 Let’s Encrypt 免費域名證書

Let’s Encrypt憑證只有90天需要手動續約

步驟 1 - 從 `Certbot` 官方網站下載 `certbot-auto` 指令稿，並設定其執行權限

`certbot-auto` 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 `/opt/letsencrypt` 目錄，把 `certbot-auto` 放在這裡

步驟 2 - 執行 `certbot-auto` ，讓它自動安裝所有相依套件

執行 `certbot-auto` 時，會需要輸入密碼取得 root 權限

步驟 4 - 使用 `certonly` 功能下載憑證

步驟 8 - 要讓 `nginx` 啟用 `HTTPS` 安全加密網頁，只要加上 `SSL` 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 `nginx` 伺服器設定

`ssl_protocols` 的部分記得要把SSLv3拿掉，避免 `POODLE` 攻擊（CVE-2014-3566）。

`Let’s Encrypt` 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 `certbot-auto` 來更新憑證，在實際更新之前我們可以加入 `--dry-run` 參數，先進行測試。