用Claude兩小時搭跨境WireGuard組網

簡而言之： Claude在WireGuard組網裡真正的貢獻，是把整套peer設定——每一個公鑰、每一段AllowedIPs、每一個endpoint——一致地產生出來，不出那種會吃掉你一個下午的手抄錯誤。這正是三到四個節點、兩小時能建成的原因。兩小時之內包含：金鑰、設定、防火牆規則、拉起連線，以及雙向驗證每一條路徑。兩小時之外的是：伺服器本身已經存在、跨境法遵審查、高可用設計、監控，以及金鑰輪替策略。

一家在深圳、香港和新加坡都有業務負載的公司，遲早需要這些伺服器之間私密地互通——一個資料庫副本、一個內部API、一個絕不該暴露在公網上的備份目標。而企業級SD-WAN報回來的那個數字，對四十個分支據點是合理的，對三台虛擬機則完全說不通。

WireGuard是那個顯而易見的替代方案。它很小、跑在核心裡，一份完整的設定檔短到一個畫面就能讀完。讓它顯得比實際更難的地方在於：每個peer都必須知道其他每個peer的公鑰和允許的位址範圍，而一個打錯的字元，會造出一條乾淨地建立起來、卻什麼也不傳的通道。正是這種失敗——看上去很有底氣、悄無聲息、追查起來極其枯燥——是語言模型能拿掉的那部分。

這是一份針對你自己擁有的基礎架構、在你自己掌控的雲端帳號裡進行的建置指南。如果你更想看看同一類基礎架構在中國雲端上長什麼樣，我們的阿里雲上的客服機器人建置講的是中國雲端基礎架構的那一側。

為什麼跨境的伺服器對伺服器互通比看上去難

問題很少出在通道協定本身，而是出在它周圍的一切。

雲端原生的對等互連跨不過這道縫。 VPC對等連線和中轉閘道在同一家雲端業者內部、甚至同一個地區內部都很好用。但當你的資產是深圳的阿里雲加新加坡的AWS，或者兩個國家的兩個獨立帳號時，原生方案要麼就到此為止，要麼變成一場商務談判。

商業方案的定價是為另一種體量的公司準備的。 託管SD-WAN、專線和雲端互連產品都是真正的答案，而它們的尺寸都是按「有分支據點、有設備、有合約期」的資產規模來定的。三台伺服器不是那種規模。

而法遵這一維確實不一樣。 涉及中國大陸地區執行個體的跨境網路連線屬於受監管的領域，什麼做法是合適的，取決於這條連線承載什麼、由誰營運、你的業務是什麼。這是一個應該在動工之前交給當地法律顧問和你的雲端業者法遵團隊的問題，而不是事後補票——本文的任何內容都不能取代那份意見。

於是團隊開始手工搭建。而手工搭建正是錯誤的來源，因為WireGuard最重要的那個欄位也是最不顯眼的那個：AllowedIPs 同時是路由表和加密層面的存取控制清單。一個方向寫錯，流量憑空消失；另一個方向寫錯，某個節點能夠到達的範圍遠超你的本意。

Claude在這裡到底做什麼，又做不了什麼

怎樣產生一套不出手抄錯誤、彼此一致的peer設定？

四個節點的全互聯網狀結構，每個節點需要三個peer段——總共十二段，每一段都帶著一個44字元的base64公鑰、一個位址範圍和一個endpoint。手打十二段這種東西，恰恰是人類會悄無聲息地做錯的活。

把拓撲作為一份規格交給Claude：節點名、地區、公網IP位址、監聽通訊埠、你選定的通道網段，以及每個節點的公鑰。它會回傳完整的設定集合，在建構上就是一致的，並附上驗證矩陣——哪個peer應該在哪個位址、沿哪個方向到達哪個peer。

它同樣會抓出那些在單個檔案裡看不見、放在一起看卻很明顯的結構性錯誤：兩個peer的 AllowedIPs 相互重疊，導致流量悄悄走了先比對上的那條；通道網段與既有的VPC網段或辦公室內網撞車；唯一那個在NAT後面的節點漏掉了 PersistentKeepalive；某個endpoint指向了對端根本路由不到的私網位址。

有一條邊界比其他所有條都重要：私鑰絕不進模型。 在將要使用它的那台機器上產生金鑰對，把私鑰留在那台機器上，只把公鑰交給Claude。公鑰本來就是設計來公開的。而一個被貼進任何聊天視窗的私鑰——無論是哪家業者——都已經離開了你的掌控，那一刻誠實的補救辦法是重新產生它。

為什麼拓撲、編址方案和信任邊界仍然要你自己定

你怎麼描述，模型就會照著產出一份能跑的設定——包括一份悄悄讓每個節點都能到達每一個網段的描述。那幾乎從來不是任何人的本意，而這也不是模型能抓到的錯誤，因為它無從得知你的意圖。

拓撲是一個關於失效模式的決定。 全互聯讓每一對節點都有直連路徑、沒有單點故障，代價是更多的設定和更多的防火牆規則。星狀結構更容易推理、也更便宜改，但中心節點一倒，全部跟著倒。請刻意地選。

編址方案是你的事。 選一個既不與你現在擁有的任何東西撞車、也不與你可能會有的東西撞車的通道網段。這是一個五分鐘的決定，而一旦服務把位址寫死進去，扭轉起來會很痛。

AllowedIPs 就是你的存取控制。 逐個peer地決定：香港節點是可以到達整個新加坡VPC，還是恰好一台主機上的一個通訊埠。先寫緊的那版，遠比在六個服務已經依賴鬆的那版之後再收緊要容易。

兩小時建置，逐步拆解

0:00–0:20 — 編址方案、拓撲決策、peer清單

為每個節點寫下：一個短名字、所在地區和雲端業者、它的公網位址（彈性或靜態IP——動態配發的位址會在執行個體第一次重開機時就把這張網撕開）、它將監聽的UDP通訊埠，以及它在通道網段裡持有的位址。決定全互聯還是星狀，並寫下理由，因為理由才是未來某個工程師需要的東西。

0:20–0:50 — 產生金鑰和逐peer的設定

在每個節點上本機產生金鑰對，把私鑰留在本機並設好嚴格的檔案權限。把公鑰收進你的清單，把這份清單交給Claude，要它給出完整的設定集合，外加由此推導出的可達性矩陣。在把任何東西寫進伺服器之前，先拿它對照你的清單讀一遍——這一步複核正是讓後面變快的原因，跳過它會把一個兩小時的建置變成一個兩小時的除錯。

0:50–1:20 — 各地區的雲端安全群組與防火牆規則

每個節點都需要在其監聽通訊埠上放行入方向UDP，而來源應該是它各個peer的具體公網位址，而不是 0.0.0.0/0。這是一件按業者、按地區重複的雜活：阿里雲和AWS之間、帳號和帳號之間，主控台版面、規則模型和預設出方向行為都不一樣。請把整整半小時預留出來；這一步最常超時。

1:20–1:50 — 拉起連線並雙向驗證每一條路徑

在每個節點上把介面拉起來，確認交握完成——WireGuard的狀態輸出會顯示每個peer最近一次交握的時間，而一個從不交握的peer是防火牆或endpoint的問題，不是金鑰的問題。然後測試每一個有向配對：四個節點意味著十二個方向，而只測六個、心想「反正是雙向的」，正是一條不對稱規則活到正式環境的方式。

不要停在ping上。在每條路徑上真正傳幾MB的資料——一條MTU設錯的通道，小封包完美通過、稍大一點就卡住。

1:50–2:00 — 固化設定、寫文件、交接

把介面設成開機自啟的服務，讓它扛得住重開機，然後把設定檔放到公司擁有的地方——一個設定儲存庫或金鑰管理服務，而不是工程師的筆電。記錄下編址方案、誰持有哪一把私鑰、開了哪些防火牆規則、為的是什麼。這十分鐘，就是「一項資產」和「一份負債」之間的差別。

WireGuard自建網 vs 託管SD-WAN vs 雲端原生互連

成本 — 自建WireGuard完勝。通道本身免費；你付的流出流量費本來就要付。
拿到第一條可用連線的時間 — WireGuard勝出，這也正是本文的論點。SD-WAN要走採購，雲端互連要等開通窗口。
跨業者、跨國家的涵蓋 — WireGuard勝出。它不在乎另一端在誰家的雲端上，而這恰恰是它適配「深圳加新加坡」這類資產的原因。
故障處理與路徑品質 — 託管SD-WAN明顯勝出。路徑選擇、多連線間的故障切換、按應用調度，這些就是產品本身，而一張手工搭的網一樣都沒有。
維運負擔 — 雲端原生互連勝出。沒有東西需要打修補程式、監控或輪替，這一點在第十二個月的價值比聽上去大。
凌晨兩點出事時的支援 — SD-WAN或雲端業者勝出。對一張自建的網來說，支援合約就是當初搭它的那個人，而這才是這份對比真正在問的問題。

第三個月會壞在哪裡

沒人安排金鑰輪替。 第一天產生的金鑰還在原地，包括那位早已換了團隊的工程師筆電上的那幾把。

MTU會遲到。 這張網好好跑了幾週，然後一個新服務開始傳更大的負載，只在其中一條路徑上開始逾時。

沒有任何東西在盯著。 一條通道斷了，而你得知的方式是某個使用者回報說報表是空的。交握狀態、通道可達性和規則漂移全都是可監控的，但在一張手工搭的網上，它們通常沒被監控。

這些都不新奇。它們只是一張網在有人負責時會得到的那種平常維護，以及在沒人負責時會得到的那種平常荒廢。

把這件事做對：金鑰保管、變更紀錄，以及何時該讓IT介入

在這張網承載任何要緊的東西之前，有三件事值得先定下來。

第一，金鑰保管。在WireGuard組網裡，私鑰*就是*存取控制——沒有第二因素，也沒有一個可以去撤銷的中心權威。請決定：它們在哪裡產生、存在哪裡、誰能讀、以及某人離職那天會發生什麼。那個答案應該是一套流程，而不是某個人的記憶。我們的AI+支援服務幫你把這類工作建在公司帳號和受治理的憑證上，而不是某個人的個人工具上；我們的託管IT支援則涵蓋圍繞它的身分與離職生命週期。

第二，一份變更紀錄。你開的每一條防火牆規則都有理由，而三個月後沒人會記得。把理由寫在規則旁邊。這也正是日後稽核不痛苦的原因，而在當時它不花任何成本。

第三，比建置活得更久的維護。一張網需要和任何其他網路設備一樣不炫目的照料：設定備份、韌體和套件更新、健康檢查，以及有人在看通道是不是真的還活著。這恰恰是網路與硬體維護所涵蓋的內容，包括VPN層級的監控和每季設定備份——也是「一張手工搭的網在第七個月會怎樣」的誠實答案。Brocent自2007年在北京創立以來一直在亞洲提供託管IT服務，總部位於新加坡，並自2016年起設有香港辦公室。

常見問題

自建的WireGuard網夠不夠跑正式環境？

對於少數幾個節點之間的私密伺服器互通，夠——WireGuard是一個成熟且口碑良好的協定，大量正式流量跑在它上面。一張自建的網給不了你的是：路徑冗餘、自動故障切換，以及一個可以打電話的業者。如果這條連線承載的東西一旦中斷就會讓業務停擺，那就要麼刻意把這些能力補上，要麼買一個自帶這些能力的產品。

私鑰由誰持有？有人離職時會怎樣？

誰能讀到每個節點上的那個檔案，誰就持有它。沒有中心化的撤銷機制，所以移除某人的存取權意味著：輪替他能觸及的那些節點上的金鑰，並更新每一個信任過這些金鑰的peer。請在需要它之前就把這件事計劃好，並把金鑰清單放在公司掌控的地方，而不是某個工程師的密碼管理器裡。

這和買SD-WAN有什麼不同？

SD-WAN是一個託管產品，額外提供路徑選擇、多連線之間的故障切換、應用感知的調度、集中策略，以及一份支援合約。而WireGuard組網就是每一對節點之間一條加密通道，別無其他。對三台需要私密路徑的伺服器來說，這個差別往往不值那個價錢。對一張承載語音和業務應用的多據點網路來說，它值。

涉及中國大陸地區的peer，跨境法遵上要考慮什麼？

多到不該由一個工程師在動工過程中拍板。從中國大陸地區執行個體出發的跨境連線屬於受監管的領域，什麼做法合適取決於這條連線承載什麼、以及你的主體是怎麼設立的。請在這張網上線之前，從當地法律顧問和你的雲端業者那裡拿到一個明確立場，並把那份決定的紀錄和設定放在一起。

Claude能看到我們的金鑰嗎？

只有你自己貼進去它才看得到——所以別貼。在將要使用它的節點上產生每一把私鑰，只共享公鑰，公鑰本來就是拿來共享的。作為一般做法，請核對你所用那個具體產品層級的資料處理與訓練條款，而不是靠假設，因為商業版和企業版通常與消費級不同，而且條款會變。

為什麼SSH能用，但傳檔案會卡住？

那是MTU問題的典型特徵。小封包放得下、能過去；更大的封包需要某種分片，而路徑上有東西沒有做，於是連線建立起來、然後就停住了。把通道介面的MTU調低，直到大檔案傳輸能穩定完成，是標準的處理辦法；而在拉起連線時就真正傳一次檔案，正是你能趕在使用者之前發現它的方式。

從哪裡開始

先做最小的可用版本：兩個節點、一條通道、兩側都寫緊的 AllowedIPs，以及一次真實的檔案傳輸作為驗收測試。在加第三個節點之前，先把這一條端到端跑通——一旦模式對了，這張網擴起來是乾淨的，而除錯一張一次性搭起來的四節點網，會是另一個、也更糟的下午。如果你更希望把這張網連同網路的其餘部分一起，妥善地建好、監控好、維護好，歡迎與我們聯絡。