OONetAPPCluster-)): vifmgr.lifs.noredundancy [ALERT]

 

Net APP每週日12:00都會收到如下MAIL 通知

簡單來說，這段話的意思是：「系統被設定成『發生故障時要幫忙切換線路』，但你卻沒有給它任何可以切換的備用線路。」

詳細拆解說明

1. Failover Policy 為 local-only（故障移轉策略：僅限本地）：

   • 這代表你告訴 NetApp 系統：「如果這個 IP 的網線斷了，請幫我自動切換到同一台機器上的其他網路孔。」

2. Targets 只有單一實體埠 e0M（備用目標）：

   • 但在系統的設定清單裡，可用的網路孔只有 e0M 這唯一一個，沒有第二個孔（例如 e0b 或 e0c）可以當作備胎。

3. 觸發警報（Alert）的原因：

   • 系統發現邏輯矛盾：「你叫我遇到故障時要切換，但我根本沒有別的孔可以切換！」

   • 為了提醒管理者，ONTAP 就發出了 vifmgr.lifs.noredundancy（代表「故障移轉設定中缺乏備援冗餘」）的警告訊息。

為什麼「節點管理介面 (Node Mgmt)」不需要備用線路？

因為 Node Management LIF 是專門用來控制「特定一台硬體」的 IP。

• 如果這台機器或它的 e0M 網線壞了，就算把這個 IP 切換到別的地方，你也無法控制原本那台壞掉的機器。

• 所以原廠建議直接把它的政策改成 disabled（停用故障移轉）。當你告訴系統「這條線路壞了不用切換」，系統就不會再報錯了。

==============================================================

 1.登入NETAPP SSH

2. 

此指令會列出所有 LIF 的 Home Node/Port、Current Node/Port，以及系統為其分配的 Failover Targets：

network interface show -failover
 
驗證方式： 檢查輸出結果中的 Failover Targets 欄位。若欄位中僅顯示 Home Port 本身（沒有其他備援 Port），且 Failover Policy 不是 disabled，該 LIF 就會觸發 vifmgr.lifs.noredundancy 警報。

備註:可以使用-->network interface show -vserver TYNetAPPCluster -failover
          僅查看特定 Vserver (如系統預設的叢集 Vserver)：

                   

3.執行如下指令

network interface modify -vserver QQNetAPPCluster -lif QQNetAPPCluster-QQ_mgmt1 -failover-policy disabled

network interface modify -vserver QQNetAPPCluster -lif QQNetAPPCluster-QQ_mgmt1 -failover-policy disabled

4 .點檢是否有套用設定,是否變Disable

 network interface show -vserver OONetAPPCluster -failover

樹莓派 Raspberry Pi 電子看板功能設定

初始化時-->帳/密 記得設定,原則上執行都需要輸入密碼 

開始-->首選-->Control Centre

1.system-->瀏覽器-->Chromiun

2.system-->admin Password-->Disable

3.Desktop-->圖片-->選擇要套用的圖片

   布局-->將屏幕拉伸覆蓋整個屏幕

4.Display-->屏幕節能-->Disable

5.Main Menu-->取消勾選-->教育,科學類,辦公,影音,遊戲

6.System-->主機名-->依需求修改

    Desktop auto login-->Enable

7.interface-->SSH/VNC-->Enable

   備註:備用方案sudo raspi-config   啟用VNC  & 啟用SSH

8.關閉藍芽/音量

============================================================

做法 1：使用選單工具（圖形化介面）

1. 進入桌面，點選左上角 Menu -> Preferences -> Screen Configuration。

2. 在畫面顯示器（如 HDMI-1）上點 右鍵 -> Orientation -> 選擇  Left。(畫面就直式的)

3. 點選上方綠色勾勾 Apply 存檔。此設定在重啟後依然會保留。

============================================================

開機自動啟用chromium,使用如下設定,有開啟成功

Step0  mkdir -p ~/.config/labwc

Step1   vi ~/.config/labwc/autostart

Step2 貼上如下：

(sleep 10 && chromium --kiosk --no-sandbox --disable-gpu --disable-software-rasterizer --ozone-platform=wayland http://192.168.255.255/web_mf_report/zh-tw/manufacture/ele/cleaning) & 

恭喜！這個參數組合（關閉 GPU 加速、關閉安全沙盒並強制使用 Wayland 繪圖架構）完全解決了樹莓派 3B+ 在 Debian 13 / Labwc 環境下的硬體渲染與開機自動執行問題。

為了讓這個看板（Kiosk）系統運作得更穩定且無人值守，以下為您提供 如何驗證目前運作狀態，以及 建議說明的優化設定。

在 --kiosk 全螢幕模式下：

• 按鍵盤的 Alt + F4 或 Ctrl + W 可以直接關閉 Chromium。
  

如下為遇到的問題:

============================================================

開啟chromium 出現如下視窗

出現這種情況，通常是因為 GNOME Keyring 裡還有其他 .keyring 檔案（例如 login.keyring 或 user.keyring），或者應用程式已經鎖定了新的 default 指標。

請依照以下步驟徹底清除或處理：

1.徹底刪除所有 Keyring 檔案：終端機操作。

先關閉所有瀏覽器與應用程式，直接刪除目錄下所有鑰匙圈檔：

Bash

rm -rf ~/.local/share/keyrings/*

刪除後，請登出帳號並重新登入系統，或直接重啟電腦。

驗證方式：執行 ls ~/.local/share/keyrings/ 應顯示為空。

2.重新觸發並將密碼「留空」：關鍵步驟。

開啟會觸發該視窗的應用程式（如 Chrome 或照片中的 EIP/應用商店）。

1. 當系統跳出 New Keyring / Choose Password（設定新鑰匙圈密碼）時。

2. 完全不要輸入任何密碼（保持空白），直接點擊 Continue / OK。

3. 系統會跳出警告提示「Password will be stored unencrypted」（密碼將不加密儲存），點擊 Continue 確定。

驗證方式：再次開啟應用程式，確認不再跳出 Unlock Keyring 提示。

tftp主機架設

 內部用tftp主機,最快速的方法,若有需要可以使用Linux架設

1.下載Tftpd64_Installer_v4.72

2.install

3.選擇要分享的目錄/介面

4.Settings-->Global-->只勾選TFTP Server

5.TFTP-->Bind TFTP this address -->選擇您要對外的IP介面

6.Windows防火牆開啟UDP 69-->建立於輸入規則
備註:有需要可以限制連線來源!

7.於連線設備設定/觀察Log Viewer是不是有記錄

Windows 內建防火牆規則,DENY某個IP ALL PORT

 使用windows 內建防火牆去阻擋特定IP一直連線(某個服務,不想看到LOG)

1.輸入規則-->新增規則

2.選擇[所有程式]

3.依需求調整,這裡全部DENY-->下一步

4.遠端IP地址-->新增-->這些IP-->輸入要阻擋的IP

5.選擇[封鎖連線]

6.套用至所有設定檔

7.規則命名

8.確認規則設定是否正確

Windows防火牆優先順序原則

明確封鎖優先於允許：明確定義的「封鎖（Block）規則」優先權高於任何衝突的「允許（Allow）規則」。只要有一條符合的封鎖規則，流量就會被拒絕。 
較特定的規則優先：條件設定越具體、範圍越小的規則（例如指定單一特定的 IP 位址或連接埠），優先權高於較為籠統、不明確的規則（例如套用至所有 IP 或所有連接埠）。 
允許規則優先於預設值：明確定義的允許規則會優先於系統預設的阻擋設定。 
預設行為：如果沒有任何規則明確符合該流量，系統會採用預設行為（通常入埠預設為阻擋，出埠預設為允許）。

詳細內容可參考 Windows 防火牆規則說明。 

OFFICE會於使用者%temp%產生大檔案LOG檔,而造成任何事都不能做~

 


問題:OFFICE會於使用者%temp%產生大檔案LOG檔,而造成任何事都不能做~

可參考如下方式去解決看看:

reg add "HKCU\Software\Microsoft\Office\16.0\Common\Telemetry" /v EnableTelemetry /t REG_DWORD /d 0 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Office\16.0\Common\Telemetry" /v EnableTelemetry /t REG_DWORD /d 0 /f

reg add "HKCU\Software\Policies\Microsoft\Office\16.0\Common\Privacy" /v DiagnosticDataGatheringLevel /t REG_DWORD /d 0 /f

reg add "HKCU\Software\Microsoft\OneDrive" /v EnableTrace /t REG_DWORD /d 0 /f

開啟工具列檔案總管會一直重啟(Adobe造成問題)

錯誤紀錄資訊解析

• 失敗的應用程式： Explorer.EXE (Windows 檔案總管)

• 失敗的模組： BIB.dll_unloaded (Adobe 基礎資訊模組，常見於舊版 CS4、Photoshop 或 Acrobat)

• 例外狀況代碼： 0xc0000005 (記憶體存取違規)

• 錯誤位移： 0x000000000000b0a0

• 失敗的處理程序識別碼： 0x0x394C

• 失敗的應用程式路徑： C:\WINDOWS\Explorer.EXE

• 失敗的模組路徑： BIB.dll

• 報告識別碼： 7531a4fd-df31-462e-a6a4-adb9550db3f4

問題原因

當您在檔案總管中開啟資料夾、點擊特定檔案（如 .zip 壓縮檔、圖片、影片）或按下右鍵時，系統會自動載入 Adobe 的右鍵選單延伸功能（Shell Extension）。由於舊版 BIB.dll 與現有 Windows 系統不相容，進而導致檔案總管直接閃退或重新啟動。

解決方案

使用 ShellExView 停用衝突的 Adobe 擴充功能（最推薦）

1. 下載工具： 前往 NirSoft 官網免費下載 ShellExView。

2. 開啟程式： 下載後解壓縮，並以系統管理員身分執行 shellexview.exe。

3. 過濾項目： 點擊上方選單的 Options，勾選 Hide All Microsoft Extensions（隱藏所有微軟延伸功能）。

4. 尋找標的： 在剩餘清單中找出公司（Company）欄位為 Adobe Systems，或名稱含有 Adobe Drive、Photoshop、Context Menu 的項目。

5. 停用項目： 選取這些項目後，點擊左上角的紅色圓圈按鈕（Disable Selected Items）。

6. 重啟總管： 按下 Ctrl + Shift + Esc 開啟工作管理員，找到「Windows 檔案總管」並點擊右鍵選擇重新啟動。

Client無法更新問題_Domain相關

 
當電腦未加入網域,執行windows update,但是出現被Doamin 管理,同時無法更請

可參考如下指令執行/執行後重啟服務或重啟

reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /f 

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection" /f 

gpupdate /force


也有另一個可能這我自己也常常犯錯,再測試電腦時,發現電腦沒有拉到指定套用的OU下,所以一直顯示WSUS更新失敗,在此提醒自己要記得設備一定要放到套用GPO政策的OU下

在 Windows 環境下，直接使用 UNC 路徑（例如 \\ServerName\ShareFolder）列出資料夾結構，指令為tree

 
有時想整理資料夾,目前Windows 11 CMD還有支援如下指令

tree "D:\Share\00_PRINT\EPSON L6190" /f > C:\output.txt
#路徑也支援UNC


產生txt檔,結果如下

ISO檔無法掛載

遇到自己的電腦要掛載ISO,但發現按右鍵無[掛載]及[無法檔案總管]
系統:Windows 11

無法指定檔案總管

判斷錯誤訊息（OpenWith.exe 無法關聯），代表系統的 .iso 檔案類型機碼可能已經損毀或被鎖死，導致檔案總管無法正常接管。
建立一個txt,將如下save並將副檔名改成.reg-->執行即可
=========================================================

Windows Registry Editor Version 5.00

; 1. 重新定義 .iso 檔案的預設處理類別

[HKEY_CLASSES_ROOT\.iso]

@="Windows.IsoFile"

"Content Type"="application/x-iso-image"

; 2. 建立檔案總管掛載選單的核心指令

[HKEY_CLASSES_ROOT\Windows.IsoFile\shell\mount]

"CommandStateHandler"="{11f15859-a5c2-4d9b-b6c8-4718dc0e6080}"

"CommandStateSync"=""

"HasLUAShield"=""

"MultiSelectModel"="Document"

[HKEY_CLASSES_ROOT\Windows.IsoFile\shell\mount\command]

@=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,00,25,\

  00,5c,00,45,00,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,2e,00,65,00,78,00,\

  65,00,00,00

; 3. 確保右鍵選單出現「掛載」

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.iso\UserChoice]

"ProgId"="Windows.IsoFile"

=========================================================

LQ-2180C列印時,左上角出現284.4 @EJL

於WIN11 安裝EPSON LQ-2180C列印時,左上角會出現,如下圖

參考網路大神及原廠說明:裝置設定-->封包模式-->關閉

設定後即不會印出左上角亂碼!

參考原廠說明如下:
 https://www.epson.com.cn/services/videomanual/videodetail/a69e7d3fe8574822ba3a4dcebdcad10b.html

outlook.exe 一直閃退

 我的outlook.exe是2019版,今早突然發現有些電腦會突然閃退

1.修復PST,一樣
2.換設定檔.一樣

3.換帳號,一樣
4.後來去查LOG

5.重安裝Visual C++ Redistributable ,一樣(如下LOG-1)
6.參如下(如下LOG-2),去控制台移除TEAMS插件,即恢復正常,給各位參考看看

如下LOG-1
=========================

失敗的應用程式名稱： OUTLOOK.EXE，版本： 16.0.10417.20020，時間戳記： 0x6833d606

錯誤模組名稱： MSVCP140.dll， 版本： 14.24.28127.4，時間戳記： 0x5d8e68d7

例外狀況代碼： 0xc0000005

錯誤位移： 0x0000000000012590

錯誤處理常式識別碼： 0xE24

失敗的應用程式開始時間： 0x1DCBCBFE2741E94

Faulting 應用程式路徑： C:\Program Files\Microsoft Office\root\Office16\OUTLOOK.EXE

Faulting 模組路徑： C:\WINDOWS\SYSTEM32\MSVCP140.dll

Report 識別碼： 3000c50e-1d87-4dce-a595-

如下LOG-2

=========================

應用程式: OUTLOOK.EXE

Framework 版本: v4.0.30319

描述: 處理序已終止，因為有未處理的例外狀況。

例外狀況資訊: System.AccessViolationException

   於 Microsoft.Teams.MeetingAddin.Scheduler.OneAuthUtils.Startup(System.String, System.String, System.String, Boolean, Boolean, Boolean, System.String)

   於 Microsoft.Teams.MeetingAddin.Scheduler.OneAuthAuthenticator+<>c.<.cctor>b__16_1(System.String, System.String, System.String, Boolean, Boolean, Boolean, System.String)

   於 Microsoft.Teams.MeetingAddin.Scheduler.OneAuthAuthenticator.OneAuthStartup(Microsoft.Teams.MeetingAddin.Telemetry.ITelemetryAppLifecycleContext, Microsoft.Teams.Diagnostics.Logger, Microsoft.Teams.MeetingAddin.Scheduler.IHrdHostService)

   於 Microsoft.Teams.MeetingAddin.Application+<CompleteIntializationAfterSettingsAreLoadedAsync>d__64.MoveNext()

=========================

資安，真的會造成對立嗎？

 

有時候，我總覺得資安就像那個家裡的「防盜門」，一開始大家覺得多此一舉，但一旦用上就知道不裝不行；然而在裝的過程中，總是有人抱怨「幹嘛這麼麻煩？」。職場上的資安，好像也差不多。

沒資安人員前：對外能用就好，稽核過關就好

還記得公司還沒有資安人員進駐的時候，整個IT團隊都抱著「能用就好」的心態。
系統能讓客戶連上線、資料能夠順利跑完流程、Email 可以寄出收進來，基本上就是合格了。至於稽核？只要偶爾整理一下紀錄、檢查一下權限，看起來「表面乾淨整齊」，稽核官來檢查也能點頭說：「嗯，可以過。」

那個階段，大家對資安的感覺很簡單：

• 防火牆？開著就好。

• SSL 證書？不要過期就好。

• 使用者權限？能登入能操作就好。

總之，只要對外能用，內部同事操作不被卡到，稽核能過關，一切就算完成任務。

那時候的我們，根本還沒有遇到資安人員。大家的心態大概是：「資安？等會有人來管就好了。」

資安人員來了：安全 VS 可用，好像開始對立

事情開始轉折，是在應用程式人員想開通某些外對內服務的時候。原本只要「能用」就好了，但資安人員出現後，情況完全變了。

你申請一個端口開放？資安人員開始計算風險、考慮潛在攻擊面。
你想部署一個 API 對外？資安人員會要求加驗證、加日誌、加加密，甚至提醒「這個還可能被 XX 攻擊」。

突然間，原本簡單的需求，變得像是過五關斬六將。大家會開始覺得：「幹嘛要這麼麻煩？我只是想讓客戶能用啊！」
私下裡，抱怨聲此起彼落。應用程式人員說：「資安人員就是來拆我的需求！」
資安人員心裡想：「他們懂什麼是安全？都只會想著好用！」

就這樣，一個小小的功能開通申請，瞬間演變成職場小戰爭，雙方好像天生就是對立的。

我本人對資安的初體驗：從抗拒到習慣

老實說，我自己也不是資安出身。以前提到資安，我的心裡是：「啊…又要學一堆東西嗎？」
尤其是當客戶要求必須達到某些資安檢查標準的時候，我一開始完全抗拒。

想想那些東西：

• SSL 憑證要檢查，還要知道什麼是中間憑證、根憑證。

• 網頁安全要調整，防 XSS、防 CSRF、防 SQL Injection。

• 權限管理要檢查，每個帳號都有什麼權限、誰能改誰不能改。

天啊！這些以前完全不熟的東西，突然要我搞懂還要落實，真的是一開始覺得心裡打鼓、手腳發抖。

但後來，我逼自己去看文件、查資料，甚至實際操作了一遍，結果發現…只要按步驟做，其實並沒有想像中恐怖。
最終，我達到客戶要求的資安最低標準，雖然不是滿分，但至少符合規範，也算是一種成就感。

更重要的是，這個過程變成了經驗累積。下次遇到類似需求，我就不會再慌張，因為我知道要檢查哪些、要調整哪些、要注意哪些細節。

所以，資安學起來，不只保護系統，也保護自己。這種「以不變應萬變」的心態，對職場生存很有幫助。

資安不是資安人的責任，而是全公司的責任

這點我深深體會到：資安不能只是資安人員的事情。
如果公司上下都沒有資安意識，再強的資安團隊也只能像「孤軍奮戰」，結果往往是疲於奔命、被抱怨、甚至被孤立。

我認為，要把資安導入公司，有幾個前提：

1. 老闆要支持
   如果老闆不支持資安策略，資安人員在公司就像走鋼索，一不小心就被人咬耳朵、被排擠、甚至被標黑。
   老闆的態度會決定資安在公司內部的定位：是「戰略核心」還是「麻煩製造者」。

2. 全公司都有責任
   資安不是資安團隊的專利，應用程式人員、系統管理員、業務部門、甚至行政部門都應該參與。
   這樣一來，當資安人員提出需求時，不會只聽到抱怨，而是理解「這是保護公司、保護客戶、保護自己」。

3. 教育和經驗累積
   不可能每個人一開始就熟悉資安，但可以透過訓練和實務操作，慢慢建立經驗。
   就像我自己，雖然初期抗拒，但累積經驗後就能從容應對，甚至可以幫助團隊提升整體資安水平。

職場幽默小觀察

我發現，資安造成的「對立感」其實有點像職場的「愛恨交錯」：

• 應用程式人員抱怨資安人員太嚴格，但其實心底也希望系統不被攻擊。

• 資安人員抱怨大家不懂安全，但看到系統被保護起來時，也會暗自竊喜。

• 老闆覺得資安很麻煩，但一旦出了問題，第一個被問責的還是自己。

所以，資安的對立感，其實更多是角色定位的衝突，而不是人人天生敵對。

我常開玩笑說，資安就像吃蔬菜：一開始嫌棄、覺得麻煩，但吃過幾次、感受到健康好處後，你就會慢慢欣賞它。

總結：資安其實可以是一種「職場成長的契機」

回過頭來看，資安的存在並非為了製造對立，而是保護公司、保護客戶、保護自己。

• 沒資安時，大家覺得簡單、方便，但風險潛藏。

• 有資安時，看似對立，其實是不同角色在不同角度思考。

• 個人學習資安，能累積經驗、增加面對挑戰的自信。

• 導入資安，需要老闆支持與全公司參與，才能避免孤立與抱怨。

所以，下次當應用程式人員抱怨「資安太麻煩」或資安人員皺眉「大家都不懂安全」時，不妨幽默地想想：這是職場的必經過程，也是每個人進步的契機。

資安，不是對立，而是成長。

而且，說不定有一天，你會發現，那些曾經抱怨的麻煩要求，其實都是你未來職場生存的「防彈衣」。

PaloAlto_21 Security Policy 不是 allow any

 

開場白：allow any 是工程師的泡麵

凌晨兩點、專案卡關、客戶在催、系統就是不通。
這時候，最容易出現的一行設定就是：

Source：any
Destination：any
Service：any
Action：allow

它就像泡麵——
不健康、沒營養、但「立刻可以活下來」。

但在 Palo Alto Networks 的世界裡，
Security Policy 的存在，就是為了阻止你每天吃泡麵。

第一課：Security Policy 到底在管什麼？

先講人話版本：
Security Policy = 誰，可以，在什麼情況下，用什麼方式，跟誰說話。

工程師翻譯版是五個 W：

1. Who（Source）：誰發起連線

2. To Whom（Destination）：要連到哪

3. How（Application / Service）：用什麼方式

4. When（Schedule）：什麼時間

5. So What（Action）：放行 or 擋掉

allow any 等於直接跟防火牆說：

「你不要思考，我來承擔後果。」
（歷史證明，後果通常你也承擔不起）

第二課：為什麼 Palo Alto 討厭 allow any？

因為 Palo Alto 的核心哲學只有一句話：

「我不只看 port，我看你在幹嘛。」

傳統防火牆：

• TCP/443？好，大概是 HTTPS，放。

Palo Alto：

• TCP/443？

• 是 HTTPS？

• 還是 Dropbox？

• 還是某個你不想讓老闆知道的東西？

你如果用 allow any，等於買了跑車卻永遠踩一檔。

第三課：正確的 Policy 心法

1️⃣ 先想「業務需求」，不是先想「怎麼通」

錯誤流程：

ping 不通 → allow any → 世界和平（10 分鐘）

正確流程：

這台 Server 要做什麼？
它應該跟誰說話？

Security Policy 是白名單思維，不是黑名單懺悔錄。

2️⃣ App-ID 是你的好朋友，不是麻煩鬼

很多人抱怨：

「App-ID 很煩，規則寫不動。」

但實話是：
App-ID 是幫你把『不知道自己在幹嘛』變成『我很清楚』。

實務建議：

• 能用 Application，就不要只用 Service

• HTTPS ≠ 一切合法行為

3️⃣ Rule Order：防火牆是從上往下讀的

這不是小說，沒有伏筆。

• 第一條 match，就停

• allow any 放最上面 = 所有規則都是裝飾品

工程師金句：

「規則不是沒生效，是你永遠跑不到它。」

第四課：一個「不丟臉」的 Security Policy 教學範例

假設情境：

Web Server 需要對外提供 HTTPS

錯誤寫法（資安會皺眉）：

• Source：any

• Destination：Web Server

• Service：any

• Action：allow

比較像樣的寫法：

• Source：Internet Zone

• Destination：Web Server Zone

• Application：ssl, web-browsing

• Service：application-default

• Action：allow

這時候 Palo Alto 會說：

「好，我知道你在做網站，不是在亂來。」

第五課：Log 不看，比 allow any 更可怕

很多人寫完規則就收工，
Log 的存在彷彿只是為了佔硬碟。

但事實是：

• Log = 你未來自保的證據

• Log = 你跟資安、稽核、老闆溝通的翻譯機

至少做到三件事：

1. 允許的流量要記錄

2. 被擋的流量要敢看

3. 出事時不要第一句就說「防火牆沒動」

結語：allow any 不是原罪，但是警訊

老實說，每個工程師人生中都用過 allow any。
真正的差別在於：

• 新手：用了就忘

• 老手：用了會內疚，然後刪掉

Security Policy 的成熟度，
不是你會不會寫 allow any，
而是你能不能不用它，系統還是活得好好的。

如果你現在打開 Palo Alto，
看到某條 allow any 在角落對你微笑——
別怕，
它不是在嘲笑你，
它是在等你長大。

PaloAlto_20 的 Routing & NAT

 

一場封包的迷航記，以及工程師的自我修行

如果你第一次打開 Palo Alto Networks Firewall，大概會有一種感覺：
「介面好漂亮。」
三分鐘後：
「Routing 跑去哪？」
十分鐘後：
「為什麼 NAT 看起來像在玩邏輯題？」

放心，你不是一個人。
在 PaloAlto_20（泛指 PA 防火牆 10.x 世代設定邏輯）裡，Routing 與 NAT 從來不是單純的「網路設定」，而是一場工程師心智成熟度測驗。

一、Routing：不是幫你指路，是決定你的人生方向

在工程師的世界裡，Routing 就像人生規劃。
你以為只要設定一條 Default Route（0.0.0.0/0），封包就會自動走向幸福的彼岸。
但 Palo Alto 冷冷地告訴你一句話：

「不好意思，我要先看 Virtual Router。」

是的，Palo Alto 沒有「全域 Routing Table」，
每個 Interface 都要掛在正確的 Virtual Router 底下，
否則你的封包會陷入量子狀態——
介於「送出」與「消失」之間。

工程師常見錯誤清單：

• Interface 掛錯 Virtual Router

• 靜態路由寫得很美，但根本沒人用

• OSPF 開得很開心，對面根本沒鄰居

這時候你會學到 Palo Alto 的第一堂人生課：
👉 Routing 沒錯，只是你想得太天真。

二、NAT：封包的變裝秀，比你想得更複雜

如果 Routing 是人生方向，那 NAT 就是身分證改名大賽。

在 Palo Alto 裡，NAT 不是「順手設定一下」，
而是明確告訴你：
「我什麼時候要改你、在哪裡改你、改成什麼樣子。」

Palo Alto 的 NAT 三大靈魂問題：

1. Original Packet 長怎樣？

2. Translated Packet 要變成誰？

3. 這一切發生在 Security Policy 之前，還是之後？

很多新手工程師會天真地問：
「為什麼我 NAT 設好了，還是連不上？」

答案通常只有一句：
👉 因為你的 Security Policy 根本不是用 NAT 後的 IP 在比對。

這一刻，你會突然理解為什麼資深工程師都不愛說話。
不是冷漠，是已經痛過。

三、Routing × NAT：當兩個世界開始互相傷害

真正的修羅場，是 Routing 跟 NAT 同時出問題。

經典場景如下：

• 封包進來 → Routing 看得懂

• NAT 改得很開心

• 封包出去 → Routing 說「這不是我認識的你」

然後 Session 就這樣死在 Log 裡，
留下你一個人盯著 Monitor → Traffic，看著封包的最後一跳。

這時候你會開始做工程師的三大儀式：

1. 開 Packet Capture

2. 打開 CLI 看 test routing fib-lookup

3. 默默懷疑人生選擇

四、工程師的覺醒：你終於開始「看流程」

某一天，你突然不再亂改設定了。

你會開始照流程思考：

1. 封包從哪個 Interface 進來？

2. 屬於哪個 Zone？

3. Routing 決定往哪走？

4. NAT 什麼時候介入？

5. Security Policy 用的是哪個 IP？

6. 回程路由是不是對稱？

那一刻，你不會特別開心，
但你會很平靜地說一句話：

「嗯，這個我大概知道問題在哪。」

恭喜你，你已經從「亂試工程師」
進化成「有邏輯的工程師」。

五、結語：Palo Alto 沒有很難，只是很誠實

PaloAlto_20 的 Routing & NAT，
其實沒有陷阱、沒有魔法、也沒有黑箱。

它只是把網路的本質攤開來，
逼你面對現實。

如果你哪天設定完，
封包一次就通，Log 乾乾淨淨，
那不是因為運氣好——

而是因為你已經學會用工程師的方式思考。

最後送你一句 Palo Alto 生存守則：

「Routing 決定你去哪，NAT 決定你是誰。」

而工程師，決定要不要再加班。

PaloAlto_19 SSL 解密：別當那個「隔著麻袋摸大象」的資安工程師

前言：加密流量，是駭客最溫柔的掩護

如果你已經搞定了 Zone 的邏輯，也學會了用 App-ID 去抓應用程式，你可能會覺得自己現在就像機房裡的葉問，一個能打十個。

但我要潑你一盆冷水。

在 2026 年的今天，超過 90% 的網路流量都是加密的（HTTPS/TLS）。如果你沒有開啟 SSL Decryption (SSL 解密)，你的 PA-1410 就算效能再強，在它眼裡，這些流量通通都長這樣：

[一團亂碼] -> [目的地] -> [又一團亂碼]

這就像是你身為機場安檢員，看到旅客提著一個「死鎖的保險箱」走進來。你問他裡面裝什麼，他說裝的是「個人隱私（HTTPS）」。你就揮揮手讓他過去了？這不叫資安，這叫佛系管理。

今天的 PaloAlto_19，我們要聊聊如何優雅地拆開這些保險箱，又不被旅客（使用者）投訴到爆。

一、 為什麼非「拆」不可？（SSL 解密的必要性）

很多老闆（甚至有些資深工程師）會問：「解密很耗效能耶，真的有必要嗎？」

我通常會回他一個情境： 如果有一個員工，從家裡的雲端硬碟下載了一個包著 Cobalt Strike（木馬） 的檔案，並且這個檔案是透過 HTTPS 傳輸的。

• 沒開解密： PA 只看到 App: web-browsing，流量通過。恭喜你，內網中毒了。

• 開了解密： PA 會在防火牆中間把流量拆開，用 Content-ID 掃描裡面的位元組。發現病毒，直接攔截。

一句話總結：不開解密，你的進階威脅防禦（IPS、WildFire）就跟裝飾品沒兩樣。

二、 實戰操作：PA-1410 的「中間人」演技

SSL 解密的原理其實就是合法的「中間人攻擊 (Man-in-the-Middle)」。

1. 使用者想連到 Google。

2. PA-1410 攔截請求，自己偽裝成 Google 發一個憑證給使用者。

3. PA-1410 另外去跟真正的 Google 連線。

這中間最容易翻車的地方就是：憑證 (Certificate)。

如果你的使用者電腦不信任 PA 發出來的那張「代理憑證」，他們打開瀏覽器就會看到滿螢幕的「您的連線不是私密連線」。接著，你的分機就會被打爆，主管會站在你背後，問你為什麼公司網路壞了。

良的避坑指南：

• 一定要透過 AD GPO 派送憑證： 讓全公司的電腦預設信任 PA 的 Sub-CA 憑證。

• 手機與 IoT 設備是地雷： 這些東西很難塞憑證進去，建議先排除在解密清單外，不然你的報修單會接到手軟。

三、 哪些東西打死都不能解？（Decryption Exclusion）

做 SSL 解密不能像推土機一樣全推平，有些東西解密了會出大事（甚至有法律責任）：

1. 金融銀行類 (Financial Services)： 你解密員工的網銀帳密？這在某些法規下是違法的。

2. 醫療與隱私 (Health and Medicine)： 同上，別給自己找麻煩。

3. 政府網站： 有些政府憑證有特殊檢查機制，解密後會直接斷線。

4. 不支援解密的 App： 例如 Dropbox 或某些特定的手機 App，它們會檢查憑證的「指紋」（Certificate Pinning），一旦發現中間有人動手腳，就直接擺工。

工程師的專業溫柔： 在 PA 的 Decryption Policy 裡，記得最上面要疊一層 No-Decrypt 的規則，把這些敏感類別通通排除。

四、 效能與「爆機」的恐懼

「解密會讓防火牆變慢」這不是傳聞，這是物理規律。解密需要大量的數學運算。 好在我們用的是 PA-1410，它有專門的硬體加速晶片處理這塊。但即便如此，你還是要監控你的 DP CPU (Dataplane CPU)。

如果有一天你發現解密開下去，CPU 飆到 90%，請不要驚慌，這時候你有兩個選擇：

1. 縮小範圍： 只解密「最危險」的類別（例如：Web-browsing, Unknown-tcp）。

2. 升級硬體： 拿著數據去找老闆，說我們需要更高階的型號了。（這也是幫自己爭取預算的好機會）。

五、 結語：資安就是一場「透明度」的戰爭

SSL 解密很痛苦，部署過程會有很多雜音，甚至會讓你懷疑人生。但一旦你熬過去，你會發現你的 Traffic Log 變得很清澈。

你會看到：

• 本來是 SSL 的流量，現在顯示為 Google-base。

• 原本藏在加密流量裡的惡意檔案，被 WildFire 準確擊落。

• 員工在上班時間偷偷用加密代理跳牆，被你一秒抓到。

資安工程師的價值，就在於你能看到別人看不見的東西。

PaloAlto_18 App-ID 的覺醒--別再讓 Port 號綁架你的智商

 

前言：你還在玩「看門牌猜屋主」的遊戲嗎？

如果你看完上一篇 [PaloAlto_17] 已經乖乖把 Zone 劃分清楚了，恭喜你，你已經從「水電工」晉升為「資安室內設計師」。但先別急著開香檳，因為接下來這個關卡，會決定你的 PA-1410 到底是一台具備人工智慧的頂級超跑，還是一台跑得比較快的電子垃圾。

這個關卡就叫：App-ID。

傳統防火牆（我們簡稱 Legacy FW，或是「那些讓你半夜被 Call 的舊機器」）邏輯很簡單：

• Source: 10.1.1.5

• Destination: 8.8.8.8

• Port: TCP 80 / 443

• Action: Allow

這種邏輯在 2005 年可能很神，但在 2026 年的今天，這簡直是開大門揖盜。為什麼？因為現在連阿嬤都知道，只要把病毒包在 HTTPS (Port 443) 裡面，你的防火牆就像瞎子一樣，摸著大象腿說這是一根柱子。

Palo Alto 的靈魂除了 Zone，另一個就是 App-ID。 它不看門牌（Port），它直接衝進屋子裡看你在幹嘛。

---

一、 Port 是騙人的，App 才是真的

很多剛從傳統防火牆轉過來的工程師（包括當年的我），最常問的一句話就是：

「良大，我明明開了 Port 80，為什麼網頁還是打不開？」

因為在 PA 的世界裡，Port 只是載體，App 才是本體。

想像一下，今天有一個外送員（流量）來到公司門口：

• 傳統防火牆思維： 「喔，你穿黃色制服（Port 80），進去吧。」（結果裡面包的是炸彈）。

• Palo Alto 思維： 「穿黃色制服是吧？把箱子打開。裡面是麥當勞（Web-browsing）？還是偽裝成麥當勞的非法無線電（BitTorrent）？」

如果你在 Policy 裡只寫了 Service Port 而沒有定義 Application，那你的 PA-1410 就只是在做「基礎重體力活」，完全浪費了它那顆強大的運算處理器。

二、 實戰演練：當主管叫你封鎖 Facebook，但又要留著發文功能

這是我最愛舉的例子，也是工程師最常遇到的「職場機車要求」。

在傳統防火牆，你要嘛全放，要嘛全擋。但在 PA-1410 裡，App-ID 讓你像拿著手術刀一樣精準。 在 Application 列表裡，你會發現 Facebook 不是一個 App，而是一群 App：

1. facebook-base（基本的瀏覽）

2. facebook-chat（聊天，這就是薪水小偷的來源）

3. facebook-posting（發文）

4. facebook-video（看影片，流量殺手）

工程師的優雅操作： 你只需要寫一條 Policy，把 facebook-chat 和 facebook-video 設為 Deny，保留 facebook-base。 明天主管過來就會說：「奇怪，為什麼我可以看公司粉專，但沒辦法看妹子的直播？一定是 FB 壞了。」 你只要推一下眼鏡，淡淡地說：「可能是最近海纜斷了吧。」

這就是 App-ID 帶給工程師的尊嚴。

三、 為什麼「Service: Any」是資安人的髒話？

在設定 Policy 時，新手最容易犯的罪就是為了省事，在 Service 欄位選 Any 或 Application-default。

讓我告訴你為什麼這很危險。 有些聰明的惡意軟體會故意走非標準 Port。例如，它用 Port 80 來跑 SSH 隧道。

• 如果你設 Service: Any 且 App: SSH，它就通了。

• 如果你設 Service: Application-default，PA 就會發現：「不對喔，SSH 應該走 Port 22，你現在走 Port 80？抓到你了，滾吧！」

良的溫馨提示： 永遠優先使用 Application-default。這意味著你強迫 Application 必須走在它該走的軌道上。不守規矩的流量，一律視為「非法入侵」。

四、 那些年，我們一起踩過的 App-ID 坑

雖然 App-ID 很強，但它也有脾氣。最常見的坑就是 「相依性 (Dependency)」。

你興沖沖地開了一條 Policy 給 Office365，結果發現 outlook 還是轉圈圈。 為什麼？因為 Office365 運作時，背後可能還需要 SSL、Web-browsing 甚至是 DNS。

解決心法：

1. 善用 Policy Optimizer： 讓 PA 跑個幾天，它會自動告訴你：「欸，我看這條流量其實還包含這幾個 App，你要不要順便補上去？」

2. 看 Log 是美德： 當流量不通時，不要一直改 IP，去看 Traffic Log。PA 會清清楚楚告訴你，這個流量被辨識為什麼 App，以及為什麼被丟掉。

五、 App-ID 之後：如何跟老闆解釋這台 PA-1410 買得很值？

身為工程師，我們不只要會做，還要會「演」。 當年度報表拿出來時，你不要只給他看 CPU 負載（老闆聽不懂）。你要給他看 「ACC (Application Command Center)」。

當你打開 ACC，畫面出現：

• 「本月攔截了 50,000 次試圖偽裝成 Web 的加密隧道。」

• 「辨識出 200 種未授權的雲端硬碟應用。」

• 「成功將頻寬從 YouTube 轉向了真正生產力工具。」

老闆會覺得你不是在管機器，你是在管「公司的數位資產」。這時候要談明年的維護費，或者是幫你自己爭取換個大一點的螢幕，勝算就高多了。

六、 結語：從「看門人」變成「引路人」

Zone 是領土，App-ID 就是規矩。 PA-1410 的強大，不在於它能撐多少 Gbps，而在於它能多細緻地理解你的流量。