騰訊雲帳號安全認證 騰訊雲 VPC 對等連接跨帳號授權失效導致路由丟失排查

一、故障現象：看起來是路由丟了，其實常常先壞的是授權

騰訊雲 VPC 對等連接在跨帳號場景裡很常見，兩個業務團隊分屬不同帳號，各自維護自己的 VPC、子網和路由表，靠對等連接打通私網。真正出故障時，最容易讓人誤判的地方，就是現象看起來像路由被刪了：一側子網突然無法訪問對端服務，控制台裡對端網段不通，查路由表時也找不到原來那條指向對等連接的路由。

很多人第一反應是去補路由，但補完之後還是不通；也有人直接懷疑安全組，折騰半天發現規則沒有問題。實際上，在跨帳號對等連接裡，授權狀態才是最容易被忽略的根因。當授權失效、被回收、過期，或者對端帳號做了變更之後，原本依賴這份授權的路由就可能失去生效基礎。從業務視角看，就是路由像是憑空丟失了。

這類問題最麻煩的地方在於，它不是單點故障，而是連接、授權、路由表、子網綁定、網段規劃幾層一起看，少看一層都可能誤判。要想快速恢復，不能只盯著路由表，而要沿著流量路徑反向排查。

二、先分清楚：是真的沒有路由，還是路由已經不生效

排查前先做一個很重要的判斷：故障現象到底屬於哪一類。第一類是路由表裡完全看不到對端網段，這通常意味著路由被刪除、被回滾，或者自動化腳本在變更時覆蓋了配置。第二類是路由還在，但流量不通，這通常意味著對等連接狀態異常、授權失效、對端網段變更，或者安全組和 ACL 攔截了流量。

跨帳號場景裡，第二類其實更常見。因為路由表顯示正常，不代表底層關係仍然有效；授權一旦失效，路由即使保留在配置裡，也可能不再被正常轉發。這也是為什麼很多人會說自己在控制台明明看見路由，業務卻仍然不通。

所以第一步不要急著做修復，而要先確認三件事：對等連接是否仍處於可用狀態，授權是否還有效，路由是否真的綁到了正確的路由表和正確的子網。只要這三件事有一項不對，流量都不可能穩定通過。

三、排查思路：從連接、授權、路由表、實例四層往回看

1. 先看對等連接本身是否正常

先到騰訊雲 VPC 控制台查看對等連接狀態。跨帳號連接通常涉及發起方和接受方兩邊，如果其中一邊刪除了連接、改了綁定 VPC，或者狀態變成待確認、已拒絕、已失效，那麼後續所有路由都只是表面配置，實際轉發都不會正常。

這一步要特別注意連接 ID 和對端 VPC 是否一致。有些故障不是連接沒了，而是新建了一條同名對等連接，路由卻還掛在舊連接上。結果看起來像路由配置沒問題，實際上流量根本沒有走到那條鏈路上。

2. 再看跨帳號授權是否仍有效

跨帳號對等連接的核心不是單純建立一條通道，而是雙方帳號對這條通道都有一致的認可。授權可能因為業務交接、權限調整、資源回收、到期清理等原因被撤掉。授權一旦失效，就算連接名稱還在，很多依賴它的路由也會變得不可用。

排查時要看授權是否還指向正確的帳號、正確的 VPC、正確的地域。跨地域和跨帳號混在一起時，最容易因為誤操作導致授權對不上。比如一方以為只是更改了說明文字，另一方卻把舊授權刪了重建，這樣原來的路由就可能全部失去依據。

3. 檢查路由表是不是掛錯了

很多人查路由時只看默認路由表，但實際生效的可能是另一張自定義路由表。子網綁定哪張路由表，才決定該子網真正採用哪組轉發規則。只要路由表掛錯，哪怕對等連接和授權都正常，流量一樣不會通。

這裡還有一個常見坑：路由條目加到了路由表裡，但對端網段寫錯了。比如對端 VPC 後來擴容了網段，原來的目標網段已經不完整，路由看起來還在，實際卻無法覆蓋新的地址段。這種情況最容易被誤認為是路由丟失。

4. 最後再驗證實例與安全策略

路由沒問題，不代表業務就一定能通。還要看源端和目的端的安全組、網絡 ACL、主機防火牆，以及應用是否真的在監聽對應端口。有些故障中，授權失效只是前半段原因，後半段還叠加了安全策略調整。這會讓排查變得更繞，因為修完路由之後，連通性測試仍然失敗。

因此，當你確認路由表和授權都恢復正常後，務必用最小代價的方法做驗證：先測 ICMP 或私網探測，再測端口，再測應用層請求。不要一上來就直接判斷業務正常，否則很容易把隱藏問題留到上線後爆發。

四、常見根因拆解：為什麼會出現授權失效導致路由丟失

根因一：授權被回收或過期

這是最典型的原因。跨帳號資源在交接時，常常先建臨時授權，等功能上線後再補正式流程。問題就在於，臨時授權最容易被遺忘，也最容易在清理過期資源時被批量刪除。當授權消失後，路由依賴的前提就沒了，結果就是流量不再走這條對等連接。

根因二：帳號角色變更，原來的管理鏈路斷了

有些團隊會把對等連接交給不同子帳號或協作者維護。當 IAM 角色、子帳號權限、協作者關係發生變更時，可能不是資源本身被刪了，而是已經沒有人能正常查看或調整它。這種情況下，表面看是路由丟失，實際上是配置管理鏈路出了問題。

根因三：路由被自動化流程覆蓋

騰訊雲帳號安全認證 現在很多團隊都用腳本、模板或者基礎設施即代碼管理網路配置。好處是效率高，壞處是如果模板沒有把對等路由納入完整管理，某次重刷配置時就可能把手工加上的路由覆蓋掉。尤其在雙帳號協作裡，一邊手工改，一邊自動化覆蓋，最容易造成路由時有時無。

騰訊雲帳號安全認證 根因四：網段規劃後期變動

不少故障不是當場發生，而是網段擴容後才暴露。比如一開始 A、B 兩個 VPC 網段不衝突，之後一方新增子網，地址段與對端部分重疊，或者新子網沒被加入路由範圍，結果一部分流量通、一部分不通。排查到最後才發現，問題不是路由丟了，而是路由覆蓋範圍不完整。

五、實際修復：按順序處理，避免越修越亂

真正處理這類故障時，建議按固定順序來，不要想到哪裡改到哪裡。

• 先確認雙方帳號都能看到同一條對等連接，且狀態正常。
• 再重新核對授權關係，必要時重新發起授權或重新接受授權。
• 然後檢查路由表，確認對端網段對應正確的下一跳是對等連接。
• 如果子網掛了多張路由表，逐個確認實際生效的那張。
• 最後做連通性驗證，從源到目的逐層測試。

如果確認授權確實失效，通常不要在舊配置上硬撐，而是先補回授權，再重新下發路由。這樣做的好處是能把關係鏈重新對齊，避免出現路由條目存在但狀態不穩定的情況。修復完成後，建議把雙方路由表都巡一遍，因為跨帳號對等連接往往是雙向通信，任何一邊漏掉路由都會造成單向或雙向不通。

如果故障發生後曾經手工刪改過路由，最好直接對照變更前快照重建，而不是只補一條看似缺失的路由。原因很簡單：很多路由問題不是單條缺失，而是網段、子網綁定、優先級、路由表選擇一起被改動了。只補一條，往往還會留下一個隱性坑。

騰訊雲帳號安全認證 六、如何快速驗證已經恢復

修復完成後，不要只看控制台上的綠色狀態。真正的驗證應該分成三步。第一步，從源 VPC 的一台測試機發起到對端網段的探測，確認基礎轉發可達。第二步，測試對端服務的實際端口，確保不是只有 ICMP 通、業務端口不通。第三步，查看雙方應用日誌和監控指標，確認請求沒有再被重試或超時。

如果條件允許，最好再做一次反向測試。跨帳號對等連接雖然看起來是一條通道，但實際排障時經常出現單向正常、單向異常的情況。反向測試能更快找出哪一側路由或安全策略沒補完整。

七、避免再次發生的做法，比事後修復更重要

這類問題最有效的解法，不是每次都靠人工救火，而是把管理方式固定下來。第一，跨帳號對等連接和路由變更要走同一套變更流程，不能一邊走工單，一邊私下手工改。第二，對等授權要有到期檢查和定期巡檢，尤其是臨時授權、測試授權，一定要標明用途和負責人。第三，路由表命名要清晰，子網綁定關係要留記錄，否則一旦出了問題，連哪張表在生效都要猜半天。

更進一步，建議把 VPC 對等連接、授權、路由表配置納入同一份基線文檔，並把關鍵變更記錄到值班手冊裡。當故障發生時，值班人員只要對照這份基線，就能快速判斷是授權問題、路由問題，還是子網掛表問題。對於跨帳號場景，這種標準化比臨場經驗更可靠。

最後還有一點很實用：定期做一次私網連通性巡檢。不要等業務報障才知道路由失效，平時就用固定探測機制檢查關鍵網段的互通狀態。只要把故障發現時間提前，授權失效導致的路由丟失就不會演變成大面積業務中斷。

結語：排查這類問題，關鍵是不要被表象帶跑

騰訊雲 VPC 對等連接跨帳號授權失效，看起來像路由丟失，實際上常常是連接關係失效後引發的連鎖反應。真正有效的排查，不是盯著控制台裡的一條路由反覆刷新，而是沿著連接、授權、路由表、子網、實例這條線一層層縮小範圍。只要把這個順序理順，大多數故障都能很快定位。

對運維來說，最怕的不是故障本身，而是把授權問題當成路由問題，把路由問題當成安全組問題，來回繞圈。只要建立起固定的排查習慣，跨帳號對等連接這種看似複雜的問題，其實並不難處理。真正決定效率的，不是工具多不多，而是你是否先找對了那個最該被檢查的點。