IIS 關站驗證與需求討論

01專案階段工作

前置協調

本階段的第一步，是與對方環境部窗口（環境資訊科技司行政資訊服務科）完成協調與網路開通。在對方單位於防火牆開放 220.128.158.152 的 443 埠對外放行之後，我方才具備從外部進行後續切換與驗證的條件。實際施作上採用 real VNC（遠端桌面連線）遠端登入，逐一調整各站點 .py 檔的伺服器指向；為求穩妥，在正式施作前先行測試了 queue 的持久化行為，確認服務重啟後排程與資料不致遺失，並替備份操作補上對應的 request 物件，讓整個切換過程可追溯、也可回復。

第一階段 · 防火牆／VM／OT／資料補齊

第一階段的重點，放在防火牆連線、VM 端更版、OT 端灰度發佈，以及資料補齊這四件事的確認。防火牆方面，HTTPS 連線已確認可透過 curl 正常存取；ping 則持續無回應，初步判斷是 ICMP（ping 測試用的協定）未開放或遭到阻擋所致，對實際的服務存取與 API 呼叫並沒有影響，因此暫不處理。系統配置調整完成後，已可正常與 Fenri 端建立連線。VM 端（虛擬機）完成了一版更新；OT 端（現場端設備）則採較保守的灰度方式逐步發佈，目前已針對 PI、大智、中正國小等站點完成 URL 更新。資料層面，全站資料皆已補齊，並持續觀察回補後的狀態與服務穩定性——整體服務目前可正常運作，惟穩定性仍需再觀察一段時間才能定論。另外要記上一筆的是，目前 Log 輸出的噪音仍偏多，已做了小幅降噪調整，但尚未正式提交至 Git，列為後續待辦。

第二階段 · IIS 關站後狀態／現場站點／Log I/O

第二階段主要檢查 IIS 站點關閉後的服務狀態、現場各站點的運作情況，以及 Log 噪音對 I/O 的影響。關於 Log，已將其改放到 VM 以外的 S 槽，並做 gz.zip 壓縮處理；即使噪音仍在，評估對 I/O 造成溢出的風險並不高。要坦白說明的是，這批修改過的檔案還沒有經過長時間的實測驗證；考量到契約結束在即，我方以系統穩定性為第一優先，因此決定優化版本暫時不上正式站，先確保現行功能穩定運行。經雙方商議，已將「優先關閉 IIS 站點」列為最優先目標；關閉之後，部分 API 已確認從外部無法存取，但本機端仍可正常連線，符合目前的切換與驗證方向。站點狀態方面，新街、忠福等站運作正常，先前已更新的大智、中正國小也一併再次確認無誤。至於服務本身，W3SVC（IIS 對外發佈網站的服務）已經關閉，目前狀態分別為關閉與手動，後續仍會持續確認關閉後是否有殘留服務、以及會不會被意外重新啟用。

收尾

由於廠商契約即將到期，我方已完成 VM 端更版，確保既有功能在交接之後仍能如常運行，並把剩餘的 OT 站點全數指向 Fenri server，同樣以 real VNC 逐項修改到位。收尾的其他工作還包括：持續檢查 queue 的寫入是否正常、有無壓力與限速的問題，以及替 hub 補上 pull 路由的白名單，讓後續的資料流有一條明確而且受控的路徑。

02站點驗收清單

下表為本次 14 個站點的最終驗收結果。多數站點運作正常；一品、康樂兩處因為採太陽能供電，連線呈現斷續但整體仍屬可用；蟹仔埔公園目前列為報修，需要另外安排現場處理。

03起因

這次需求的起點，是承辦希望把這個網址從目前的「現況」改成他想要的「目標」狀態，並且附上了下面這兩張畫面來說明。左邊是現在的樣子，右邊是他期望達到的樣子——乍看之下很直覺，但其實藏了一個需要先講清楚的細節。

→

04需求理清（還原與理解）

我方觀點

先講我方的判斷。DNS server 這一塊，本來就應該是由對方單位在管理的；而依照過往處理類似案子的經驗，我傾向認為這根本就是 DNS 紀錄還沒刪的問題，而不是 IIS 這一層的問題。這個判斷並不是憑感覺——PART 3 的技術佐證已經證明，我方的 IIS 對外是完全沒有回應的。既然來源這一端已經關到連 TCP 都連不上，那麼右圖想要的那種 NXDOMAIN，就只剩下一條路可走：由對方的 DNS 維運端，把 raingarden 這一筆紀錄從權威區域裡刪掉。

待釐清：對方的具體訴求到底是什麼？

不過在動手之前，有一件事得先跟承辦問清楚：同樣是「傳兩張圖過來」，背後想表達的訴求其實可能差很多。與其各自猜、各做各的，不如先把對方到底要什麼還原、理解清楚。我大致把它拆成三種可能：

後續動作（釐清之後）

1. 先向承辦確認上面 A／B／C 到底是哪一種，把訴求與「完成」的定義講定。
2. 若確定就是要達到 NXDOMAIN：檢附本報告，請對方 DNS 維運端刪除 raingarden 的 A 紀錄，並同步各權威伺服器。
3. 刪除之後，以稽核腳本複驗，取得 COMPLETE_CLOSURE_VERIFIED（我方稽核腳本的「已徹底關閉」判定字串）才算真正結案。

05IIS 關站驗證

這一節是用來支撐前面討論的技術佐證。前面之所以敢說「IIS 已經關乾淨、問題出在 DNS」，並不是嘴上講講，而是有實際的稽核數據撐著。以下把驗證的邏輯、指令，以及真實的回傳一併附上，讓結論可以被覆核。

4.3　HTTP／HTTPS —— 來源伺服器層（證明沒有任何 HTTP 回應）

直接對來源 IP 223.200.81.115，帶上正確的 Host 與 SNI、而且不跟隨轉址地去探測：

沒有 200、沒有 301／302、沒有 404，也沒有任何標頭——連 Server: Microsoft-IIS 都看不到，因為連線根本就沒建立起來。

驗證指令（sh）與實際回傳

底下的指令與輸出都是實跑擷取下來的，沒有經過美化。

驗證指令

# 帶正確 Host 與 SNI、不跟隨轉址，逾時 8 秒
curl -sS --max-time 8 -o /dev/null \
     -w 'http_code=%{http_code} time=%{time_total}s\n' \
     https://raingarden.moenv.gov.tw/

# 純 TCP 層：直接測來源 IP 的 80 / 443（bash /dev/tcp）
for p in 80 443; do
  timeout 6 bash -c "exec 3<>/dev/tcp/223.200.81.115/$p" \
    && echo "port $p OPEN" || echo "port $p UNREACHABLE"
done

實際回傳

curl: (28) Connection timed out after 8001 milliseconds
http_code=000   time=8.002224s        # 連 HTTP 狀態列都沒收到
port 80  UNREACHABLE
port 443 UNREACHABLE

差異化連通性（排除「是我方網路連不到」的可能）

有人可能會質疑：會不會只是我方這台機器連不到 MoENV？為了把這個可能性排除掉，我在同一台稽核機、同一個時刻，拿 MoENV 相鄰網段的權威 NS 跟來源 IP 做對照——如果鄰段連得上、只有來源連不上，那問題就一定出在來源主機本身，而不是網路路徑。

# 相鄰權威 NS vs 來源 IP，同源同時比較
for hp in 223.200.80.244:53 223.200.80.51:53 223.200.81.115:443; do
  h=${hp%:*}; p=${hp#*:}
  timeout 6 bash -c "exec 3<>/dev/tcp/$h/$p" 2>/dev/null \
    && echo "$hp OPEN" || echo "$hp UNREACHABLE"
done

223.200.80.244:53  OPEN (14 ms)      # 鄰段權威 NS 秒回
223.200.80.51:53   OPEN (13 ms)
223.200.81.115:443 UNREACHABLE       # 來源全埠不可達 → 是主機無服務，不是路徑問題

結論（分兩層看，責任才清楚）

把這件事拆成兩層來看，責任歸屬就一目了然：一層是我方負責的 Web／IIS，一層是對方負責的 DNS。