風雲網通系統 – 強化您的企業 IT 戰力

了解資安威脅面對資安威脅處理資安防護 (NAS 篇)

工程師思路系列・事出必有因 .L0CK3D 勒索攻擊：C3RB3R（Cerber）以及 PHP2Shell 漏洞這類越來越多的事件，大力敲響了所有 NAS 廠商的資安警鐘。如果日常沒辦法做到像手機或電腦作業系統本身那樣的頻繁更新防護程度，就更難奢言「對外服務的伺服器」會有縝密資安防護的可能性。 NAS 買回來，多數人的第一個念頭是：「我出門在外，也想看到家裡或公司的檔案。」於是設定 DDNS、在路由器開幾個埠轉發，或是直接點開廠商的雲端連線服務。十分鐘搞定，方便得很。但從網路的另一端看過來，你的 NAS 只是一台「有登入頁、有版本號、有開放服務」的 Linux 伺服器。自動化掃描工具不會管你是公司還是家庭，它們只問一件事：這台有沒有已知漏洞可以用？這篇把兩件事講清楚：公開在網路上的伺服器會遇到哪些偵查與攻擊，以及只想給特定的人使用時，連線該怎麼設計。文末附上一份可以直接拿去勾的「快速自檢表」。先認識這 8 個詞，再往下讀文中帶徽章或虛線底線的術語，滑鼠移上去會顯示說明；手機沒有滑鼠提示，請看這個表，或直接跳到文末術語表。術語一句話 RCE 遠端程式碼執行。攻擊者從網路上讓你的 NAS 執行他的指令，最嚴重的漏洞類型 CVE CVSS CVE 是漏洞編號，CVSS 是嚴重度分數（0 到 10） KEV 美國 CISA 公布的「已確認被實際利用」漏洞清單 MFA 多因素驗證。密碼之外再加一道，例如手機驗證碼 VPN ZTNA 先通過一道受控的加密通道再連 NAS，NAS 本身不對網際網路開放 UPnP 讓設備自動叫路由器「幫我開洞」的功能，常在你不知情時開了門中繼原廠遠端服務的運作方式之一，連線先到原廠伺服器再轉到你的 NAS Immutable Backup 不可變備份。寫入後一段時間內，連管理員也改不了、刪不掉先講結論... » read more

Read

steven written 10 hours ago

一個早上被刷三萬台幣，原因在八個月前的一次點擊：用 Kill Chain 看懂多層防護

工程師思路系列・事出必有因一個早上被刷三萬台幣，原因在八個月前的一次點擊：單層防禦為什麼高機率被擊穿最近臉書上有一位醫師兼資工背景的工程師，公開分享了自己的遭遇：Google Cloud 帳號在一個凌晨被大量呼叫 Vertex AI，帳單暴增約三萬台幣。他花了好幾天追查，結論很反直覺：不是 API Key 外洩，不是密碼被盜，也不是 AI Agent 失控，而是八個月前就躺在他 Mac 裡的一隻資訊竊取木馬。我看完的第一個念頭不是「這個人好倒楣」，而是：這條攻擊鏈，把 Mac 換成 Windows、把 Google Cloud 換成公司信箱或雲端 ERP，一模一樣走得通。一般人聽到這種事，會想到兩招：裝防毒軟體、調瀏覽器設定。這兩招都對，但我建議再加上第三層：資安閘道器。這篇文章想說的其實很簡單：人都有疏失的時候；惡意威脅不斷提高攻擊層級、增加方法與管道；被利用的機器與程式又不休息。所以單層防禦被擊穿的機率很高。我們用這個案例，再借用資安界兩套偏理論的工具，看清楚攻擊走到哪一步、每一層守什麼，以及為什麼需要多層防護。一、事件經過（三分鐘版）時間點發生的事約八個月前為了安裝 Claude Code 上網搜尋，點進排名很前面、長得像官方的仿冒網站，疑似下載並執行了惡意檔案之後數個月電腦裡多了幾個隱藏檔與一個開機自動執行的設定，電腦照常使用，沒有任何異狀事發前約兩週雲端專案裡出現陌生的 Service Account：先有人盤點專案，幾秒內啟用十幾個 AI 相關 API，接著建立帳號並下載金鑰。當天活動紀錄有一筆來自美國的 IP 事發當天凌晨多個專案同時大量呼叫 Vertex AI。約一小時後 Google 異常偵測來信，自己設的預算提醒晚了約五小時才到，而且只通知、不會停結果關閉帳務與專案止血，向 Google 申訴後，大部分費用獲得調整減免先講清楚：以上是當事人的自述與推論。木馬的主程式已經不在機器上，所以「木馬家族」「仿冒網站就是感染途徑」「登入狀態被重放」都屬於推論，並非鑑識確認的結論。但「釣魚下載 → 竊取登入狀態... » read more

Read

steven written 1 day ago

不得不對外：NAS 公開服務的「相對安全」存取指南

工程師思路系列・事出必有因　NAS 勒索潮番外・第二篇不得不對外：NAS 公開服務的「相對安全」存取指南 Mr. τ ｜風雲網通系統｜資訊截至 2026-11-02 #NAS#Synology#遠端存取#VPN#IPsec#GeoIP#修補窗口#風險接受想像一下老闆說：「我在外面要看一下檔案。」業務說：「行事曆能不能也同步？」您明明知道這樣不安全，卻很難回他們一句「不行」。這篇不教您說不，而是教您怎麼說「好」，但更安全。 🧭 三種讀法，挑一種開始 ⚡ 30 秒只看下面的「5 句話」。 ☕ 5 分鐘 5 句話，加 30 秒自測，再看措施階梯、短中長期建議。 📖 完整版（約 29 分鐘）從第一節讀起；每節有重點框，結尾可回目錄。 ⚡ 先看這 5 句話 1 對外服務的風險不可能歸零：廠商修補前誰也縮不了，您能縮短的只有自己更新的那一段。 2 先把需求縮成四個最小：誰、用什麼服務、從哪裡、多久，通常真正非開不可的比想像少。 3 措施像一把梯子：VPN、Site-to-Site、前置驗證、直接對外加縮限；GeoIP 是濾網，不是圍牆。 4 短期一週止血、中期三個月改架構、長期把對外服務與核心資料分離；做不到就寫一頁風險接受聲明。 5 自架 Ubuntu 不是逃生口，修補窗口只是換人負責；NAS 上的 WordPress 要檢查... » read more

Read

steven written 3 days ago

NAS 勒索潮不是玄學：用「攻擊鏈」找出隘口，一關一關自檢

工程師思路系列・事出必有因 NAS 勒索潮不是玄學：用「攻擊鏈」找出隘口，一關一關自檢 Mr. τ ｜風雲網通系統｜資訊截至 2026-11-02 #NAS#Synology#L0CK3D#C3RB3R#攻擊鏈#MITRE ATT&CK#資安自檢想像一下週一早上，您打開 NAS，發現所有檔案都多了 .L0CK3D 副檔名，每個資料夾裡躺著一份 read-me3.txt。這不是科幻，是上週在各社群與論壇真實出現的畫面。如果只能提早一天知道一件事，您希望是什麼？答案藏在「攻擊鏈的隘口」裡，而且比您想的少。 🧭 三種讀法，挑一種開始 ⚡ 30 秒只看下面的「5 句話」。 ☕ 5 分鐘 5 句話，加 30 秒自測，再看決策樹總覽、逐關詳解。 📖 完整版（約 35 分鐘）從第一節讀起；每節有重點框，結尾可回目錄。 ⚡ 先看這 5 句話 1 這波災情的共通點，不是密碼太弱，而是服務從網際網路看得到、系統沒更新、攻擊發生在登入之前，所以兩步驟驗證也擋不住。 2 入侵途徑各方說法不一，但入口的「類型」很穩定，不必等完整報告就能防。 3 火力集中在五個隘口：不被看見、補洞、限縮損害、救得回、看得見。 4 最優先兩件事：收掉對外入口，並確保有一份攻擊者碰不到的備份。 5 PHP2Shell、Node.js、Tailscale 是另外幾件事，不要混為一談；NAS 上有網站（WordPress）要另外檢查... » read more

Read

steven written 3 days ago

群暉 NAS 勒索事件（L0CK3D／C3RB3R）：從疫情實況、防禦到善後

工程師思路系列・事出必有因群暉 NAS 勒索事件（L0CK3D／C3RB3R）：從疫情實況、防禦到善後作者：Mr. τ ／風雲網通系統　・　資訊更新至 2026-10-30，事件仍在發展中這幾天社團有成員反映，看到群暉 NAS 被勒索的消息，覺得受到威脅。有趣的是，原廠指出的漏洞是 2024 年底就已經修補的舊問題，攻擊卻是這個禮拜才大規模出現。這代表一件事：漏洞老不老不重要，重要的是你的 NAS 有沒有被留在那個「還沒修、又對外開放」的角落。這篇文章依序談三件事：沒中招的人現在該做什麼、不得不對外或沒辦法更新的人怎麼辦、以及萬一中招了還能做什麼。本文關鍵術語看不懂的名詞，點一下就會在術語表顯示該字卡（另開新分頁）。內文中的虛線底線詞，也都可以點。勒索軟體攻擊面（暴露面）連接埠轉送與 UPnP虛擬補丁QuickConnect多因素驗證（2FA）快照異地備份與離線備份查看本文全部術語（44 則）→ 一分鐘版本 ✔ 先封入口：關掉路由器連接埠轉送、UPnP 與不必要的對外服務，遠端改走 VPN。 ✔ 再補強系統：DSM 與套件更新到修補版本，啟用雙重驗證、停用預設帳號。 ✔ 確保能復原：快照加異地或離線備份，而且備份要讓攻擊者「摸不到」。一、先說事實：這波疫情的實況 10 月 28、29 日起，大量群暉用戶回報檔案被加密，Synology 在 10 月 29 日發布聲明證實。症狀很好認： ✔ 檔案副檔名變成 .L0CK3D（或 .LOCK3D，是數字 0 和 3） ✔ 每個資料夾出現 read-me3.txt 勒索信，指向 Tor... » read more

Read

steven written 6 days ago

不續約防火牆資安服務後 …

資安｜防火牆｜ Windows 內建防護｜ Pico-UTM 100 ｜ ZYXEL USG FLEX 200 作者：Mr. τ ／風雲網通系統　·　2026-10-27 不續約防火牆資安服務後，電腦與瀏覽器的內建防護能支撐「已知威脅」，支撐不了「網路設備被直接攻擊」和「事後沒有紀錄」。風險升在網路入口與設備這兩處。 ✔ 可以勉強支撐：已知的釣魚與惡意網站、已知的惡意檔案、本機的勒索行為偵測。前提是 Windows 有更新、Defender 與 SmartScreen 都開著。 ✔ 照顧不到：NAS、伺服器與舊設備被直接攻擊、手機與訪客、郵件的第一層過濾、自動隔離、集中的網路紀錄。 ✔ 該做的事：到期前匯出報表與日誌、提醒同仁、確認備份與更新，再決定繼續續約、加裝 Pico-UTM 100，或先觀察。 Pico-UTM 100 對應 FLEX 200 的網址、攻擊、病毒三層，但沒有應用程式管控、垃圾信過濾與自動隔離，詳見對照表。背景防護依賴：沒出事，不代表沒有東西被擋防護成功的時候，使用者什麼也看不到。用了幾年之後，同仁自然把「沒事」當成理所當然，不知道網路入口有一層檢查一直在運作。這會默默養鈍風險敏感度：信件看起來正常就打開，連結看起來正常就點，因為過去點了也沒發生事。真正的原因不是「那些連結都安全」，而是「那些危險連結在到達電腦之前已經被擋掉」。防護服務到期後，行為習慣不會跟著改變，這段空檔最危險。同仁仍照「有防護」的習慣操作，而防線已經少了一層。所以不續約的第一件事，是讓同仁知道「以前有人在擋，現在沒有了」。 FLEX 200 與 Pico-UTM 100 功能對照核心的網址、攻擊、病毒三層，Pico-UTM 100 都有對應；差在 Pico-UTM 沒有應用程式管控、垃圾信過濾與自動隔離。防護面向 ZYXEL... » read more

Read

steven written 1 week ago

外掛式資安服務與資安閘道器的位置差異

工程師思路系列・事出必有因企業訂閱電信業者的資安外掛服務（例如中華電信資安艦隊），是好消息。對供應鏈資安查核而言，這是一項具體的邊界防護佐證。但外掛服務擺在業者端，和擺在公司內網入口的設備，看到的東西並不一樣。這篇文章用「位置」來說明兩者的差異與搭配。圖：兩類佐證各自回答不同的查核問題。本圖為架構說明，不構成任何合規認證。外掛式服務（中華電信資安艦隊這類）的優點與位置界線優點：不必自行維護設備，且在網路業者端先行攔阻已知威脅，減少帶威脅的流量進入公司。服務範圍界線則是位置：設備位於業者端，看到的是企業防火牆送出的連線，通常以單一公網位址呈現。若某條連線有疑慮，較難進一步指出是公司內部哪一台電腦或設備發起的。簡單地說資安艦隊這類服務，在外面把火勢擋下來，但看不出是公司內網哪一台設備一再點火。圖解：方案擺放位置不同，帶來不同效果圖：兩種方案擺放位置不同，看到的內容也不同。下方示意圖再把位址轉換（NAT）的邊界標出來。位址轉換前：公網側位址轉換後：內網側網際網路 → 中華電信資安艦隊外部邊界防護 → 防火牆路由器／閘道 ⇢ Pico-UTM 100 內部行為可視 → 主交換器 → 內網設備電腦・伺服器・AP NAT 邊界資安艦隊的觀察範圍進出口流量，通常以單一公網位址呈現 Pico-UTM 100 的觀察範圍名稱解析與對外連線，可對應到個別設備資安艦隊在位址轉換之前，Pico-UTM 100 在位址轉換之後。放在防火牆之後，才有機會分辨每一台設備。資安閘道器補上的位置資安閘道器（Pico-UTM 100）串接在防火牆與主交換器之間，是全公司設備對外連線的必經位置：防火牆 → Pico-UTM 100 → 主交換器 → 全公司電腦與設備（內部網路）內部網路這一區是日常行為與異常最常出現的地方，也是需要公司與維運方持續跟進改善的地方，但是並不在外掛式服務（資安艦隊這類）的服務範圍內。內網常見的兩類弱點 1 使用者端的資安風險意識。同仁一時閃神點到釣魚連結，或安裝來路不明的軟體，是資安事件最常見的起點之一。 2... » read more

Read

steven written 1 week ago

續篇：我們努力過了——請 AI 助理陪我探查舊 NAS 的真實環境

工程師思路系列・事出必有因續篇：我們努力過了——請 AI 助理陪我探查老舊主機的真實環境 Mr. τ ｜風雲網通系統｜ 2026-10-22 昨天那篇談的是「更新不動、換機不實際、放著不管、廠商不扛」四道難題。有人問我：你說得頭頭是道，那你自己的呢？這篇就是交代。我沒有憑印象下結論，而是請 AI 助理陪我確認一台對外主機的實際狀況。為了不替別人提供地圖，這篇刻意不寫品牌、型號、版本、位址與路徑，只談做法和結論。一、我是怎麼做的流程：AI 助理擬出唯讀指令，我貼到主機上執行，再把輸出貼回去讓它判讀。它自己能做的，只有從外網做最基本的連線測試，只看回應狀態。它一度想直接遠端登入，驗證失敗後就停手，沒有重試，也沒有猜密碼。檢查指令本身都是唯讀的。唯一的設定變動，是我為了檢查而暫時啟用了一個高權限帳號【請確認：檢查後是否已停用並更換密碼】。二、查到什麼 1 平台沒有修復路徑（以我的系統版本而言）。這台機器已升到它能升的最後一版系統，而平台提供的執行環境選項，全都停在已終止支援的舊分支，沒有任何一個落在官方的修復線上。這不是我忘了更新，是平台已經沒路了。 10/23 補充：設備廠商後來針對較新的系統版本發布了 PHP 更新，所以是否有修復路徑，取決於你的系統版本；較舊或已終止支援的系統仍沒有直接的路。【請依自己實際的系統版本確認：是否在廠商更新涵蓋範圍內】 2 PHP 實際被誰用。對外的網站只用到單一一組執行環境。同一台機器上另有少數附屬套件各自帶有執行環境，網站目錄裡也堆著多年累積的舊專案與測試檔。 3 對外曝露。網站前面有 CDN，從正式網域測試未使用的管理介面，回應是找不到。但來源主機的另一個入口上，仍有一個沒在使用的管理介面入口沒有來源限制，只要有人知道來源位址就可能連到。另外，我從外網確認有少數不該公開的檔案可以直接下載。漏洞公告逼你檢查，而檢查常常先翻出自己留下的爛攤子。 4 入侵跡象。我掃描了常見的後門特徵，也檢查了使用者上傳區：沒有命中。近期被修改的程式檔，我還在確認是否都出自我自己的更新。另有少數項目因為權限問題，檢查帳號讀不到；我查了擁有者、權限和內容開頭，判斷是我自己先前測試時留下的，網站程式本身也讀不到它。所以「沒有發現入侵證據」只涵蓋上述這幾項，不等於「沒事」。 5 順手發現的雜物。網站程式本身落後多年；附加元件很多，我還沒逐一確認哪些有啟用、哪些仍在維護；有些檔案的權限開得過寬；網站目錄裡有開發測試殘留。這些在多數老站都很常見，建議你也逐項檢查。三、同一台機器上別的套件呢？給也在用類似設備的讀者：不是每個套件都共用網頁服務的 PHP。我順便查了郵件類套件：執行中的行程和相依項目裡都沒有 PHP，所以在我這台機器上看不到它們使用 PHP 的跡象。10/23 補充：廠商公告提到部分郵件類套件需要手動更新，不同廠商、不同套件的實作不同，請以自己設備的公告為準。【請確認自己使用的郵件套件是否在受影響清單內】但有些套件會自帶獨立的執行環境，改網頁服務的設定改不到它。這只代表我這台機器，你的情況請自己查。四、今天的新情況 ✔ 攻擊活動變多了。據報導，雲端業者的蜜罐最早在 10/17 就觀察到攻擊嘗試，PoC 公開後嘗試快速增加。相對地，資安廠商在 10/21 的報告裡寫的是尚未獨立確認有大規模利用。兩者其實只是時間差，而且講的都是「嘗試」。我仍未看到可靠證據確認有網站被成功入侵，但風險已從「可能被利用」變成「正在被大量嘗試」，所以日誌建議至少從 10/17... » read more

Read

steven written 2 weeks ago

NAS 架站的四道難題：更新不動、換機不實際、放著不管、廠商不扛，然後呢？

工程師思路系列・事出必有因 NAS 架站的四道難題：更新不動、換機不實際、放著不管、廠商不扛，然後呢？ Mr. τ ｜風雲網通系統｜ 2026-10-21 晚間今天（10/21）PHP 官方釋出緊急安全更新，修補兩個 CVSS v4.0 評分 9.2 的遠端程式碼執行漏洞（代號 php2shell，CVE-2026-109618、CVE-2026-109619）。WordPress 核心的 CVE-2026-87902 則早在 9/22 就已修補，並已被美國 CISA 列入「已知遭利用漏洞」清單。這篇不是漏洞通報，我已經另外在社團發過。我想談的是：當你的網站架在一台更新不動的 NAS 上，到底該怎麼辦。一、這不是你一個人的問題我自己的官網，最早是一台自己安裝套件的 PC Linux 主機。後來考慮到費電，改用 NAS，前後換過兩代。每一步都合理：省電、省維護、快速上線。大家平常都忙著日常工作，建站這件事，本能就會挑「懶人包」。就算本職是工程師，也一樣：能省時間的 Appliance，就用 Appliance。但 Appliance 賣的是「不用自己維護」，這個承諾有一個隱含條件：廠商要持續維護。型號老舊、原廠不再支援的那天，承諾就消失了，而網站還掛在外網上，沒有人通知你這個條件已經不成立。二、為什麼更新總是被拖更新的成本是現在就要付的： ✔ 先備份網站、資料庫、系統與設定 ✔ 嘗試升級，失敗要能退回 ✔ 就算成功，可能還要轉換一些設定與規格檔案更新的回報卻是看不見的：做好了，什麼都不會發生；沒做，也往往很久都不會出事。所以只有兩種情況會認真做：有人付維護費，或是出事之後。有維運責任的工程師，其實都不想碰這件事，但早晚會遇到。這是痛點，不是疏失。三、四道難題把處境攤開，會發現是四個條件互相卡住： 1 NAS 的網站功能好用，會繼續用。內建功能方便、上線快，沒有理由放棄。... » read more

Read

steven written 2 weeks ago

沒料到的隱藏路由器：一次韌體更新，揪出區網裡的小天地

工程師思路系列・事出必有因沒料到的隱藏路由器：一次韌體更新，揪出區網裡的小天地原廠來信說有新版韌體，修了兩個 CVE，建議客戶盡速更新。我照做了，幾家客戶都順利過關，只有一家，更新完就從我的 CMS 設備清單裡消失了。接下來的追查，讓我發現這家企業的區域網路裡，還躲著一台沒人記得的 IP 分享器。起因：一封原廠通知信那天檢視 E-Mail，看到原廠通知：Pico-UTM 100 推出新版本，解決了兩個 CVE 資安問題，建議客戶盡速更新。我替一些客戶安裝建置了 Pico-UTM 100，也透過原廠提供給經銷商夥伴的 Lionic CMS 系統管理它們。只要在客戶端的 Pico-UTM 100 填入敝公司的 CMS 主機資訊，就能持續看到企業端推播過來的資安紀錄與統計資訊。這對於協同客戶一起了解企業面臨哪些網路資安威脅，是很好的輔助設計；CMS 也包含了「對企業端 Pico-UTM 發起韌體更新要求」的功能，這次就派上用場。 📌 補充：Pico-UTM 100 擺在哪裡？為什麼它的「WAN 端」是內網 IP？（點此展開） Pico-UTM 100 是單 WAN 埠、單 LAN 埠的結構，常見擺放位置在路由器（防火牆）與主交換器之間。這個樞紐位置，可以同時看到全內部網路的電腦與設備，以及它們與網際網路之間的連線情況。這樣擺放時，會採用原廠所稱的「橋接模式」，也就是一般網通廠說的「透通模式」。要注意的是，雖然介面上寫著 WAN / LAN 字樣，但在這個架構下，Pico-UTM 100 的 WAN 端 IP，被設定派發的仍是原本內網區域網路的網段，主要是方便內部網路管理者在同一網段就能直接管理這台資安閘道器。至於設備預設的 LAN 網段，則是比較少見的... » read more

Read

steven written 2 weeks ago

從氣冷極限到後 3M 時代：解密 AI 伺服器散熱的物理限制與商業博弈

工程師思路系列・事出必有因從氣冷極限到後 3M 時代：解密 AI 伺服器散熱的物理限制與商業博弈作者：Mr. τ ／風雲網通系統隨著生成式 AI 與大型語言模型的爆發，AI 晶片的功耗正以恐怖的速度飆升。當單顆 GPU 的功耗跨越 1000W 大關、單一機櫃發熱量衝破 120kW 時，散熱技術已經不再是硬體的「附屬品」，而是決定 AI 算力能否完整釋放的核心關鍵。 💡 本文要回答的問題許多科技影片都說「氟化液浸沒式散熱比傳統氣冷強 10 倍」。這在物理上是如何辦到的？既然如此強大，為何當前的 AI 機房依然以局部水冷（冷板式）為絕對主流？本文從物理特性、成本效益、應用場景與風險控制，全面拆解這場散熱革命。一、氣冷（風冷）的「物理天花板」傳統資料中心依賴風扇帶動空氣流動，配合機房冷氣進行解熱。然而，風冷系統存在著無法跨越的物理極限： ✔ 單櫃解熱上限：工程實務上，傳統氣冷機櫃的散熱極限普遍落在 15 ~ 25 kW。即便透過極致的氣流優化與後門熱交換器（RDHx），頂多也只能勉強推至 30 ~ 40 kW。超過這個範圍，熱點（Hot Spot）累積與風扇自身的功耗將會急劇上升。 ✔ 物理性質的孱弱：空氣的熱傳導與帶熱能力天生弱勢。常溫下的比熱容僅約 1.0 kJ/kg·K，且體積熱容極低，這意味著要帶走相同的熱量，需要極為龐大的風量。 ✔ 能源與噪音代價：為壓制高功耗晶片，風扇必須拉高至上萬轉。這不僅帶來如同飛機場般的機械振動與噪音，更使資料中心的 PUE（電力使用效率）高達 1.3 ~ 1.8，大量電力被白白浪費在「吹風扇」與空調上。當前主流的 AI 伺服器機櫃（如... » read more

Read

steven written 2 weeks ago

三顆基地台同時拿不到 IP：「重開就好」其實是最貴的答案

工程師思路系列・事出必有因　#DHCP　#無線基地台　#路由器汰換　#Nebula　#SMB IT 三顆基地台同時拿不到 IP：「重開就好」其實是最貴的答案一個住家網路的小事件，從現象判讀、根因推論，一路走到下一台閘道器怎麼選。今天收到客戶訊息：家裡各房間的三顆 ZYXEL NWA50AX 商用基地台，忽然全部拿不到 IP，燈號綠、橘交替閃。但同一時間，有線連接的電腦都能正常上網。客戶自己的推論很有道理：基地台半夜自動更新韌體或重開，醒來後向 ASUS RT-AC66U 要 IP，路由器卻沒有發放。重開 RT-AC66U 之後，一切恢復正常。事情就這樣結束了嗎？對客戶來說是。對工程師來說，「重開就好」只是止血，還沒有回答「為什麼」。一、先把現象讀對觀察我的判讀 AP 燈號綠橘交替 AP 本身正常開機，卡在「等 DHCP」這一步有線電腦正常上網電腦手上還有舊租約，沒到續約時間，不代表 DHCP 服務是好的重開 RT-AC66U 後恢復問題在路由器端（服務卡死、記憶體、過熱），不在 AP 端關鍵觀念：「有線電腦能上網」是最容易讓人誤判的證據。DHCP 只在「要 IP」和「續租約」的瞬間才被考驗；已經拿到 IP 的設備，在租約期內完全感覺不到 DHCP 服務已經死了。三顆 AP 同時重開、同時要 IP，才讓問題一次暴露。二、根因推論：四個嫌疑犯誠實聲明：這次重開前沒有留下 log，所以下面是推論，不是定論。工程師最怕把「合理的猜測」寫成「確定的原因」。 1 散熱不良。這台路由器放在家庭輕鋼架上，距離天花板很近，天花板附近是熱空氣積聚處。老機長期高溫，最典型的症狀就是「跑久了怪怪的」。 2 長期不重開導致服務卡死。路由與 NAT 還在轉發，但發放... » read more

Read

steven written 3 weeks ago