WireGuard 教程：使用 DNS-SD 進行 NAT-to-NAT 穿透

2021 年 2 月 1 日
筆記
docker

原文鏈接：//fuckcloudnative.io/posts/wireguard-endpoint-discovery-nat-traversal/

WireGuard 是由 Jason A. Donenfeld 等人創建的下一代開源 VPN 協議，旨在解決許多困擾 IPSec/IKEv2、OpenVPN 或 L2TP 等其他 VPN 協議的問題。2020 年 1 月 29 日，WireGuard 正式合併進入 Linux 5.6 內核主線。

利用 WireGuard 我們可以實現很多非常奇妙的功能，比如跨公有雲組建 Kubernetes 集群，本地直接訪問公有雲 Kubernetes 集群中的 Pod IP 和 Service IP，在家中沒有公網 IP 的情況下直連家中的設備，等等。

如果你是第一次聽說 WireGuard，建議你花點時間看看我之前寫的 WireGuard 工作原理。然後可以參考下面兩篇文章來快速上手：

如果遇到某些細節不太明白的，再去參考 WireGuard 配置詳解。

本文將探討 WireGuard 使用過程中遇到的一個重大難題：如何使兩個位於 NAT 後面（且沒有指定公網出口）的客戶端之間直接建立連接。

WireGuard 不區分服務端和客戶端，大家都是客戶端，與自己連接的所有客戶端都被稱之為 Peer。

1. IP 不固定的 Peer

WireGuard 的核心部分是加密密鑰路由（Cryptokey Routing），它的工作原理是將公鑰和 IP 地址列表（AllowedIPs）關聯起來。每一個網路介面都有一個私鑰和一個 Peer 列表，每一個 Peer 都有一個公鑰和 IP 地址列表。發送數據時，可以把 IP 地址列表看成路由表；接收數據時，可以把 IP 地址列表看成訪問控制列表。

公鑰和 IP 地址列表的關聯組成了 Peer 的必要配置，從隧道驗證的角度看，根本不需要 Peer 具備靜態 IP 地址。理論上，如果 Peer 的 IP 地址不同時發生變化，WireGuard 是可以實現 IP 漫遊的。

現在回到最初的問題：假設兩個 Peer 都在 NAT 後面，且這個 NAT 不受我們控制，無法配置 UDP 埠轉發，即無法指定公網出口，要想建立連接，不僅要動態發現 Peer 的 IP 地址，還要發現 Peer 的埠。

找了一圈下來，現有的工具根本無法實現這個需求，本文將致力於不對 WireGuard 源碼做任何改動的情況下實現上述需求。

2. 中心輻射型網路拓撲

你可能會問我為什麼不使用中心輻射型（hub-and-spoke）網路拓撲？中心輻射型網路有一個 VPN 網關，這個網關通常都有一個靜態 IP 地址，其他所有的客戶端都需要連接這個 VPN 網關，再由網關將流量轉發到其他的客戶端。假設 Alice 和 Bob 都位於 NAT 後面，那麼 Alice 和 Bob 都要和網關建立隧道，然後 Alice 和 Bob 之間就可以通過 VPN 網關轉發流量來實現相互通訊。

其實這個方法是如今大家都在用的方法，已經沒什麼可說的了，缺點相當明顯：

當 Peer 越來越多時，VPN 網關就會變成垂直擴展的瓶頸。
通過 VPN 網關轉發流量的成本很高，畢竟雲伺服器的流量很貴。
通過 VPN 網關轉發流量會帶來很高的延遲。

本文想探討的是 Alice 和 Bob 之間直接建立隧道，中心輻射型（hub-and-spoke）網路拓撲是無法做到的。

3. NAT 穿透

要想在 Alice 和 Bob 之間直接建立一個 WireGuard 隧道，就需要它們能夠穿過擋在它們面前的 NAT。由於 WireGuard 是通過 UDP 來相互通訊的，所以理論上 UDP 打洞（UDP hole punching）是最佳選擇。

UDP 打洞（UDP hole punching）利用了這樣一個事實：大多數 NAT 在將入站數據包與現有的連接進行匹配時都很寬鬆。這樣就可以重複使用埠狀態來打洞，因為 NAT 路由器不會限制只接收來自原始目的地址（信使伺服器）的流量，其他客戶端的流量也可以接收。

舉個例子，假設 Alice 向新主機 Carol 發送一個 UDP 數據包，而 Bob 此時通過某種方法獲取到了 Alice 的 NAT 在地址轉換過程中使用的出站源 IP:Port，Bob 就可以向這個 IP:Port（2.2.2.2:7777）發送 UDP 數據包來和 Alice 建立聯繫。

其實上面討論的就是完全圓錐型 NAT（Full cone NAT），即一對一（one-to-one）NAT。它具有以下特點：

一旦內部地址（iAddr:iPort）映射到外部地址（eAddr:ePort），所有發自 iAddr:iPort 的數據包都經由 eAddr:ePort 向外發送。
任意外部主機都能經由發送數據包給 eAddr:ePort 到達 iAddr:iPort。

大部分的 NAT 都是這種 NAT，對於其他少數不常見的 NAT，這種打洞方法有一定的局限性，無法順利使用。

4. STUN

回到上面的例子，UDP 打洞過程中有幾個問題至關重要：

Alice 如何才能知道自己的公網 IP:Port？
Alice 如何與 Bob 建立連接？
在 WireGuard 中如何利用 UDP 打洞？

RFC5389 關於 STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程式）的詳細描述中定義了一個協議回答了上面的一部分問題，這是一篇內容很長的 RFC，所以我將盡我所能對其進行總結。先提醒一下，STUN 並不能直接解決上面的問題，它只是個扳手，你還得拿他去打造一個稱手的工具：

STUN 本身並不是 NAT 穿透問題的解決方案，它只是定義了一個機制，你可以用這個機制來組建實際的解決方案。

— RFC5389

STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程式）是一種網路協議，它允許位於NAT（或多重NAT）後的客戶端找出自己的公網地址，查出自己位於哪種類型的 NAT 之後以及 NAT 為某一個本地埠所綁定的公網埠。這些資訊被用來在兩個同時處於 NAT 路由器之後的主機之間建立 UDP 通訊。該協議由 RFC 5389 定義。

STUN 是一個客戶端－服務端協議，在上圖的例子中，Alice 是客戶端，Carol 是服務端。Alice 向 Carol 發送一個 STUN Binding 請求，當 Binding 請求通過 Alice 的 NAT 時，源 IP:Port 會被重寫。當 Carol 收到 Binding 請求後，會將三層和四層的源 IP:Port 複製到 Binding 響應的有效載荷中，並將其發送給 Alice。Binding 響應通過 Alice 的 NAT 轉發到內網的 Alice，此時的目標 IP:Port 被重寫成了內網地址，但有效載荷保持不變。Alice 收到 Binding 響應後，就會意識到這個 Socket 的公網 IP:Port 是 2.2.2.2:7777。

然而，STUN 並不是一個完整的解決方案，它只是提供了這麼一種機制，讓應用程式獲取到它的公網 IP:Port，但 STUN 並沒有提供具體的方法來向相關方向發出訊號。如果要重頭編寫一個具有 NAT 穿透功能的應用，肯定要利用 STUN 來實現。當然，明智的做法是不修改 WireGuard 的源碼，最好是借鑒 STUN 的概念來實現。總之，不管如何，都需要一個擁有靜態公網地址的主機來充當信使伺服器。

5. NAT 穿透示例

早在 2016 年 8 月份，WireGuard 的創建者就在 WireGuard 郵件列表上分享了一個 NAT 穿透示例。Jason 的示例包含了客戶端應用和服務端應用，其中客戶端應用於 WireGuard 一起運行，服務端運行在擁有靜態地址的主機上用來發現各個 Peer 的 IP:Port，客戶端使用原始套接字（raw socket）與服務端進行通訊。

/* We use raw sockets so that the WireGuard interface can actually own the real socket. */
sock = socket(AF_INET, SOCK_RAW, IPPROTO_UDP);
if (sock < 0) {
	perror("socket");
	return errno;
}

正如評論中指出的，WireGuard 擁有「真正的套接字」。通過使用原始套接字（raw socket），客戶端能夠向服務端偽裝本地 WireGuard 的源埠，這樣就確保了在服務端返迴響應經過 NAT 時目標 IP:Port 會被映射到 WireGuard 套接字上。

客戶端在其原始套接字上使用一個經典的 BPF 過濾器來過濾服務端發往 WireGuard 埠的回復。

static void apply_bpf(int sock, uint16_t port, uint32_t ip)
{
	struct sock_filter filter[] = {
		BPF_STMT(BPF_LD + BPF_W + BPF_ABS, 12 /* src ip */),
		BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ip, 0, 5),
		BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20 /* src port */),
		BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, PORT, 0, 3),
		BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 22 /* dst port */),
		BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, port, 0, 1),
		BPF_STMT(BPF_RET + BPF_K, -1),
		BPF_STMT(BPF_RET + BPF_K, 0)
	};
	struct sock_fprog filter_prog = {
		.len = sizeof(filter) / sizeof(filter[0]),
		.filter = filter
	};
	if (setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &filter_prog, sizeof(filter_prog)) < 0) {
		perror("setsockopt(bpf)");
		exit(errno);
	}
}

客戶端與服務端的通訊數據都被定義在 packet 和 reply 這兩個結構體中：

struct {
    struct udphdr udp;
    uint8_t my_pubkey[32];
    uint8_t their_pubkey[32];
} __attribute__((packed)) packet = {
    .udp = {
        .len = htons(sizeof(packet)),
        .dest = htons(PORT)
    }
};
struct {
    struct iphdr iphdr;
    struct udphdr udp;
    uint32_t ip;
    uint16_t port;
} __attribute__((packed)) reply;

客戶端會遍歷配置好的 WireGuard Peer（wg show <interface> peers），並為每一個 Peer 發送一個數據包給服務端，其中 my_pubkey 和 their_pubkey 欄位會被適當填充。當服務端收到來自客戶端的數據包時，它會向以公鑰為密鑰的 Peer 記憶體表中插入或更新一個 pubkey=my_pubkey 的 entry，然後再從該表中查找 pubkey=their_pubkey 的 entry，一但發現 entry 存在，就會將其中的 IP:Port 發送給客戶端。當客戶端收到回復時，會將 IP 和埠從數據包中解包，並配置 Peer 的 endpoint 地址（wg set <interface> peer <key> <options...> endpoint <ip>:<port>）。

entry 結構體源碼：

struct entry {
	uint8_t pubkey[32];
	uint32_t ip;
	uint16_t port;
};

entry 結構體中的 ip 和 port 欄位是從客戶端收到的數據包中提取的 IP 和 UDP 頭部，每次客戶端請求 Peer 的 IP 和埠資訊時，都會在 Peer 列表中刷新自己的 IP 和埠資訊。

上面的例子展示了 WireGuard 如何實現 UDP 打洞，但還是太複雜了，因為並不是所有的 Peer 端都能打開原始套接字（raw socket），也並不是所有的 Peer 端都能利用 BPF 過濾器。而且這裡還用到了自定義的 wire protocol，程式碼層面的數據（鏈表、隊列、二叉樹）都是結構化的，但網路層看到的都是二進位流，所謂 wire protocol 就是把結構化的數據序列化為二進位流發送出去，並且對方也能以同樣的格式反序列化出來。這種方式是很難調試的，所以我們需要另闢蹊徑，利用現有的成熟工具來達到目的。

6. WireGuard NAT 穿透的正解

其實完全沒必要這麼麻煩，我們可以直接利用 WireGuard 本身的特性來實現 UDP 打洞，直接看圖：

你可能會認為這是個中心輻射型（hub-and-spoke）網路拓撲，但實際上還是有些區別的，這裡的 Registry Peer 不會充當網關的角色，因為它沒有相應的路由，不會轉發流量。Registry 的 WireGuard 介面地址為 10.0.0.254/32，Alice 和 Bob 的 AllowedIPs 中只包含了 10.0.0.254/32，表示只接收來自 Registry 的流量，所以 Alice 和 Bob 之間無法通過 Registry 來進行通訊。

這裡有一點至關重要，Registry 分別和 Alice 與 Bob 建立了兩個隧道，這就會在 Alice 和 Bob 的 NAT 上打開一個洞，我們需要找到一種方法來從 Registry Peer 中查詢這些洞的 IP:Port，自然而然就想到了 DNS 協議。DNS 的優勢很明顯，它比較簡單、成熟，還跨平台。有一種 DNS 記錄類型叫 SRV記錄（Service Record，服務定位記錄），它用來記錄伺服器提供的服務，即識別服務的 IP 和埠，RFC6763 用具體的結構和查詢模式對這種記錄類型進行了擴展，用於發現給定域下的服務，我們可以直接利用這些擴展語義。

7. CoreDNS

選好了服務發現協議後，還需要一種方法來將其與 WireGuard 對接。CoreDNS 是 Golang 編寫的一個插件式 DNS 伺服器，是目前 Kubernetes 內置的默認 DNS 伺服器，並且已從 CNCF 畢業。我們可以直接寫一個 CoreDNS 插件，用來接受 DNS-SD（DNS-based Service Discovery）查詢並返回相關 WireGuard Peer 的資訊，其中公鑰作為記錄名稱，fuckcloudnative.io 作為域。如果你熟悉 bind 風格的域文件，可以想像一個類似這樣的域數據：

_wireguard._udp         IN PTR          alice._wireguard._udp.fuckcloudnative.io.
_wireguard._udp         IN PTR          bob._wireguard._udp.fuckcloudnative.io.
alice._wireguard._udp   IN SRV 0 1 7777 alice.fuckcloudnative.io.
alice                   IN A            2.2.2.2
bob._wireguard._udp     IN SRV 0 1 8888 bob.fuckcloudnative.io.
bob                     IN A            3.3.3.3

公鑰使用 Base64 還是 Base32 ？

到目前為止，我們一直使用別名 Alice 和 Bob 來替代其對應的 WireGuard 公鑰。WireGuard 公鑰是 Base64 編碼的，長度為 44 位元組：

$ wg genkey | wg pubkey
UlVJVmPSwuG4U9BwyVILFDNlM+Gk9nQ7444HimPPgQg=

Base 64 編碼的設計是為了以一種允許使用大寫字母和小寫字母的形式來表示任意的八位位元組序列。

— RFC4648

不幸的是，DNS 的 SRV 記錄的服務名稱是不區分大小寫的：

DNS 樹中的每個節點都有一個由零個或多個標籤組成的名稱 [STD13, RFC1591, RFC2606]，這些標籤不區分大小寫。

— RFC4343

Base32 雖然產生了一個稍長的字元串（56 位元組），但它的表現形式允許我們在 DNS 內部表示 WireGuard 公鑰：

Base32 編碼的目的是為了表示任意八位位元組序列，其形式必須不區分大小寫。

我們可以使用 base64 和 base32 命令來迴轉換編碼格式，例如：

$ wg genkey | wg pubkey > pub.txt
$ cat pub.txt
O9rAAiO5qTejOEtFbsQhCl745ovoM9coTGiprFTaHUE=
$ cat pub.txt | base64 -D | base32
HPNMAARDXGUTPIZYJNCW5RBBBJPPRZUL5AZ5OKCMNCU2YVG2DVAQ====
$ cat pub.txt | base64 -D | base32 | base32 -d | base64
O9rAAiO5qTejOEtFbsQhCl745ovoM9coTGiprFTaHUE=

我們可以直接使用 base32 這種不區分大小寫的公鑰編碼，來使其與 DNS 兼容。

編譯插件

CoreDNS 提供了編寫插件的文檔，插件必須要實現 plugin.Handler 介面：

type Handler interface {
    ServeDNS(context.Context, dns.ResponseWriter, *dns.Msg) (int, error)
    Name() string
}

我自己已經寫好了插件，通過 DNS-SD（DNS-based Service Discovery）語義來提供 WireGuard 的 Peer 資訊，該插件名就叫 wgsd。自己編寫的插件不屬於官方內置插件，從 CoreDNS 官方下載頁下載的可執行程式並不包括這兩個插件，所以需要自己編譯 CoreDNS。

編譯 CoreDNS 並不複雜，在沒有外部插件的情況下可以這麼編譯：

$ git clone //github.com/coredns/coredns.git
$ cd coredns
$ make

如果要加上 wgsd 插件，則在 make 前，要修改 plugin.cfg 文件，加入以下一行：

wgsd:github.com/jwhited/wgsd

然後開始編譯：

$ go generate
$ go build

查看編譯好的二進位文件是否包含該插件：

$ ./coredns -plugins | grep wgsd
  dns.wgsd

編譯完成後，就可以在配置文件中啟用 wgsd 插件了：

.:53 {
  wgsd <zone> <wg device>
}

可以來測試一下，配置文件如下：

$ cat Corefile
.:53 {
  debug
  wgsd fuckcloudnative.io. wg0
}

運行 CoreDNS：

$ ./coredns -conf Corefile
.:53
CoreDNS-1.8.1
linux/amd64, go1.15,

當前節點的 WireGuard 資訊：

$ sudo wg show
interface: wg0
  listening port: 52022

peer: mvplwow3agnGM8G78+BiJ3tmlPf9gDtbJ2NdxqV44D8=
  endpoint: 3.3.3.3:8888
  allowed ips: 10.0.0.2/32

下面就是見證奇蹟的時候，列出所有 Peer：

$ dig @127.0.0.1 _wireguard._udp.fuckcloudnative.io. PTR +noall +answer +additional

; <<>> DiG 9.10.6 <<>> @127.0.0.1 _wireguard._udp.fuckcloudnative.io. PTR +noall +answer +additional
; (1 server found)
;; global options: +cmd
_wireguard._udp.fuckcloudnative.io. 0 IN  PTR     TL5GLQUMG5VATRRTYG57HYDCE55WNFHX7WADWWZHMNO4NJLY4A7Q====._wireguard._udp.fuckcloudnative.io.

查詢每個 Peer 的 IP 和埠：

$ dig @127.0.0.1 TL5GLQUMG5VATRRTYG57HYDCE55WNFHX7WADWWZHMNO4NJLY4A7Q====._wireguard._udp.fuckcloudnative.io. SRV +noall +answer +additional

; <<>> DiG 9.10.6 <<>> @127.0.0.1 TL5GLQUMG5VATRRTYG57HYDCE55WNFHX7WADWWZHMNO4NJLY4A7Q====._wireguard._udp.fuckcloudnative.io. SRV +noall +answer +additional
; (1 server found)
;; global options: +cmd
tl5glqumg5vatrrtyg57hydce55wnfhx7wadwwzhmno4njly4a7q====._wireguard._udp.fuckcloudnative.io. 0 IN SRV 0 0 8888 TL5GLQUMG5VATRRTYG57HYDCE55WNFHX7WADWWZHMNO4NJLY4A7Q====.fuckcloudnative.io.
TL5GLQUMG5VATRRTYG57HYDCE55WNFHX7WADWWZHMNO4NJLY4A7Q====.fuckcloudnative.io. 0 IN A 3.3.3.3

🎉 🎉 🎉 完美！🎉 🎉 🎉

驗證公鑰是否匹配：

$ wg show wg0 peers
mvplwow3agnGM8G78+BiJ3tmlPf9gDtbJ2NdxqV44D8=
$ dig @127.0.0.1 _wireguard._udp.fuckcloudnative.io. PTR +short | cut -d. -f1 | base32 -d | base64
mvplwow3agnGM8G78+BiJ3tmlPf9gDtbJ2NdxqV44D8=

👍 👍 👍

8. 最終通訊流程

最終實現的通訊流程如下：

一開始，Alice 和 Bob 分別與 Registry 建立了隧道；接下來，Alice 上的 wgsd-client 向 Registry 節點上運行的 CoreDNS插件（wgsd）發起查詢請求，該插件從 WireGuard 資訊中檢索 Bob 的 endpoint 資訊，並將其返回給 wgsd-client；然後 wgsd-client 開始設置 Bob 的 endpoint；最後 Alice 和 Bob 之間直接建立了一條隧道。

任何提及 "建立隧道 "的地方都只是意味著發生了握手，數據包可以在 Peer 之間傳輸。雖然 WireGuard 確實有一個握手機制，但它比你想像的更像是一個無連接的協議。

任何安全協議都需要保持一些狀態，所以最初的握手是非常簡單的，只是建立用於數據傳輸的對稱密鑰。這種握手每隔幾分鐘就會發生一次，以提供輪換密鑰來實現完美的前向保密。它是根據時間來完成的，而不是根據之前數據包的內容來完成的，因為它的設計是為了優雅地處理數據包丟失的問題。

— wireguard.com/protocol

現在萬事俱備，只欠東風，只需要實現 wgsd-client 就完事了。

9. 實現 wgsd-client

wgsd-client 負責使 Peer 的 endpoint 配置保持最新狀態，它會檢索配置中的 Peer 列表，查詢 CoreDNS 中與之匹配的公鑰，然後在需要時為相應的 Peer 更新 endpoint 的值。最初的實現方式是以定時任務或者類似的調度機制運行，以序列化的方式檢查所有 Peer，設置 endpoint，然後退出。目前它還不是一個守護進程，後續會繼續改進優化。

wgsd-client 的源碼位於 wgsd 倉庫中的 cmd/wgsd-client 目錄。

下面開始進行最終的測試。

Alice 和 Bob 都在 NAT 後面，Registry 沒有 NAT，且有固定的公網地址。這三個 Peer 的資訊如下：

Peer	Public Key	Tunnel Address
Alice	xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=	10.0.0.1
Bob	syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=	10.0.0.2
Registry	JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=	10.0.0.254

它們各自的初始配置：

Alice

$ cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.1/32
PrivateKey = 0CtieMOYKa2RduPbJss/Um9BiQPSjgvHW+B7Mor5OnE=
ListenPort = 51820

# Registry
[Peer]
PublicKey = JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
Endpoint = 4.4.4.4:51820
PersistentKeepalive = 5
AllowedIPs = 10.0.0.254/32

# Bob
[Peer]
PublicKey = syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
PersistentKeepalive = 5
AllowedIPs = 10.0.0.2/32

$ wg show
interface: wg0
  public key: xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
  private key: (hidden)
  listening port: 51820

peer: JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
  endpoint: 4.4.4.4:51820
  allowed ips: 10.0.0.254/32
  latest handshake: 48 seconds ago
  transfer: 1.67 KiB received, 11.99 KiB sent
  persistent keepalive: every 5 seconds

peer: syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
  allowed ips: 10.0.0.2/32
  persistent keepalive: every 5 seconds

Bob

$ cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.2/32
PrivateKey = cIN5NqeWcbreXoaIhR/4wgrrQJGym/E7WrTttMtK8Gc=
ListenPort = 51820

# Registry
[Peer]
PublicKey = JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
Endpoint = 4.4.4.4:51820
PersistentKeepalive = 5
AllowedIPs = 10.0.0.254/32

# Alice
[Peer]
PublicKey = xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
PersistentKeepalive = 5
AllowedIPs = 10.0.0.1/32

$ wg show
interface: wg0
  public key: syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
  private key: (hidden)
  listening port: 51820

peer: JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
  endpoint: 4.4.4.4:51820
  allowed ips: 10.0.0.254/32
  latest handshake: 26 seconds ago
  transfer: 1.54 KiB received, 11.75 KiB sent
  persistent keepalive: every 5 seconds

peer: xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
  allowed ips: 10.0.0.1/32
  persistent keepalive: every 5 seconds

Registry

$ cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.254/32
PrivateKey = wLw2ja5AapryT+3SsBiyYVNVDYABJiWfPxLzyuiy5nE=
ListenPort = 51820

# Alice
[Peer]
PublicKey = xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
AllowedIPs = 10.0.0.1/32

# Bob
[Peer]
PublicKey = syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
AllowedIPs = 10.0.0.2/32

$ wg show
interface: wg0
  public key: JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
  private key: (hidden)
  listening port: 51820

peer: xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
  endpoint: 2.2.2.2:41424
  allowed ips: 10.0.0.1/32
  latest handshake: 6 seconds ago
  transfer: 510.29 KiB received, 52.11 KiB sent

peer: syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
  endpoint: 3.3.3.3:51820
  allowed ips: 10.0.0.2/32
  latest handshake: 1 minute, 46 seconds ago
  transfer: 498.04 KiB received, 50.59 KiB sent

Registry 與 Alice 和 Bob 都建立了連接，可以直接查詢它們的 endpoint 資訊：

$ dig @4.4.4.4 -p 53 _wireguard._udp.fuckcloudnative.io. PTR +noall +answer +additional

; <<>> DiG 9.10.6 <<>> @4.4.4.4 -p 53 _wireguard._udp.fuckcloudnative.io. PTR +noall +answer +additional
; (1 server found)
;; global options: +cmd
_wireguard._udp.fuckcloudnative.io. 0 IN  PTR     YUTRLED535IGKL7BDLERL6M4VJXSXM3UQQPL4NMSN27MT56AD4HA====._wireguard._udp.fuckcloudnative.io.
_wireguard._udp.fuckcloudnative.io. 0 IN  PTR     WMRID55V4ENHXQX2JSTYOYVKICJ5PIHKB2TR7R42SMIU3T5L4I5Q====._wireguard._udp.fuckcloudnative.io.

$ dig @4.4.4.4 -p 53 YUTRLED535IGKL7BDLERL6M4VJXSXM3UQQPL4NMSN27MT56AD4HA====._wireguard._udp.fuckcloudnative.io. SRV +noall +answer +additional

; <<>> DiG 9.10.6 <<>> @4.4.4.4 -p 53 YUTRLED535IGKL7BDLERL6M4VJXSXM3UQQPL4NMSN27MT56AD4HA====._wireguard._udp.fuckcloudnative.io. SRV +noall +answer +additional
; (1 server found)
;; global options: +cmd
yutrled535igkl7bdlerl6m4vjxsxm3uqqpl4nmsn27mt56ad4ha====._wireguard._udp.fuckcloudnative.io. 0 IN SRV 0 0 41424 YUTRLED535IGKL7BDLERL6M4VJXSXM3UQQPL4NMSN27MT56AD4HA====.fuckcloudnative.io.
YUTRLED535IGKL7BDLERL6M4VJXSXM3UQQPL4NMSN27MT56AD4HA====.fuckcloudnative.io. 0 IN A 2.2.2.2

完美，下面分別在 Alice 和 Bob 上啟動 wgsd-client 試試：

# Alice
$ ./wgsd-client -device=wg0 -dns=4.4.4.4:53 -zone=fuckcloudnative.io.
2020/05/20 13:24:02 [JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=] no SRV records found
jwhited@Alice:~$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=64 time=173.260 ms
^C
jwhited@Alice:~$ wg show
interface: wg0
  public key: xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
  private key: (hidden)
  listening port: 51820

peer: syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
  endpoint: 3.3.3.3:51820
  allowed ips: 10.0.0.2/32
  latest handshake: 2 seconds ago
  transfer: 252 B received, 264 B sent
  persistent keepalive: every 5 seconds

peer: JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
  endpoint: 4.4.4.4:51820
  allowed ips: 10.0.0.254/32
  latest handshake: 1 minute, 19 seconds ago
  transfer: 184 B received, 1.57 KiB sent
  persistent keepalive: every 5 seconds

# Bob
$ ./wgsd-client -device=wg0 -dns=4.4.4.4:53 -zone=fuckcloudnative.io.
2020/05/20 13:24:04 [JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=] no SRV records found
jwhited@Bob:~$ wg show
interface: wg0
  public key: syKB97XhGnvC+kynh2KqQJPXoOoOpx/HmpMRTc+r4js=
  private key: (hidden)
  listening port: 51820

peer: xScVkH3fUGUv4RrJFfmcqm8rs3SEHr41km6+yffAHw4=
  endpoint: 2.2.2.2:41424
  allowed ips: 10.0.0.1/32
  latest handshake: 22 seconds ago
  transfer: 392 B received, 9.73 KiB sent
  persistent keepalive: every 5 seconds

peer: JeZlz14G8tg1Bqh6apteFCwVhNhpexJ19FDPfuxQtUY=
  endpoint: 4.4.4.4:51820
  allowed ips: 10.0.0.254/32
  latest handshake: 1 minute, 14 seconds ago
  transfer: 2.08 KiB received, 17.59 KiB sent
  persistent keepalive: every 5 seconds

wgsd-client 成功發現了 Peer 的 endpoint 地址並更新了 WireGuard 的配置，最終 Alice 和 Bob 之間直接建立了一條隧道！

總結

本文探討了如何在受 NAT 限制的兩個 Peer 之間直接建立一條 WireGuard 隧道。本文提供的解決方案都是使用現有的協議和服務發現技術，以及自己寫了個可插拔的插件，你可以直接使用 dig 或 nslookup 來進行調試，不需要干擾或修改 WireGuard 本身。

當然，這個 CoreDNS 插件肯定還可以優化，wgsd-client 也需要繼續優化。比如，CoreDNS 伺服器是否應該限制只在 Registry 的隧道中可用？是否應該對域進行簽名？每次查詢 DNS 時是否都需要查詢一次 WireGuard 的 Peer 資訊，還是說可以用快取來解決？這些都是值得思考的問題。

wgsd 插件的程式碼是開源的，歡迎大家踴躍貢獻。

Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包發布地址//store.lameleg.com ，歡迎體驗。使用了最新的sealos v3.3.6版本。作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs載入問題，修復lvscare社區netlink與3.10內核不兼容問題,sealos生成百年證書等特性。更多特性 //github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群，釘釘群已經集成sealos的機器人實時可以看到sealos的動態。

Tags: docker