欄目：翻牆速遞

DNS隧道可以實現 DoH和DoT

2023 年 8 月 7 日下午 7:34

dnstt是一種新的DNS隧道，可以與DNS over HTTPS和DNS over TLS解析器一起使用，根據Turbo Tunnel的理念設計。

https://www.bamsoftware.com/software/dnstt/

git clone https://www.bamsoftware.com/git/dnstt.git

它與其他DNS隧道有何不同？

它可以與DNS over HTTPS（DoH）和DNS over TLS（DoT）解析器一起使用，這使得網路觀察者更難以判斷是否使用了隧道。
它嵌入了一個適當的可靠性和會話協議（KCP+smux）。客戶端和服務器可以同時發送和接收數據，客戶端無需等待一個查詢接收到響應后再發送下一個查詢。同時進行多個查詢有助於提高性能。（這就是Turbo Tunnel的概念。）
它使用Noise協議對隧道進行端到端的加密和認證，與DoH/DoT加密分開。

.——. | .——–. .——.
|tunnel| | | public | |tunnel|
|client|<—DoH/DoT—>|resolver|<—UDP DNS—>|server|
『——『 |c 『——–『『——『
| |e |
.——. |n .——.
|local | |s |remote|
| app | |o | app |
『——『 |r 『——『

這樣的DNS隧道對於繞過審查是有用的。想象一下，一個審查者可以觀察到客戶端⇔解析器的連接，但無法觀察到解析器⇔伺服器的連接（圖中的垂直線）。傳統基於UDP的DNS隧道通常被認為很容易被檢測到，因為它們生成的DNS消息的格式不同尋常，而且每個DNS消息必須帶有隧道伺服器的域名標記，因為中間的遞歸解析器需要知道將它們轉發到哪裡。但是使用DoH或DoT，客戶端⇔解析器的DNS消息是加密的，因此審查者不能輕易地看到正在使用隧道。（當然，根據加密流量的數量和時序可能仍然可能啟髮式地檢測到隧道，僅僅加密本身並不能解決這個問題。）

我希望這個軟體發布可以展示這種類型的隧道設計的潛力。目前，該軟體不提供TUN/TAP網路介面，甚至不提供SOCKS或HTTP代理介面。它只是將本地TCP套接字連接到遠程TCP套接字。不過，您可以相對容易地設置它以像普通的SOCKS或HTTP代理一樣工作，見下文。
DNS區設置

DNS隧道通過使隧道伺服器充當特定DNS區的權威解析器來工作。中間的解析器通過將該區域的子域的查詢轉發到隧道伺服器來充當代理。要設置DNS隧道，您需要一個域名和一個可以運行伺服器的主機。

假設您的域名是example.com，您的主機的IP地址是203.0.113.2和2001:db8::2。轉到您的域名註冊商的配置面板，並添加三個新記錄：

A    tns.example.com    指向203.0.113.2
AAAA    tns.example.com    指向2001:db8::2
NS    t.example.com    由tns.example.com管理

tns和t標籤可以是任何您想要的內容，但tns標籤不應是t標籤的子域（該子域下的所有內容都保留給隧道負載）。t標籤應該很短，因為DNS消息中的空間有限，而且域名佔用其中的一部分。
隧道伺服器設置

在伺服器主機上運行以下命令；即在上面的示例中的tns.example.com / 203.0.113.2 / 2001:db8::2上運行。

cd dnstt-server
go build

首先，您需要為端到端隧道加密生成加密密鑰。

./dnstt-server -gen-key -privkey-file server.key -pubkey-file server.pub
privkey寫入server.key
pubkey寫入server.pub

現在運行伺服器。127.0.0.1:8000是將轉發隧道流的TCP地址（圖中的「遠程應用程序」）。

./dnstt-server -udp :5300 -privkey-file server.key t.example.com 127.0.0.1:8000

隧道伺服器需要在埠53上可訪問。您可以直接綁定到埠53（-udp :53），但這需要您以root身份運行伺服器。最好像上面顯示的那樣在非特權埠上運行伺服器，並使用埠轉發將埠53轉發到它。在Linux上，以下命令將埠53轉發到埠5300：

sudo iptables -I INPUT -p udp –dport 5300 -j ACCEPT
sudo iptables -t nat -I PREROUTING -i eth0 -p udp –dport 53 -j REDIRECT –to-ports 5300
sudo ip6tables -I INPUT -p udp –dport 5300 -j ACCEPT
sudo ip6tables -t nat -I PREROUTING -i eth0 -p udp –dport 53 -j REDIRECT –to-ports 5300

您還需要為隧道伺服器連接到的內容提供一些內容。它可以是代理伺服器或其他任何內容。為了測試，您可以使用Ncat監聽器：

sudo apt install ncat
ncat -lkv 127.0.0.1 8000

隧道客戶端設置

cd dnstt-client
go build

將伺服器上的server.pub（公鑰文件）複製到客戶端。您不需要在客戶端上使用server.key（私鑰文件）。

選擇一個DoH或DoT解析器。這裡有一個DoH解析器的列表：

https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers

以及這裡有一個DoT解析器的列表：

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers#DNSPrivacyPublicResolvers-DNS-over-TLS%28DoT%29
https://dnsencryption.info/imc19-doe.html

要使用DoH解析器，請使用-doh選項：

./dnstt-client -doh https://doh.example/dns-query -pubkey-file server.pub t.example.com 127.0.0.1:7000

對於DoT，請使用-dot：

./dnstt-client -dot dot.example:853 -pubkey-file server.pub t.example.com 127.0.0.1:7000

127.0.0.1:7000指定了隧道的客戶端埠。連接到該埠的任何內容（圖中的「本地應用程序」）將通過解析器進行隧道傳輸，並連接到隧道伺服器上的127.0.0.1:8000。您可以使用Ncat客戶端測試它；運行此命令，您在客戶端終端中鍵入的任何內容都將顯示在伺服器上，反之亦然。

ncat -v 127.0.0.1 7000

如何創建標準代理

您可以通過使隧道伺服器轉發到標準代理伺服器來使隧道工作像普通的代理伺服器。我發現使用Ncat的HTTP代理伺服器模式很方便。

ncat -lkv –proxy-type http 127.0.0.1 3128
./dnstt-server -udp :5300 -privkey-file server.key t.example.com 127.0.0.1:3128

在客戶端上，將您的應用程序配置為使用隧道的本地埠（127.0.0.1:7000）作為HTTP/HTTPS代理：

./dnstt-client -doh https://doh.example/dns-query -pubkey-file server.pub t.example.com 127.0.0.1:7000
curl -x http://127.0.0.1:7000/ https://example.com/

我嘗試使用Firefox通過DNS隧道連接到Ncat HTTP代理，它可以正常工作。
本地測試

如果您只想看看它是如何工作的，而不想費心設置DNS區域或網路伺服器，您可以在本地主機上運行隧道的兩端。這種方式使用明文UDP DNS，所以不用說，跨互聯網使用這樣的配置是不隱蔽的。因為在這種情況下沒有中間解析器，您可以使用任何您想要的域名；只需在客戶端和伺服器上保持一致即可。

./dnstt-server -gen-key -privkey-file server.key -pubkey-file server.pub
./dnstt-server -udp 127.0.0.1:5300 -privkey-file server.key t.example.com 127.0.0.1:8000
ncat -lkv 127.0.0.1 8000

./dnstt-client -udp 127.0.0.1:5300 -pubkey-file server.pub t.example.com 127.0.0.1:7000
ncat -v 127.0.0.1 7000

當它工作時，您將在伺服器上看到如下的日誌消息：

2020/04/20 01:48:58 pubkey 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff
2020/04/20 01:49:00 begin session 468d274a
2020/04/20 01:49:03 begin stream 468d274a:3

以及在客戶端上看到如下的日誌消息：

2020/04/20 01:49:00 MTU 134
2020/04/20 01:49:00 begin session 468d274a
2020/04/20 01:49:03 begin stream 468d274a:3

注意事項

對於外部觀察者來說，DoH或DoT隧道是隱蔽的，但對於中間的解析器來說並非如此。如果解析器想要阻止您使用隧道，他們可以很容易地做到，只需不遞歸解析隧道伺服器的DNS區域的請求。然而，隧道仍然對惡意解析器的竊聽或篡改是安全的；解析器可以拒絕服務，但無法更改或讀取隧道的內容。

出於技術原因，該隧道要求解析器支持至少1232位元組的UDP負載大小，這比DNS保證的最小值512要大。我懷疑大多數公共的DoH或DoT伺服器都滿足這個要求，但我沒有進行過調查或其他任何操作。

我沒有進行任何系統性能測試，但我對Google、Cloudflare和Quad9解析器進行了一些初步測試。使用Google和Cloudflare時，通過Ncat傳輸文件時，我可以獲得超過100 KB/s的下載速度。Cloudflare的DoH解析器偶爾會發送「400 Bad Request」響應（當隧道客戶端看到這樣的意外狀態碼時，它會自動限制自身的速度）。Quad9解析器的性能似乎明顯不如其他解析器，但我不知道原因。