1.為什么使用TPROXY才能代理UDP
在進(jìn)行TCP的代理時(shí)缓醋，只要在NET表上無(wú)腦進(jìn)行REDIRECT就好了竹揍。例如使用ss-redir,你只要把tcp的流量redirect到ss-redir監(jiān)聽(tīng)的端口上就OK了呕寝。但是當(dāng)你使用這種方法的時(shí)候达舒，就會(huì)不正常只嚣，因?yàn)閷?duì)于UDP進(jìn)行redirect之后灿渴，原始的目的地址和端口就找不到了洛波。
這是為什么呢？
ss-redir的原理很簡(jiǎn)單：使用iptables對(duì)PREROUTING與OUTPUT的TCP/UDP流量進(jìn)行REDIRECT（REDIRECT是DNAT的特例）骚露，ss—redir在捕獲網(wǎng)絡(luò)流量后蹬挤，通過(guò)一些技術(shù)手段獲取REDIRECT之前的目的地址（dst）與端口（port），連同網(wǎng)絡(luò)流量一起轉(zhuǎn)發(fā)至遠(yuǎn)程服務(wù)器棘幸。
針對(duì)TCP連接焰扳，的確是因?yàn)長(zhǎng)inux Kernel連接跟蹤機(jī)制的實(shí)現(xiàn)才使獲取數(shù)據(jù)包原本的dst和port成為可能，但這種連接跟蹤機(jī)制并非只存在于TCP連接中误续，UDP連接同樣存在吨悍，conntrack -p udp便能看到UDP的連接跟蹤記錄。內(nèi)核中有關(guān)TCP與UDP的NAT源碼/net/netfilter/nf_nat_proto_tcp.c和/net/netfilter/nf_nat_proto_udp.c幾乎一模一樣蹋嵌，都是根據(jù)NAT的類型做SNAT或DNAT育瓜。
那這究竟是怎么一回事？為什么對(duì)于UDP連接就失效了呢栽烂？
回過(guò)頭來(lái)看看ss-redir有關(guān)獲取TCP原本的dst和port的源碼躏仇，核心函數(shù)是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;
}
在內(nèi)核源碼中搜了下有關(guān)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慧起！只針對(duì)TCP與SCTP才能這么做菇晃，并非技術(shù)上不可行册倒，只是人為地阻止罷了。
2.TPROXY
為了在redirect UDP后還能夠獲取原本的dst和port磺送，ss-redir采用了TPROXY驻子。Linux系統(tǒng)有關(guān)TPROXY的設(shè)置是以下三條命令：
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中為每個(gè)UDP數(shù)據(jù)包打上0x2333/0x2333標(biāo)志，之后在路由選擇中將具有0x2333/0x2333標(biāo)志的數(shù)據(jù)包投遞到本地環(huán)回設(shè)備上的1080端口估灿；對(duì)監(jiān)聽(tīng)0.0.0.0地址的1080端口的socket啟用IP_TRANSPARENT標(biāo)志崇呵，使IPv4路由能夠?qū)⒎潜緳C(jī)的數(shù)據(jù)報(bào)投遞到傳輸層，傳遞給監(jiān)聽(tīng)1080端口的ss-redir馅袁。IP_RECVORIGDSTADDR與IPV6_RECVORIGDSTADDR則表示獲取送達(dá)數(shù)據(jù)包的dst與port域慷。
可問(wèn)題來(lái)了：要知道m(xù)angle表并不會(huì)修改數(shù)據(jù)包，那么TPROXY是如何做到在不修改數(shù)據(jù)包的前提下將非本機(jī)dst的數(shù)據(jù)包投遞到換回設(shè)備上的1080端口呢汗销？
這個(gè)問(wèn)題在內(nèi)核中時(shí)如何實(shí)現(xiàn)的犹褒，還待研究，但是確定是TPROXY做了某些工作弛针。
TPROXY主要功能：
- 重定向一部分經(jīng)過(guò)路由選擇的流量到本地路由進(jìn)程(類似NAT中的REDIRECT)
- 在非本地IP上起監(jiān)聽(tīng)叠骑。監(jiān)聽(tīng)后就可以轉(zhuǎn)發(fā)了(神奇吧)
TPROXY要解決的兩個(gè)重要的問(wèn)題
- 1.套接字如何監(jiān)聽(tīng)到非本地IP地址。
先用setsockopt函數(shù)為套接字設(shè)置IP_TRANSPARENT標(biāo)識(shí)削茁，再去監(jiān)聽(tīng)0.0.0.0地址這樣的方式來(lái)實(shí)現(xiàn)監(jiān)聽(tīng)任意IP宙枷。 - 2.如何獲取的原始目標(biāo)的端口 。
先調(diào)用setsockopt (s, IPPROTO_IP, IP_RECVORIGDSTADDR, &n, sizeof(int))函數(shù)為套接字設(shè)置IP_RECVORIGDSTADDR標(biāo)識(shí)茧跋，然后通過(guò)recvmsg函數(shù)從tproxy那邊接受發(fā)過(guò)來(lái)的msghdr結(jié)構(gòu)體信息慰丛，并循環(huán)遍歷cmsghdr成員最終獲取到原始目標(biāo)的地址和端口，也就是說(shuō)tproxy會(huì)向msghdr(附屬數(shù)據(jù)結(jié)構(gòu))填入原始目標(biāo)ip和端口信息瘾杭，再通過(guò)sendmsg函數(shù)發(fā)送給代理應(yīng)用诅病。
參考：
https://blog.csdn.net/ts__cf/article/details/78942294
https://vvl.me/2018/06/09/from-ss-redir-to-linux-nat/
