公司換了新鎖，結果連負責開門的人都進不去

想像公司全面更換門禁。
新鎖裝好了，管理員卻刷不進去。
主管說：
「那叫資訊部門進來修啊！」
「資訊部門也在門外。」
……
安全措施非常成功。
連負責修理的人，都被擋在外面了。

最近我持續開發 Rulemoor，一個管理遠端 Linux 防火牆變更的實驗性服務。
它想處理的問題是：
修改規則之後，管理通道還在嗎？如果出問題，又靠什麼恢復？

預檢：先攔下已知的管理入口阻擋

第一步，是在變更前檢查。
Rulemoor 可以選擇啟用管理埠預檢，評估候選政策是否會阻擋事先宣告的 IPv4／IPv6 本機 TCP 管理埠。
已知自有政策會擋住的，就先拒絕新變更。
外部 nftables 規則則只讀取、診斷，不擅自修改。無法確定的條件保留為風險，不把「沒看出問題」當成「保證連得上」。

確認：換鎖後，重新刷卡進來

第二步，是套用之後重新確認。
變更有確認期限，而且必須透過規則套用後建立的新 TLS 管理連線確認。
因為舊連線還活著，不代表新連線進得來。
就像主管坐在辦公室裡說：
「我還在裡面，代表新門禁正常！」
工程師問：
「那你出去，再刷卡進來看看？」
「為什麼？」
「因為你是在換鎖之前進來的。」
突然，大家都不想當第一個出去的人。

明確啟用雙協定模式後，IPv4 和 IPv6 都要分別確認，變更才會提交。
只有一邊成功，不能替另一邊背書。這也只證明被測試的管理路徑，不代表所有來源與服務都正常。

復原與 Boot Guard：先核對政策，再啟用介面

第三步，是在故障條件下驗證復原。
沒有完成確認，仍在運作、負責變更與復原的管理程式（Agent）會嘗試恢復前一份政策。必要的已知基準政策復原，不應被新變更的管理埠准入檢查卡住；原本的狀態與權屬檢查仍然保留。
這次新增、可選擇啟用的 Boot Guard，則在支援的隔離網路配置裡，先執行復原、核對日誌與兩邊防火牆規則，再啟用指定介面。

但測試找到的缺陷，出現在關閉流程。
原本程式先寫入「正在關閉」的狀態收據，再執行介面關閉。
如果收據寫入失敗，後面的關閉命令就可能沒有執行。

就像警衛準備緊急關門。
流程卻要求先填事件報告。
偏偏表單系統故障。
主管問：「為什麼還沒關？」
警衛說：「報告送不出去。」
……
原來緊急關門，也要先等文書核准。

修正後，收據寫入失敗仍會讓服務回報失敗，但不能跳過關閉嘗試。
在安裝正式服務的 Linux VM 裡，我刻意把收據目的位置換成目錄，製造 EISDIR 寫入錯誤。
受測的清理與停止流程仍執行關閉命令，並讀回介面已 DOWN。

不過，「有嘗試關閉」不等於「一定關閉成功」。
若介面操作本身失敗，仍可能需要本機救援。舊的 OPEN 收據也可能留下，因此必須查實際狀態，不能只看上一次成功紀錄。

其他受控驗證包括：在介面啟用前後終止 Boot Guard，以及正常 VM 重開機後，分別恢復待確認變更的基準政策與已提交政策。
仍存活的舊執行程序，也必須先終止並確認退出，再接受新變更。

證據範圍與限制

目前同一份來源的 macOS 與 Linux 各通過 132 項測試，另外完成 12 個實際 Linux VM 驗證階段。
但 Boot Guard 目前只支援指定命名空間、由它獨占啟用權的靜態 veth 介面。
這不是一般實體網卡或全主機開機零空窗的保證。突然斷電後的復原，也尚未驗證。

這 12 個 VM 階段包含安裝設定與清理，使用實際 systemd 執行安裝後的正式程式；不是把先前不同來源版本的驗證組數累加。

實際 VM 的 EISDIR 是把收據目的位置換成目錄所造成的寫入錯誤；跨平台測試另外在收據寫入邊界注入 EIO／ENOSPC／EROFS，沒有在 VM 驗證真實磁碟耗盡或突然斷電。介面命令失敗的注入情境曾維持 UP／FAULTED，之後才經本機救援關閉；測試通過不代表每種故障都能關閉。

Boot Guard 在 UP 前執行復原與政策讀回，啟用後再核對介面與政策；啟用後的受控終止仍存在開啟時窗，不是所有故障的零空窗保證。它不涵蓋實體網卡、一般網路管理器、DHCP／SLAAC、WAN 或任意特權程序。

舊 Executor 先退場，才接受後繼政策。後續讀回與網路探測是有限時段的取樣，不是持續監控，也不能排除每次讀回之間的所有暫態變化。

部署前，先決定誰能接手

對我而言，這些實驗最後回到同一個部署決策：
我們承諾保留哪些管理能力？
哪些故障由系統自動處理？
自動復原無法完成時，由誰透過什麼獨立路徑接手？

預檢結果、確認收據、程序重啟，都各自提供一部分證據。
真正需要驗收的，是整條流程能否在承諾處理的故障下完成，以及剩下的限制是否已進入維運計畫。