原來這是hEX號由器（目前型號為RB750Gr3）的升級版，主要的改變應該是CPU換了一顆基於ARM64架構的雙核心EN7562CT，記憶體也從原本的256M提升至512M，官方號稱效能提升超過一倍！（各項數據表現在100%-134%之間）至於其他規格，如儲存空間、PoE、SDCard卡槽則沒有改變，預載的作業系統則是使用RouterOS v7（我先入手的 2 台 RB750Gr3 出廠都是預載 v6）。

以下是官方介紹影片：

我們需要在 wp-config.php 內取得真實IP後，再覆寫 header 資訊即可：

if ( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
	$http_x_headers = explode( ',', $_SERVER['HTTP_X_FORWARDED_FOR'] );
	$_SERVER['REMOTE_ADDR'] = $http_x_headers[0];
}

A地更新完後，也許是DDNS更新還需要點時間，IPSec連線無法馬上建立，手動在/ip cloud進行DDNS的強制更新後 (force update)，便成功建立IPSec連線與GRE tunnel。

確定上網正常後，便開始進行B地更新（遠端），詎料等待了10分鐘，IPSec連線仍無法建立。使用nslookup檢查了B地的DDNS域名設定，發現也早已更新完成，便使用米家app確認B地米家攝影機是否正常，發現可以正常觀看，表示B地Internet連線沒有問題，只好透過Cloudflare Tunnel連上B地伺服器，再跳到MikroTik設備裡看看有什麼端倪。

確定IPSec設定無誤，手動kill connection也沒效，重新連線，A、B兩端始終都會停在no phase 2的階段，IPSec handshake無法順利完成。於是心生一計，到GRE tunnel設定頁面，將A、B兩端的IPSec secret重新設定一次，沒想到一切都正常了（？？？）太神奇了，傑克！

# location 設定
location / {
    proxy_pass http://127.0.0.1:8080;
    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-Host $server_name;
    proxy_set_header X-Forwarded-Proto $scheme;

    proxy_redirect off;
}

確保wp-config.php加入以下原始碼，否則使用HTTPS連線時，有機會遇到redirect loop (HTTP 302)：

if (isset($_SERVER[‘HTTP_X_FORWARDED_HOST’])) {
    $_SERVER[‘HTTP_HOST’] = $_SERVER[‘HTTP_X_FORWARDED_HOST’];
}
if (isset($_SERVER[‘HTTP_X_FORWARDED_PROTO’])) {
    if ($_SERVER[‘HTTP_X_FORWARDED_PROTO’] == ‘https’) {
        $_SERVER[‘HTTPS’] = ‘on’;
    }
}

官網提供的範例是：

if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

這次移往Linode，算是我第二次申租，前一次是數年前衝著前幾月的免費額度姑且先試試，曾遇過VPS突然死機，需要Linode介入處理（Linode還自己開立ticket），那時候就讓我對Linode品質打了個問號，後來發現AWS Lightsail物美價廉，免費額度結束後，便移往AWS。

那麼……這次重回Linode遇到的問題是什麼呢？──CPU utilization異常飆高，原因不明。使用不到一週的時間內，共遇到2次，第一次自復，第二次則是CPU吃到SSH都無法登入，請求協助只會提供一些沒用的top指令，都登入不了了，我要如何下指令呢？一氣之下，砍掉VPS，再度重回AWS懷抱。至於IPv4 address費用？3美元，就付吧。

後來因為愈來愈跟不上時代，或是零件故障，也陸陸續續換過幾次零組件，但都沒有脫離Intel 775平台（P5QL-EM真能撐啊！）。

在本次換心手術前的規格是：

雖然上述配備在2024年的今日，做做基本文書處理、看看影片都還過得去，但是其實效能（笑能？）也已經是捉襟見肘，所以一直醞釀著更換的想法。正巧上週末去台北順發時，發現順發AMD AM4的CPU和主機板都在打折（感覺是想出清，以Intel為主力了，光看款式與數量就輸Intel陣營一大截），最終用3,780元的價格帶走了技嘉B450M-K和Ryzen 3 3200G這個組合。

從Passmark跑分比較來看，兩次的換血，應該是非常有感，若從E5200跳到3200G來看，將近提升了8倍！

下班後花了一點時間，完成換血。

最新配備清單：

原本執行EndeavourOS (Arch Linux系)，試用了下沒問題，也不用額外安裝驅動，為了做完整測試，重新安裝成Windows 11專業版，以下是工作管理員和CPU-Z執行畫面。

做了許多日常操作測試，觀看YouTube、Netflix、巴哈姆特動畫瘋影片都沒有什麼大問題，大概只有遊戲沒有測過了，也許再找機會跑個原神試試？

1. 新增路由表
   在IP選項的Routes子選項的Routes頁籤，新增一筆，Dst. address可填0.0.0.0/0、Gateway填寫gre-tunnel1、Routing Mark填寫想要的名稱，例如：Route-to-SiteB
2. 新增路由規則
   在IP選項的Routes子選項的Rules頁籤，新增一筆，Src. address填寫本地端的某設備IP、Dst. address填寫0.0.0.0/0，table填寫Route-to-SiteB，action填寫lookup

即設定完成！

為了滿足前述的PBR (policy-based routing)需求，爬了不少文章，最後決定採用GRE tunnel over IPSec，在此將設定方式簡單做一下筆記：

1. 建立GRE Tunnel
   在Interfaces選項的GRE Tunnel頁籤，新增一個GRE tunnel，填寫Name、Remote Address、IPSec Secret、取消Allow Fast Path
2. 為GRE Tunnel介面（例：gre-tunnel1）設定IP位址
   在IP選項的Addresses子選項新增IP，填寫Address和Interfaces。記得兩地的address要錯開，但是必須是同一個網段，例如可以各別填寫172.16.0.1/24和172.16.0.2/24
3. 建立路由規則
   針對A地RouterOS，可設定往B地網段的閘道為GRE tunnel介面，如gre-tunnel1
4. 建立NAT規則
   可在srcnat表建立A地網段到B地網段的accept規則

註：只要兩地都填寫一樣的IPSec Secret且IPSec profile有共同的加密和雜湊演算法，RouterOS即可自動建立IPSec Tunnel，不必自己額外進行IPSec設定。

上回說到我在A、B兩地之間建了Site-To-Site VPN (IPSec Tunnel)，因此A、B兩地之間的互連是沒有問題的。但我在米家app裡為B地攝影機進行NAS設定時還是卡關了，是什麼問題呢？

米家app第一次進行NAS設定時，會使用NBNS (NetBIOS Name Service) 協定發出廣播封包，待SAMBA Server收到時發出回應，藉此獲得整個區域網路內的SAMBA資訊，列成清單，供使用者在app內選擇。

乍聽之下，好像沒什麼毛病，問題在於NBNS廣播封包只會在LAN端，不會被轉到WAN端，因此B地的小米攝影機發出NBNS廣播時，A地是完全收不到的。

為了解決這個問題，拿了片樹莓派4B，架好SAMBA Server（後稱SAMBA_B），先在B地運行，讓B地的小米攝影機都先完成第一次NAS設定。接著將樹莓派的SAMBA服務停止，再透過app調整攝影機的NAS設定，直接將NAS名稱設定為SAMBA_A的IP位址，沒想到完全無效。（註：先前在小米N3做過此實驗可正常上傳影像，不知是不同型號的支援度有差還是何故，竟然沒辦法運作）

為了解決這個問題，我想起先前拜讀過的（也動手實作過）一篇文篇：《跨网段环境下，小米摄像机配置NAS存储》，文章裡頭提到一個轉發封包的小工具udp-boradcast-relay-redux，可以用來將NBNS封包轉發到特定IP，這可成了救命稻草。

此前在閱讀此文時，文中方法是將udp-broadcast-relay-redux置於OpenWRT中執行，而我的網路環境使用的是UBNT EdgeRouter-X和Mikrotik RB570Gr3，未必能支援，而且已經折騰了好幾天，便沒深入思考這個方法還能怎麼套用在我的環境上。現在重新忖度……咦？在B地找台可以收得到NBNS廣播封包的機器來跑udp-broadcast-relay-redux不就成了嗎？不一定要靠路由器呀！

udp-broadcast-relay-redux雖是由C語言寫成，但沒有用到第三方函式庫，直接make即可順利獲得執行檔，接著我們指定封包轉傳到A地的SAMBA_A：

sudo ./udp-broadcast-relay-redux --id 1 --port 137 --dev eth0 --dev wlan0 -t SAMBA_A_IP_ADDR

此時再到米家app裡重新設定NAS，廣播封包順利被轉發到SAMBA_A，SAMBA_A也做出回應，從此B地攝影機和A地的NAS過著幸福快樂的日子。

在參考 https://stoneapp.tech/cavern/post.php?pid=758 網頁設定後，成功啟用 Hairpin NAT 功能，小米攝影機也可正常觀看。

設定方法

在 IP / Firewall 功能頁，選擇 NAT 頁籤，新增以下 SNAT 規則：

• action=masquerade
• chain=srcnat
• out-interface=bridge
• src-address=區網網段 （例：192.168.1.0/24）