1.為什么使用TPROXY才能代理UDP

在進行TCP的代理時，只要在NET表上無腦進行REDIRECT就好了。例如使用ss-redir,你只要把tcp的流量redirect到ss-redir監聽的端口上就OK了。但是當你使用這種方法的時候，就會不正常，因為對于UDP進行redirect之后，原始的目的地址和端口就找不到了。

這是為什么呢？

ss-redir的原理很簡單：使用iptables對PREROUTING與OUTPUT的TCP/UDP流量進行REDIRECT(REDIRECT是DNAT的特例)，ss—redir在捕獲網絡流量后，通過一些技術手段獲取REDIRECT之前的目的地址(dst)與端口(port)，連同網絡流量一起轉發至遠程服務器。

針對TCP連接，的確是因為Linux Kernel連接跟蹤機制的實現才使獲取數據包原本的dst和port成為可能，但這種連接跟蹤機制并非只存在于TCP連接中，UDP連接同樣存在，conntrack -p udp便能看到UDP的連接跟蹤記錄。內核中有關TCP與UDP的NAT源碼/net/netfilter/nf_nat_proto_tcp.c和/net/netfilter/nf_nat_proto_udp.c幾乎一模一樣，都是根據NAT的類型做SNAT或DNAT。

那這究竟是怎么一回事？為什么對于UDP連接就失效了呢？

回過頭來看看ss-redir有關獲取TCP原本的dst和port的源碼，核心函數是getdestaddr：

static int

getdestaddr(int fd, struct sockaddr_storage *destaddr)

{

socklen_t socklen = sizeof(*destaddr);

int error = 0;

error = getsockopt(fd, SOL_IPV6, IP6T_SO_ORIGINAL_DST, destaddr, &socklen);

if (error) { // Didn't find a proper way to detect IP version.

error = getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, destaddr, &socklen);

if (error) {

return -1;

}

}

return 0;

}

在內核源碼中搜了下有關SO_ORIGINAL_DST的東西，看到了getorigdst：

static int

getorigdst(struct sock *sk, int optval, void __user *user, int *len)

{

const struct inet_sock *inet = inet_sk(sk);

const struct nf_conntrack_tuple_hash *h;

struct nf_conntrack_tuple tuple;

memset(&tuple, 0, sizeof(tuple));

lock_sock(sk);

tuple.src.u3.ip = inet->inet_rcv_saddr;

tuple.src.u.tcp.port = inet->inet_sport;

tuple.dst.u3.ip = inet->inet_daddr;

tuple.dst.u.tcp.port = inet->inet_dport;

tuple.src.l3num = PF_INET;

tuple.dst.protonum = sk->sk_protocol;

release_sock(sk);

/* We only do TCP and SCTP at the moment: is there a better way? */

if (tuple.dst.protonum != IPPROTO_TCP &&

tuple.dst.protonum != IPPROTO_SCTP) {

pr_debug("SO_ORIGINAL_DST: Not a TCP/SCTP socket\n");

return -ENOPROTOOPT;

}

We only do TCP and SCTP at the moment。Oh，shit！只針對TCP與SCTP才能這么做，并非技術上不可行，只是人為地阻止罷了。

2.TPROXY

為了在redirect UDP后還能夠獲取原本的dst和port，ss-redir采用了TPROXY。Linux系統有關TPROXY的設置是以下三條命令：

ip rule add fwmark 0x2333/0x2333 pref 100 table 100

ip route add local default dev lo table 100

iptables -t mangle -A PREROUTING -p udp -j TPROXY --tproxy-mark 0x2333/0x2333 --on-ip 127.0.0.1 --on-port 1080

大意就是在mangle表的PREROUTING中為每個UDP數據包打上0x2333/0x2333標志，之后在路由選擇中將具有0x2333/0x2333標志的數據包投遞到本地環回設備上的1080端口；對監聽0.0.0.0地址的1080端口的socket啟用IP_TRANSPARENT標志，使IPv4路由能夠將非本機的數據報投遞到傳輸層，傳遞給監聽1080端口的ss-redir。IP_RECVORIGDSTADDR與IPV6_RECVORIGDSTADDR則表示獲取送達數據包的dst與port。

可問題來了：要知道mangle表并不會修改數據包，那么TPROXY是如何做到在不修改數據包的前提下將非本機dst的數據包投遞到換回設備上的1080端口呢？

這個問題在內核中時如何實現的，還待研究，但是確定是TPROXY做了某些工作。

TPROXY主要功能：

重定向一部分經過路由選擇的流量到本地路由進程(類似NAT中的REDIRECT)

在非本地IP上起監聽。監聽后就可以轉發了(神奇吧)

TPROXY要解決的兩個重要的問題

1.套接字如何監聽到非本地IP地址。

先用setsockopt函數為套接字設置IP_TRANSPARENT標識，再去監聽0.0.0.0地址這樣的方式來實現監聽任意IP。

2.如何獲取的原始目標的端口 。

先調用setsockopt (s, IPPROTO_IP, IP_RECVORIGDSTADDR, &n, sizeof(int))函數為套接字設置IP_RECVORIGDSTADDR標識，然后通過recvmsg函數從tproxy那邊接受發過來的msghdr結構體信息，并循環遍歷cmsghdr成員最終獲取到原始目標的地址和端口，也就是說tproxy會向msghdr(附屬數據結構)填入原始目標ip和端口信息，再通過sendmsg函數發送給代理應用。

總結

以上是生活随笔為你收集整理的tproxy_Linux使用TPROXY进行UDP的透明代理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。