jt-ipam IP 變更評估：改址影響分析與審核

Jason Cheng 發布 2026.11.04 瀏覽 1 次

本文目錄

功能概要
示範情境
建立評估
分析結果
關係圖
證據與資料不足
待辦與復原
AI 解說
匯出報告
審核流程
維護與結案
權限與稽核
適用範圍
結論
參考資料

替一台伺服器換 IP，動手只要幾分鐘，麻煩的是事後才發現的那些地方：DNS 的 A 記錄改了、PTR 忘了改；防火牆的別名還寫著舊位址；監控還在 ping 舊 IP；TLS 憑證裡登記的還是舊 IP，用新 IP 連線就會出現憑證錯誤；Wazuh 代理用固定位址註冊，改完就連不上管理端。

新位址也不一定真的是空的。IPAM 上顯示可用，實際上可能已經有新接上去的設備在用，或是服務台剛替別人申請了同一個位址。這些資訊分散在 DNS、防火牆、監控、虛擬化平台好幾套系統裡，靠記憶與 grep 總會漏掉一兩個，而出問題的時間點通常是半夜的維護時段。

變更審核也有同樣的問題：主管手上多半只有一張變更單，看不到實際有哪些設定引用了這個位址，也沒辦法逐項確認。

jt-ipam 的「IP 變更評估」就是為這件事設計的：改 IP 或除役設備之前，先把所有引用到它的地方一次列出來，判斷哪些會擋住、哪些要改、哪些資料不足，產生待辦與復原步驟，再走送審、覆核、執行、驗證、結案的流程。這篇以 v1.0.18 的實際畫面，示範一次 ERP 資料庫改址的完整過程。

功能概要

IP 變更評估從 v1.0.2 開始提供，預設關閉，要在系統設定裡打開。它有一個很重要的前提：整個評估只讀取已經同步進 jt-ipam 的資料，不會連到任何設備，也不會修改任何設定。評估本身不需要任何設備的寫入權限，產生的待辦也都是人工操作清單。

四種評估情境

IP 改址
舊位址被誰引用、新位址有沒有衝突（本文示範的情境）
裝置除役
裝置與名下 IP 的所有引用、還在跑的虛擬機、佈線與電源
交換器維護
只接這台交換器的裝置列為「模型內中斷」，有備援的列為「備援待驗證」
節點停機
虛擬化節點停機時會停的 VM 與受影響的服務，分成直接停機、先遷移、交給 HA 三種模式

讀取的資料來源

評估時用的都是各整合已經同步進來的資料：

IPAM
IP 記錄、IP 申請（待審核或已核准）、IP 範圍、冷卻期、子網路閘道與 DNS 設定
DNS
A、AAAA、PTR 記錄，經過多層 CNAME 指過來的別名，以及 AdGuard 觀察到的 DNS 改寫；同一個 DNS 比對群組裡相同的記錄合併成一項
DHCP
保留、租約與發放範圍（Kea、ISC DHCP、Windows DHCP、Technitium、ISOinsight 與各家防火牆的 DHCP）；Technitium 與 Check Point Gaia 另外比對範圍發給用戶端的閘道與 DNS
防火牆與 NAT
OPNsense、pfSense、FortiGate、Palo Alto、Check Point、MikroTik 的規則、別名與位址物件，以及 NAT 規則（pfSense 同步進來的 port forward 也會比對，但 pfSense 不算 NAT 來源，環境裡沒有其他 NAT 來源或手動建立的 NAT 時不會檢查 NAT）
監控與資產
Zabbix、LibreNMS、Wazuh（包含用固定位址註冊的代理）、OCS Inventory、RustDesk
虛擬化
Proxmox VE、VMware ESXi、Hyper-V、OpenStack 與 CubeCOS 的 VM 網路卡位址；Proxmox VE 的 LXC 設定裡寫死的固定 IP 會列為「需變更」
電路與實體
電路關聯的 WAN 位址；裝置除役時另外檢查租用設備（提醒歸還）、IP 頁對外路徑上手動插入的中間設備、機櫃、佈線與電源
憑證與服務
登記了這個 IP 的 TLS 憑證（憑證裡有一個 SAN 欄位，列出這張憑證可以用在哪些網域名稱與 IP）；在「IP 變更評估 > 服務」登記的服務端點與依賴關係
jt-ipam 自己的設定
跳板主機、整合的連線位址、LDAP、SMTP、LLM 等系統設定，以及其他記錄的說明或備註裡提到這個位址的文字

結果的分類

每一項影響會歸到三種處置之一：

阻擋
已有衝突或佔用的證據，必須先查明並排除，系統不允許核准，例如新位址已經配發、掃描代理或 ARP 看到有設備在用、有 DHCP 租約或保留
需覆核
需要修改或確認的引用，審核人必須逐項選擇處置
參考
知道就好的項目，例如防火牆規則用整段網段涵蓋了新舊位址

每一項另外標示影響程度（可能中斷、需變更、未知、僅有引用等）、嚴重度與證據強度（明確、多來源佐證、推定）。

沒接的整合、太久沒同步的來源、權限看不到的範圍、還沒建模的項目（例如 DNS view），會列在「資料不足」。看不到的地方不會被當成沒有影響，這一點對審核的人特別重要。

示範情境

示範用的是虛構公司：ERP 資料庫 erp-db-01（198.51.100.21）要搬到新規劃的位址，維護時段是 11/14 22:00 到 24:00。網域 example.net、位址屬於 RFC 5737 的文件保留網段，文中的人物姓名也都是虛構的：

網管「陳志明」：建立評估、送審、執行
資訊主管「林雅婷」：指定的審核人
服務台「吳家豪」：先前替 3F 新事務機申請了 198.51.100.121

整合的同步資料是直接寫進示範資料庫的，分析結果、關係圖、審核流程、通知與 AI 解說則是系統實際跑出來的。

這台資料庫牽動的東西不少：兩台 DNS 上的 A、PTR 與 CNAME 別名，防火牆的位址物件與三條規則，一條 NAT 轉發（會計師事務所的報表系統從外部連進來讀資料），Zabbix 與 LibreNMS 兩套監控，用固定位址註冊的 Wazuh 代理，OCS 資產盤點，Proxmox VE 的虛擬機網路卡，一張登記了這個 IP 的 TLS 憑證，「ERP 系統」服務登錄，還有另一台應用伺服器的說明欄寫著這個位址。

事前狀況：服務台已替 3F 新事務機申請 198.51.100.121，申請還在等待中

建立評估

IP 頁右上角的「改址評估」就是入口；裝置頁有「變更評估」，左側選單也有「IP 變更評估」的清單。

198.51.100.21（erp-db-01）的 IP 頁，右上角「改址評估」是入口

在新增評估視窗填入新 IP、標題與預定維護時段，按「建立並分析」。視窗下方也寫明了：只讀取 jt-ipam 已同步的資料，不會連到任何設備。

新增評估：新 IP 先填 198.51.100.121，維護時段 11/14 22:00 到 24:00

分析結果

分析完成後，頁首列出決策狀態、完整性、阻擋數、需覆核數與資料不足數。這一次的結果是阻擋 1 項、需覆核 14 項（其中需變更 10 項）、資料不足 5 項。最上方固定有一行「這是評估結果，尚未執行任何變更。」

分析結果有有效期限，預設 24 小時（可在 1 到 168 小時之間調整），過期就要重新分析才能送審、核准或開始維護，避免拿幾天前的資料做決定。

影響清單

影響清單共 21 項，每一項有處置、嚴重度、類別、物件與原因、影響、證據強度。原因是一句白話，例如「fw-hq 的規則在目的直接寫了 198.51.100.21」。

排第一的就是阻擋項目：掃描代理最近在 198.51.100.121 看到一台設備（3F 的新事務機已經先接上網路）。服務台對同一個位址還有一筆尚未處理的 IP 申請，這一項另外列為需覆核。

影響清單：阻擋、TLS 憑證、防火牆位址物件與規則、IP 申請、Wazuh、ERP 服務、DNS、NAT、監控等 21 項

展開任一列可以看到證據：觀察時間與收錄時間分開列，也列出套用的規則版本，方便事後追查當時為什麼這樣判斷。

關係圖

影響清單適合逐項處理，關係圖則用來看整體：中間是評估目標，周圍是引用它的物件，箭頭由引用的一方指向被引用的物件。

四種排列方式

右上角可以切換四種排列：

分層
依影響一圈一圈往外排，最內圈是可能中斷，接著是需變更、未知、僅有引用，每一圈的標題寫數量
自動排列
依關係自動推開，關聯多的物件會聚在一起
放射
評估目標在中心、物件平均放射排列，物件很多時適合看全貌
樹狀
由左往右的卡片，每條線上直接寫關係，最適合放進報告或簡報

分層排列：阻擋的「使用跡象：198.51.100.121」畫紅框，同類物件收成「防火牆規則（3）」「DNS 紀錄（3）」

分層排列一眼就能看出嚴重的項目在哪一圈。阻擋項目另外畫紅框，就算混在其他節點之間也很明顯。

群組與展開

同一類、連到同一個物件的節點會收成一組，例如「DNS 紀錄（3）」「防火牆規則（3）」，圖面才不會一下子塞滿。按「展開所有群組」就把每一筆攤開，示範情境的樹狀圖從 14 張卡片變成 18 張，四種排列都可以展開。

展開後的樹狀圖，每條線上都寫著關係：「新位址目前有設備在用」「IP 申請要求」「憑證的 IP SAN 包含」「DNS 紀錄指向」「防火牆規則涵蓋」「NAT 轉送到」「監控目標」「說明或備註提到這個位址」等。

顏色與線條

節點顏色代表影響：模型內中斷、備援待驗證、可能中斷、需變更、僅有引用。線條也有區分：

粗線：對方停機時，這個也會中斷
細線：設定裡寫著這個位址，改址時要跟著改
虛線：推定的關係

節點卡片

點任何一個節點，其他節點淡出，只留它和評估目標之間的線，右邊出現卡片，內容有物件類型與影響、為什麼列出來、相關物件、證據來源與時間。卡片下方的「開啟原始物件」會開啟 jt-ipam 裡那條 NAT、那張憑證或那台虛擬機的頁面；設備上的實際設定仍要到防火牆、虛擬化平台等來源系統修改。

NAT 轉發的卡片：NAT 對應的目的是這個位址，「開啟原始物件」會開啟 jt-ipam 裡的 NAT 頁面

群組節點的卡片會列出組裡的每一筆與各自的影響顏色，並提供「在圖上展開」。

文字線索是很容易漏掉的一類。示範情境裡，另一台應用伺服器的 IPAM 記錄說明欄寫著 198.51.100.21，關係圖用虛線畫出來，交給人判斷要不要處理。

右下角的縮圖可以拖曳移動，「符合畫面」一鍵縮放到全部看得到。關係圖也可以匯出 PNG 或可編輯的 SVG，放進變更單或簡報。

證據與資料不足

「證據與資料不足」頁籤先列資料不足的項目，再列證據清單。證據的來源會寫到是哪一台，例如「DNS · corp-ns1」，並附觀察時間、收錄時間與時效。

示範情境沒有設定 DHCP 與 NAT 類的整合，系統就明確寫出「沒有納入觀測，不代表沒有依賴」；DNS view 與 split DNS 也列為尚未建模。

待辦與復原

系統依分析結果自動產生待辦，分成四段：

前置
確認新位址、確認受影響物件與維護時段、備妥原設定與復原通道；新位址的衝突會掛在「確認新位址」底下
變更
修改設備位址，再依類別更新引用：憑證、DNS、防火牆、監控、NAT、服務。這是分類清單，實際先後依環境安排；DNS 有快取，要縮短 TTL 得在維護前提早調整
驗證
驗證新位址的連線、DNS 與服務（只有 ping 不算完成），重新分析確認沒有遺漏的舊引用
復原
出問題時改回舊位址並還原已修改的引用

每一項可以設定待處理、進行中、完成、受阻、略過，也可以自己新增待辦，例如系統看不到的應用程式設定：資料庫的監聽位址、ERP 的連線字串。這些都是人工操作的清單，標成完成不會修改任何設備。

AI 解說

AI 解說頁籤有「產生摘要」「草擬待辦」「逐項解釋」三個按鈕，也可以直接提問，例如「哪些項目擋住了核准？」。

AI 的回答只根據這份結果，而且只用目前使用者有權限看的部分；影響程度與是否阻擋一律以分析引擎的判斷為準，AI 不能改寫。回答會附上引用的項目編號，系統會檢查這些編號確實存在、使用者也看得到，可以對回影響清單；文字裡提到的 IP 必須出自資料。回覆格式不符時，系統會請模型修正一次，仍不符就改用範本摘要。草擬的待辦可以勾選後存進計畫。

AI 解說：藍色標籤是引用的項目編號，草擬的待辦可以勾選存進計畫（區網 Ollama gemma4:26b，文字為模型原樣輸出）

示範用的是區網自架的 Ollama（gemma4:26b），資料不會送到外部雲端服務。截圖裡的文字是模型實際產出的內容，沒有修飾，所以也看得出模型的摘要不一定完全精準，判斷仍要回到影響清單與證據。

匯出報告

匯出選單分三類：

報告
PDF、Word、OpenDocument，內容有基本資料、AI 摘要（有產生過才有）、影響清單、資料不足的項目、分段的待辦與覆核紀錄
表格
Excel、OpenDocument，分成影響清單、資料不足的項目、待辦、證據四個工作表
原始資料
Markdown、JSON，適合自動化處理或存檔

匯出內容只包含下載者目前有權限看的部分，每次匯出都會寫入稽核記錄。

審核流程

審核設定

審核人在「申請審核設定 > IP 變更評估審核」設定，有五種模式：對評估目標有修改權限的人（預設）、僅系統管理員、系統管理員加上指定的使用者或群組、多組會簽、依序多關卡。示範用的是指定資訊主管為審核人。預設不允許建立者覆核自己的評估，但系統管理員不受這項限制。

第一次送審：退回修改

網管按「送審」時，確認視窗會列出將通知哪些審核人，審核人會收到「IP 變更評估待覆核」的通知。

主管打開覆核視窗，系統直接說明這次分析有阻擋項目，不能核准或接受風險，這兩個選項反灰，只能退回修改或駁回。退回修改會讓計畫回到草稿，駁回則會直接取消計畫。主管選「退回修改」，理由寫明 .121 已經被新事務機用掉，請改用 198.51.100.122。

計畫退回草稿後，網管打開計畫頁，最上方就是黃色提示：誰、在什麼時候退回、完整的理由。

修改計畫與重新分析

網管編輯計畫，把新 IP 改成 198.51.100.122。修改計畫會產生新版本並回到草稿，舊的覆核自動失效，必須重新分析、重新送審。

第 2 版的分析沒有阻擋項目了，剩 13 項需覆核，退回理由仍保留在頁面上方。

第二次送審：逐項處置後核准

主管在覆核視窗逐項選擇處置：會修改、不需處理、待負責人確認，並寫下核准理由。

完整性看的是來源有沒有過期、同步失敗或權限受限；沒接的整合、尚未建模的項目只列為資料不足，不影響完整性，所以第 1 版有 5 項資料不足仍是「完整」。

第 2 版的完整性是「部分」，資料不完整時只能選「接受風險後核准」，而且一定要填理由（至少 5 個字）。另外，審核人如果有看不到的需覆核項目（例如只有管理員看得到的 Wazuh 或憑證），也不能核准，要由看得到全部的人處理。

維護與結案

核准之後，按鈕變成「開始維護」。開始維護時，系統會先重新分析一次，證據跟核准時一致才放行；不一致時計畫會退回草稿、要求重新分析，不會拿過期的核准去做事。

這裡比對的是 jt-ipam 已同步的資料，開始維護前要先確認相關整合都已完成同步。開始維護時用的分析結果一樣受 24 小時有效期限限制，核准後拖太久才維護，就要重新分析、重新覆核。

維護期間照待辦逐項完成，驗證階段的待辦都完成或略過（略過要填理由）之後，才能按「完成驗證」，最後按「結束」，計畫狀態變成「已結束」。略過的項目不代表驗證通過，結案前要確認每一項略過的原因。

示範為了呈現完整流程，核准後就直接開始維護，沒有等到 11/14 的維護時段，也沒有實際修改設備。

結案後，「歷史」頁籤留著完整記錄：兩次分析、兩筆覆核（退回與核准，含時間、審核人、版本與理由），以及兩個版本各自的新位址。之後要追查這次變更當初是誰核准、依據是什麼，都查得到。

權限與稽核

建立、分析評估，要對評估目標有修改權限；檢視結果要有讀取權限
修改計畫或推進狀態，限建立者、負責人或管理員
監控（Zabbix、LibreNMS、Wazuh、OCS、RustDesk）與憑證類的項目只有管理員看得到，DNS、DHCP、防火牆、NAT、虛擬化要有全域讀取權限；權限不足的人分析時，結果會標成部分完整，審核時也只能「接受風險後核准」；審核人看不到其中的需覆核項目時，則不能核准
每次讀取都依目前的權限重新篩選，看不到的項目不會出現在清單、關係圖、數量、匯出或 AI 解說裡
建立、分析、送審、覆核、匯出都會寫入稽核記錄

另外也可以透過 MCP 讓 AI 助理準備評估草稿，但建立評估仍限管理員，而且要有伺服器簽發的草稿憑證。