今天閒來無事逛了一下MikroTik網頁，發現冒出了一款名為hEX refresh的新硬體！嗯！？
原來這是hEX號由器（目前型號為RB750Gr3）的升級版，主要的改變應該是CPU換了一顆基於ARM64架構的雙核心EN7562CT，記憶體也從原本的256M提升至512M，官方號稱效能提升超過一倍！（各項數據表現在100%-134%之間）至於其他規格，如儲存空間、PoE、SDCard卡槽則沒有改變，預載的作業系統則是使用RouterOS v7（我先入手的 2 台 RB750Gr3 出廠都是預載 v6）。
以下是官方介紹影片：
近期有不知名大大前來留言，才發現我的WordPress對於處理外部真實IP的部份沒有做好，雖然前一篇文章已經成功設定好nginx將real IP搞成HTTP header的一部份，但後端WordPress完全沒有拿來用呀！XD
我們需要在 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];
}
今天心血來潮，檢查了MikroTik RouterOS v6是否有新版本，發現4月釋出了v6.49.15版，都過了這麼久，也許算是穩定版了，便著手進行系統升版（設備版本為v6.49.11）。
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重新設定一次，沒想到一切都正常了（？？？）太神奇了，傑克！
參考文章 https://medium.com/@tyh409700530/nginx-reverse-proxy-wordpress-in-https-mode-a21658f23978 ，使用 nginx，於 nginx 設定檔設定：
# 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';
前一陣子，由於收到AWS即將針對IPv4 address收費的公告，便嘗試將Lightsail轉移成IPv6-only lightsail，沒想到容器移到了IPv6-only環境後，原本提供服務的容器如nginx接收request是沒問題，但若是由容器主動發起對外連線就不行了，cloudflare tunnel也是因為同樣的原因失效，由於無法短時間解決，便決定移往Linode。
這次移往Linode，算是我第二次申租，前一次是數年前衝著前幾月的免費額度姑且先試試，曾遇過VPS突然死機，需要Linode介入處理（Linode還自己開立ticket），那時候就讓我對Linode品質打了個問號，後來發現AWS Lightsail物美價廉，免費額度結束後，便移往AWS。
那麼……這次重回Linode遇到的問題是什麼呢？──CPU utilization異常飆高，原因不明。使用不到一週的時間內，共遇到2次，第一次自復，第二次則是CPU吃到SSH都無法登入，請求協助只會提供一些沒用的top指令，都登入不了了，我要如何下指令呢？一氣之下，砍掉VPS，再度重回AWS懷抱。至於IPv4 address費用？3美元，就付吧。
家裡仍有幾部年齡十年以上的PC在服役中，其中一台是2008年自組的Intel 775平台，核心零組件是：
| CPU | Intel Pentium Dual-Core E5200 |
| Motherboard | ASUS P5QL-EM |
| Memory | G.Skill F2-6400CL4D-4GBHK (DDR2-800 2G*2) |
| VGA | MSI R4770 Cyclone |
| HDD | WD WD6400AAKS (640G Blue) |
| PSU | Seasonic S12 II 430W Bronze |
後來因為愈來愈跟不上時代，或是零件故障，也陸陸續續換過幾次零組件，但都沒有脫離Intel 775平台（P5QL-EM真能撐啊！）。
…若A、B兩地之間已建立GRE Tunnel，且A地想經由B地再路由到某地（例如Internet），可進行以下設定：
即設定完成！
原本在二個住處間建立了IPSec tunnel，使兩地之間的設備可以互相通訊，例如讓B地的小米攝影機能將影像檔上拋至A地的SAMBA伺服器。前一陣子，又有了策略路由需求，例如讓A地某設備經由B地再路由到Internet，但剛好一地是EdgeRouter-X，一地是MikroTik RB750Gr3，被設定搞得很頭疼。恰好雙十一時又淘了一台RB750Gr3回來，本來是要當備用機的，趁著元旦連假有空，便把EdgeRouter-X換成RB750Gr3。如此一來，兩地都是MikroTik設備，RouterOS的設定變得輕鬆許多。
為了滿足前述的PBR (policy-based routing)需求，爬了不少文章，最後決定採用GRE tunnel over IPSec，在此將設定方式簡單做一下筆記：
註：只要兩地都填寫一樣的IPSec Secret且IPSec profile有共同的加密和雜湊演算法，RouterOS即可自動建立IPSec Tunnel，不必自己額外進行IPSec設定。
我在A、B兩地都安裝了小米攝影機，其中A地有另外用Linux架設了SAMBA Server，供小米攝影機上傳影像（米家app的NAS設定）。為了讓影像資源的管理集中，而且不另外在B地架設SAMBA Server，便有了讓B地攝影機將影像上傳至A地SAMBA Server（後稱SAMBA_A）的想法誕生。
上回說到我在A、B兩地之間建了Site-To-Site VPN (IPSec Tunnel)，因此A、B兩地之間的互連是沒有問題的。但我在米家app裡為B地攝影機進行NAS設定時還是卡關了，是什麼問題呢？
…今天在RouterOS的區網中，使用app觀看小米攝影機，發現無法觀看（使用行動4G則正常），才發現RouterOS沒有開啟Hairpin NAT（NAT loopback）功能。
在參考 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）