谷歌把35.199.192.0/19藏了7年，企業(yè)防火墻集體破防

全球企業(yè)每年在DNS架構(gòu)上燒掉的錢，夠買3艘航母。但有個IP段讓工程師集體失眠——35.199.192.0/19，谷歌Cloud DNS的"幽靈地址"，企業(yè)防火墻見一個攔一個。

這不是配置錯誤，是設(shè)計層面的死結(jié)。一位剛踩完坑的架構(gòu)師在GitHub吐槽：「我們花了兩周排查，最后發(fā)現(xiàn)是谷歌自己埋的雷。」

那個刪不掉的神秘路由

事情要從2024年說起。某跨國企業(yè)把核心業(yè)務(wù)遷上谷歌云，IT總監(jiān)的要求很簡單：本地Infoblox DNS必須繼續(xù)做老大，云上的記錄也得它說了算。

團隊選了Cloud DNS的轉(zhuǎn)發(fā)區(qū)（Forwarding Zone），把查詢指向本地數(shù)據(jù)中心。測試當天，防火墻日志炸了——源地址35.199.192.0/19的請求被批量丟棄。

這個地址段的詭異之處在于：它看起來是公網(wǎng)IP，實際上只在谷歌云內(nèi)部有意義。更離譜的是，每個VPC都有一條"隱形路由"指向它，控制臺里看不見，API刪不掉，VPC對等連接（VPC Peering）和Network Connectivity Center（網(wǎng)絡(luò)連接中心，NCC）都不交換這條路由。

企業(yè)安全團隊的反應(yīng)高度一致：陌生公網(wǎng)段？封。等工程師查明真相申請放行，變更流程走兩周，項目已經(jīng)黃了一半。

谷歌文檔里輕描淡寫提了一句「某些防火墻可能需要放行」，但沒解釋為什么這個地址會出現(xiàn)在本不該出現(xiàn)的場景里。

DNS查詢的"跨VPC死亡陷阱"

問題的根源比防火墻規(guī)則更深。Cloud DNS轉(zhuǎn)發(fā)區(qū)有兩種路由模式：標準模式走公網(wǎng)，私有模式走VPC內(nèi)部網(wǎng)絡(luò)。企業(yè)當然選私有模式——誰想把內(nèi)網(wǎng)DNS查詢暴露到互聯(lián)網(wǎng)？

但私有模式有個致命副作用：查詢源地址強制變成35.199.192.0/19。這個設(shè)計本意是讓目標DNS服務(wù)器能正確回包，卻在混合云場景里制造了連鎖災(zāi)難。

假設(shè)你有兩個VPC：App VPC跑業(yè)務(wù)，Infra VPC放DNS服務(wù)器。App VPC的Cloud DNS想把查詢轉(zhuǎn)發(fā)給Infra VPC的DNS VM。

查詢包從App VPC出發(fā)，源地址35.199.192.0/19，目標地址是Infra VPC的DNS VM。NCC把路由交換得很好，包能到。但響應(yīng)包返程時，Infra VPC的隱形路由生效了——35.199.192.0/19被認為在本地，根本不回App VPC。

查詢消失在黑洞里。超時。重試。再超時。

工程師抓包看到請求出去了，響應(yīng)沒回來，第一反應(yīng)是防火墻又抽風。折騰三天才發(fā)現(xiàn)，是谷歌自己的路由邏輯在搞事。

Network Connectivity Center的"最后一公里"悖論

NCC被谷歌定位為混合云網(wǎng)絡(luò)的中樞，支持SD-WAN、專線、VPN多種接入方式。它的核心能力是在不同VPC和本地網(wǎng)絡(luò)之間交換路由，讓資源互通。

但在DNS這個特定場景，NCC有個盲區(qū)：它交換的是子網(wǎng)路由，不是那條特殊的35.199.192.0/19。這意味著即使你把所有VPC都掛到NCC上，Cloud DNS的跨VPC轉(zhuǎn)發(fā)依然會掉進黑洞。

那位架構(gòu)師的解決方案堪稱暴力美學：在Infra VPC里部署一臺BIND虛擬機，假裝成IPAM（IP地址管理）平臺的網(wǎng)格成員。App VPC不直接轉(zhuǎn)發(fā)給這臺VM，而是通過DNS對等（DNS Peering）把查詢"嫁接"到Infra VPC的DNS上下文。

關(guān)鍵區(qū)別在于：DNS Peering不走數(shù)據(jù)平面，只在元數(shù)據(jù)層面把查詢目標切換到另一個VPC的Cloud DNS實例。響應(yīng)路徑完全由Infra VPC自己處理，繞開了跨VPC路由的死亡陷阱。

整個架構(gòu)用了三個VPC：App VPC跑業(yè)務(wù)負載，Infra VPC托管DNS橋接，SD-WAN VPC對接本地網(wǎng)絡(luò)。NCC負責讓App VPC知道怎么到達本地子網(wǎng)，但DNS查詢的閉環(huán)完全在Infra VPC內(nèi)完成。

企業(yè)IPAM的"權(quán)威執(zhí)念"

為什么非要折騰這么復(fù)雜的拓撲？直接讓Cloud DNS管所有記錄不行嗎？

不行。金融、醫(yī)療、制造業(yè)的合規(guī)部門有個執(zhí)念：IPAM平臺必須是唯一權(quán)威源。Infoblox、EfficientIP、BlueCat這些系統(tǒng)不只是DNS服務(wù)器，它們關(guān)聯(lián)著IP分配、設(shè)備發(fā)現(xiàn)、安全策略，是網(wǎng)絡(luò)治理的中樞神經(jīng)。

讓Cloud DNS自建權(quán)威區(qū)，等于在企業(yè)架構(gòu)里制造"影子DNS"，審計的時候解釋不清。更現(xiàn)實的問題是：云上的VM IP地址要同步回IPAM，變更記錄要留痕，這些都不是Cloud DNS的強項。

所以方案必須滿足：本地IPAM繼續(xù)當老大，云上查詢能找它，響應(yīng)能回來，防火墻不報警。

那位架構(gòu)師的設(shè)計里，Cloud DNS只扮演"智能接線員"角色。四個托管區(qū)（Managed Zone）分工明確：兩個Peering Zone負責把gcp.example.com和corp.example.com的查詢導(dǎo)向Infra VPC，兩個Forwarding Zone在Infra VPC內(nèi)部完成到BIND VM的最后一跳。

所有轉(zhuǎn)發(fā)都顯式指定forwarding_path = "private"，確保不走公網(wǎng)。BIND VM再向上游的企業(yè)IPAM發(fā)起遞歸查詢，拿到結(jié)果后原路返回。

35.199.192.0/19的"薛定諤公網(wǎng)"屬性

這個地址段的身份焦慮，折射出云計算的一個深層矛盾：什么是"內(nèi)部"？什么是"外部"？

在AWS，類似的功能用不同的地址實現(xiàn)。Azure有自己的方案。谷歌選擇了一個歷史上屬于IANA預(yù)留空間的范圍，但沒向企業(yè)防火墻廠商充分同步這個信息。

結(jié)果是一個經(jīng)典的安全/可用性沖突：嚴格遵循安全最佳實踐（屏蔽未知公網(wǎng)段）的防火墻，恰好破壞了云原生DNS的設(shè)計假設(shè)。

谷歌的文檔在2024年更新了幾次，增加了對35.199.192.0/19的解釋，但"非可移除路由"這個設(shè)計決策沒有動搖。工程師社區(qū)里有人提議用私有DNS解析器（Private DNS Resolver）作為替代方案，但那是另一個價格檔位的產(chǎn)品。

那位架構(gòu)師在復(fù)盤文檔里寫了一句：「理解Cloud DNS的轉(zhuǎn)發(fā)路徑，比配置它花的時間多十倍。」

查詢流程的最終形態(tài)是這樣的：App VM發(fā)起dig請求，命中App VPC的Peering Zone，查詢被元數(shù)據(jù)重定向到Infra VPC的Cloud DNS實例；Infra VPC的Forwarding Zone把查詢發(fā)給BIND VM，源地址35.199.192.0/19；BIND VM向企業(yè)IPAM遞歸，拿到10.0.2.10的A記錄；響應(yīng)沿原路返回，因為全程沒離開Infra VPC的上下文，隱形路由恰好生效。

一個查詢經(jīng)歷了三次DNS上下文切換，兩次VPC邊界穿越（邏輯上），最終靠"不穿越"的設(shè)計才成功。

SD-WAN設(shè)備的"雙面間諜"角色

架構(gòu)里的SD-WAN VM是個有趣的存在。它同時屬于兩個網(wǎng)絡(luò)：通過VPC Network Interface（網(wǎng)絡(luò)接口）接入谷歌云，通過外部網(wǎng)絡(luò)接口對接本地MPLS或互聯(lián)網(wǎng)專線。

NCC把它注冊為Router Appliance Spoke（路由器設(shè)備分支），自動交換路由。App VPC因此學會了到達本地子網(wǎng)的路徑，不需要手動配置靜態(tài)路由。

但DNS流量不走SD-WAN VM。這是刻意的設(shè)計——如果把DNS查詢也塞進SD-WAN隧道，源地址問題會更復(fù)雜，而且增加了單點故障風險。

SD-WAN VM只負責"東西向"的網(wǎng)絡(luò)連通，DNS是"南北向"的控制平面，物理隔離。

這種分層在架構(gòu)圖上看起來干凈，運維的時候卻容易讓人困惑：為什么網(wǎng)絡(luò)通了，DNS還是超時？因為NCC解決的是IP可達性，不是DNS上下文的一致性。

從BIND VM到生產(chǎn)就緒的gap

那位架構(gòu)師的方案用了BIND作為概念驗證，但企業(yè)落地時通常會換成IPAM廠商提供的官方網(wǎng)格成員鏡像。Infoblox有vNIOS，EfficientIP有SOLIDserver，BlueCat有類似產(chǎn)品。

這些鏡像的核心價值不是功能，是合規(guī)——廠商認證、安全補丁、支持合同。用BIND POC可以，上生產(chǎn)得換。

另一個隱藏成本是HA設(shè)計。BIND VM單點部署是架構(gòu)師的簡化，真實環(huán)境需要至少兩臺，跨可用區(qū)分布，加上健康檢查和自動故障轉(zhuǎn)移。Cloud DNS的Peering Zone本身是高可用的，但背后的轉(zhuǎn)發(fā)目標不能掉鏈子。

防火墻規(guī)則的管理也是持久戰(zhàn)。35.199.192.0/19要放行，BIND VM的IP要放行，SD-WAN VM的接口要放行，任何一次安全策略收緊都可能誤傷。

那位架構(gòu)師建議：把DNS相關(guān)的防火墻規(guī)則單獨成冊，變更評審時必須有人懂這個地址段的特殊含義。

查詢路徑的調(diào)試工具也值得 investment。dig +trace能看到遞歸過程，但看不到VPC邊界的元數(shù)據(jù)切換。谷歌云的Packet Mirroring（包鏡像）可以抓包，但35.199.192.0/19的源地址在鏡像流量里可能顯示異常，因為那是內(nèi)部實現(xiàn)細節(jié)。

最可靠的驗證方法是端到端測試：在App VPC放一臺VM，持續(xù)dig一個只有IPAM知道的內(nèi)部域名，監(jiān)控成功率和延遲。

Cloud DNS的產(chǎn)品邊界

整個方案繞了一大圈，本質(zhì)上是在填補Cloud DNS的產(chǎn)品缺口：它不提供原生的、跨VPC的私有DNS轉(zhuǎn)發(fā)能力。

Peering Zone是個精巧的補丁，但它要求目標VPC必須有對應(yīng)的托管區(qū)配置，不能直接把查詢?nèi)咏o任意IP。Forwarding Zone能指向任意IP，但受限于35.199.192.0/19的路由陷阱。

兩者的組合實現(xiàn)了功能，但增加了架構(gòu)復(fù)雜度。對比AWS Route 53的Resolver Endpoint，或者Azure Private DNS的虛擬網(wǎng)絡(luò)鏈接，Cloud DNS的混合云故事確實更難講。

谷歌的回應(yīng)方向是Private DNS Resolver，一個托管的出站解析器，可以部署在VPC內(nèi)部，避免35.199.192.0/19的問題。但價格、功能成熟度、與企業(yè)IPAM的集成度，都是待驗證的變量。

那位架構(gòu)師在文檔結(jié)尾列了三個備選方案：繼續(xù)維護BIND橋接、評估Private DNS Resolver、或者激進一點，把部分權(quán)威區(qū)遷移到Cloud DNS，降低對IPAM的依賴。

每個選項都有代價，沒有銀彈。

這個案例的啟示或許是：云計算的"托管服務(wù)"承諾，在混合云場景里需要打折扣。當企業(yè)有強合規(guī)要求、復(fù)雜網(wǎng)絡(luò)拓撲、遺留系統(tǒng)綁定的時候，云廠商的抽象層會露出接縫，需要工程師用創(chuàng)造性的臟活填補。

35.199.192.0/19就是那個接縫的標記。它不會消失，只會被更多人踩到。

那位架構(gòu)師最后更新文檔是在2024年12月，附了一張查詢流程的ASCII藝術(shù)圖，和一句備注：「如果谷歌哪天改了這條隱形路由的行為，整個方案會瞬間崩潰。但目前看來，他們動不了——太多存量依賴了。」

你的DNS架構(gòu)里，有沒有類似的"幽靈地址"在潛伏？