Meraki 裝置在 Dashboard 顯示 unreachable 時，先到該 Organization 的 Firewall info 核對目前需要的目的地與連接埠，再查 DNS、NTP、上游防火牆、授權狀態與裝置 event log。不要只放行一個固定 Port，也不要先把設備判成故障。
Meraki 這類雲端網管平台，最迷人的賣點就是「設定一次、推到所有點」,一個人在辦公室按幾下，幾十個分點的 SSID、VLAN、防火牆政策就同步下去了。但這份方便是有代價的：它把「管理大腦」搬到了雲端，裝置本身變成聽命行事的手腳。手腳要聽話，前提是它隨時能跟大腦通上話。所以雲端網管的故障，多數不是設備壞了，而是出在三個環節：裝置連不連得上雲、授權有沒有到期、還有跨點的 Auto VPN 打不打得通。這篇就照著現場的頻率，把這三件事整理，也把背後的機制講清楚，讓你之後遇到能自己判斷方向。
先建立一個觀念：管理在雲端，資料在本地
要少走冤枉路，得先把架構的前提搞懂。傳統網路設備，設定檔就存在機器裡，你 SSH 或接 console 進去改；雲端網管把這件事拆成兩層：管理平面(control plane)放在雲端，資料平面(data plane)留在本地。白話講就是：「怎麼設定、誰來管」在雲上決定，但「封包實際怎麼走」還是在你機房裡跑。這代表兩件很重要的事。
第一，裝置開機後的第一要務，是主動對外撥號回雲端、建立一條管理通道，把自己註冊上去、再把設定拉下來。這條通道是「由內往外」發起的，所以你上游防火牆只要擋掉出向，裝置就成了斷線的孤兒，後台自然是 unreachable。第二，就算管理通道斷了，已經下發到本地的設定通常還會繼續生效一段時間，使用者上網不見得立刻有感：這也是為什麼很多人是等到要改設定、或裝置重開後拉不到組態，才驚覺雲端早就連不上了。把這一層理解透，後面每個故障你都推得出方向。
裝置上線：claim 只是登記，放行對外連線才是關鍵
claim 進 Inventory 不等於開始納管
把裝置序號 claim 到 Organization，只是把設備登記進 Inventory；接著還要指派到正確的 network，才會套用該站點設定。授權起算不能用「有沒有指派」判斷：效期要看訂單或 entitlement 的 Start Date／End Date。設備沒指派時可能不占使用數量，但不代表授權時鐘還沒走。採購後先到 Dashboard 核對授權日期，別把倉庫裡沒上架的設備當成「授權還沒開始」。
claim 本身失敗，最常見的兇手是拿整張訂單的 Order Number 去 claim。訂單一旦分批出貨，一組 Order Number 只能認領到其中單一批次，剩下的怎麼點都出不來。解法很單純：改用每台裝置機身上那組 12 碼序號逐台 claim,或是用 Order Claim Key 一次把整張單認領進來，就繞過批次的坑了。
連不上 Dashboard,先查對外連線，別急著怪設備
裝置顯示 unreachable 時，先查上游 DNS、NTP 與雲端連線，不要急著 Reset。Meraki 各產品線與韌體使用的目的 FQDN、IP 和連接埠可能不同，不能把 UDP 7351 或 TCP 443 的行為寫成全系列固定規則。請從 Dashboard 的 Help > Firewall info 或當期 upstream firewall rules 取得這個 organization／device 的清單，再依管理網段做必要的出向放行；看到 backup cloud connection 也要回到 Dashboard 查該設備的實際原因，而不是直接照舊埠表開洞。
除了 7351,還有兩個容易被忽略的基礎服務也要一起放行。一是 NTP 的 UDP 123:雲端網管靠 TLS 加密建立信任，而 TLS 交握會驗證憑證的有效期與時間戳，裝置的時鐘要是差太多，交握會直接被判失敗、連都連不上，偏偏這種「時間不對」的故障最不直覺，很多人查半天查不到根。二是 DNS 的 UDP/TCP 53,裝置要先解析得出雲端主機的名稱，才談得上後面的連線。
這裡要特別提醒一個常見的錯誤做法：不要去網路上抄一張固定 IP 清單就貼進防火牆。實際要放行的目的地位址，會隨著你這個 organization 加了哪些裝置、開了哪些服務、落在哪個 region 而不同，而且雲端後台的位址本來就會調整。正確做法是登入 Dashboard,到 Help 底下的「Firewall info」頁，那裡會產生一份專屬於你這個 org、當下有效的完整放行清單，照著那份交給網路組，才不會今天通、下個月又莫名其妙不通。
Meraki 授權怎麼看：先分 Subscription、Co-term、PDL
Meraki 現在同時有 Subscription Licensing、Co-termination（Co-term）與 Per-Device Licensing（PDL） 三種模式。先到 Organization > License Info 看自己的組織是哪一種，再談續約、到期或移轉；不能再用「只有 Co-term 跟 PDL」的舊說法處理。
- Subscription：依訂閱與產品範圍管理，日期與可用功能以 Dashboard 的訂閱資料為準。
- Co-term：組織內授權會換算成共同到期日；新建立的 organization 預設是這個模式。
- PDL：每台裝置各自套用授權。這是既有模式，目前已不接受新轉入；既有 PDL 可依官方流程移往 Co-term 或 Subscription，但移出後不能回到 PDL。
三種模式的到期處理與寬限規則不同，不要再用「一台過期就怎樣」或「整個組織一定第幾天關閉」一句話概括。續約前直接看 Dashboard 的警示、Start Date、End Date 與授權使用量，再對照 Meraki 當期授權文件；多據點採購則把設備交期、啟用日與續約責任一併寫進台帳。
Auto VPN:雲端只負責牽線，tunnel 是兩台設備直連
多分點之間免手動設定就能互連的 Auto VPN,是這套系統的招牌功能，但也最容易被它的名字誤導。很多人以為資料是繞經雲端中轉的，其實不是。它的運作是這樣：雲端有一個 VPN Registry 只扮演「媒人」的角色，負責記錄每一台 MX 設備當下的對外位址、有哪些內部網段，讓彼此交換得到聯絡方式；但真正的 IPsec 加密隧道，永遠是兩台 MX 之間點對點直連,資料流不經過雲端。看懂這個分工，你就知道排查要顧兩件事。
第一件，MX 必須連得上這個媒人。它要能對外連到 registry 的 UDP 9350 到 9381 這段埠，一旦被上游擋掉，後台會明明白白顯示「VPN Registry Disconnected」,連媒合都做不成，自然配不了對。第二件，媒合成功後，兩台設備要靠 UDP 打洞(hole punching)把隧道建起來：各自動態挑一個介於 32768 到 61000 的來源埠，主動往對方發封包，在自家防火牆上「戳」出一個臨時的回程通道，對方的封包才進得來。所以這段動態埠範圍的出向也得是通的。
後台報 NAT Type: Unfriendly 怎麼辦
Auto VPN 最典型的卡關，就是 Dashboard 把某一台或多台標成 NAT Type: Unfriendly。原因幾乎都出在上游那一層：如果前面接了負載平衡器、對稱式 NAT(Symmetric NAT)或政策很嚴的防火牆，它會針對不同的目的地，把你的來源埠或對外公網 IP 改寫成不一致的樣子。打洞這招賴以成立的前提，是「我從哪個埠出去、對方就能從哪個埠回來」,來源埠被中途改掉，洞就打歪了，隧道自然建不起來。
解法有兩條路。一是在 Site-to-site VPN 設定裡，把 NAT 穿透從 Automatic 改成 Manual: Port forwarding,在 32768 到 61000 這個範圍內自己挑一個 UDP 埠，到上游防火牆做一條靜態的埠對應，把公網某個埠的流量固定轉進這台 MX;二是乾脆用 1:1 NAT,給這台設備固定一個對外公網 IP。兩種做法本質都一樣：把原本浮動、會被改寫的對應關係「釘死」,讓對端每次都找得到同一扇門。另外還有一種特別容易踩到的環境，是電信端的 CGNAT(電信級大量共享 NAT),好幾個用戶共用一個公網 IP,這種先天就對打洞不友善，遇上了通常得回頭跟 ISP 要一個固定或可控的公網位址，才有得談。
順帶補一個 Client VPN 的雷。如果你另外有開給員工遠端撥入的 Client VPN(走 L2TP/IPsec),記得放行 UDP 500 跟 4500 這兩個 IKE 與 NAT-T 用的埠；而且千萬別在同一台 MX 上，把 500 或 4500 拿去做其他用途的 port forwarding,一旦挪用，Client VPN 會當場失效，而這種故障排查起來特別容易鬼打牆。
firmware 升級：不是按下去就沒事，要留退路
雲端網管的 firmware 是排程集中管理的，好處是不用一台一台手動刷，但也因為它會「自己動」,你更要掌握它的節奏，別讓升級撞在你最忙的時段。
機制上，平台排定升級時，會提前約 7 到 14 天寄信通知 org 管理員與設定好的收件人，實際動作則落在你自己設定的維護視窗(maintenance window)內執行：所以維護視窗一定要排在營運離峰，別讓它挑半夜升級，結果正好撞上你們的跨夜結帳或備份時段。萬一升上去發現新版本跟現場某個設定或設備咬不起來，平台留了退路：升級後 14 天內,可以在 Dashboard 自助回滾到前一個版本；但要注意，超過 14 天再回滾，退回去的是「最後一個穩定版」而不見得是你原本那一版，這中間的落差要先想清楚。
幾個現場養成的好習慣分享給你：
- 升級前務必先讀該版本的 release notes / changelog,重點看它列的 known issues 與 bug fixes,跟你現場實際用到的功能對照一遍。
- 能不跨大版就別跨，一次跳太多版風險最高，設定相容性與已知問題都變得難預測，寧可分階段慢慢往上推。
- 多點環境別安排「同一晚把 MX、switch、AP 全升」,先挑一個非關鍵的分點升、觀察一兩天沒事再擴大，把爆炸半徑控制住。
- 資安類的重大更新(例如修補高風險漏洞)時程可能比一般排程短很多，這種要優先處理、別無腦延後。
