每用户路由似乎不起作用

Question

所以，我正在尝试实现每用户路由，以便我能够通过 VPN 路由所有 btpd 种子流量。不幸的是，btpd 目前不允许您绑定到特定的 IP 地址。:(

我决定尝试遵循本指南。

基本上，您标记任何数据包，然后对数据包执行 SNAT 或 DNAT 或 MASQUERADE，然后使用 ip 规则强制特定路由表。

最后，我的设置：

(To my router)
eth1  Link encap:Ethernet  HWaddr 00:0a:cd:18:8a:ae  
      inet addr:172.29.5.10  Bcast:172.29.5.255  Mask:255.255.255.0
      inet6 addr: fe80::20a:cdff:fe18:8aae/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:2073338425 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2031270514 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:3014149031 (2.8 GiB)  TX bytes:1897259705 (1.7 GiB)
      Interrupt:17 Base address:0x6c00 

(my VPN)
tun0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:10.1.1.4  P-t-P:10.1.1.4  Mask:255.255.255.0
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:7842859 errors:0 dropped:0 overruns:0 frame:0
      TX packets:8040846 errors:0 dropped:41433 overruns:0 carrier:0
      collisions:0 txqueuelen:100 
      RX bytes:1544016294 (1.4 GiB)  TX bytes:1737654278 (1.6 GiB)

iptables -t mangle -vnL （这是我标记数据包的地方）：

Chain PREROUTING (policy ACCEPT 42 packets, 3595 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 42 packets, 3595 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 36 packets, 3461 bytes) pkts bytes target     prot opt in     out     source               destination         
0     0 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           owner UID match 1000 MARK set 0x2a 
0     0 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:!53 owner UID match 1000 MARK set 0x2a 
0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           owner UID match 1000 MARK set 0x2a 

Chain POSTROUTING (policy ACCEPT 36 packets, 3461 bytes) pkts bytes target     prot opt in     out     source               destination  

我的iptables -t nat（我切换源地址的地方）：

Chain PREROUTING (policy ACCEPT 10 packets, 536 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 10 packets, 536 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 6 packets, 360 bytes) pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 6 packets, 360 bytes) pkts bytes target     prot opt in     out     source               destination         
0     0 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0  

的输出ip rule show：

0:      from all lookup local 
32761:  from all fwmark 0x2a lookup 42 
32762:  from 10.1.0.0/16 lookup 42 
32766:  from all lookup main 
32767:  from all lookup default 

最后，输出ip route show table 42：

default via 10.1.1.1 dev tun0 

现在，当我首先在 VPN 接口上执行 tcpdump 时，一切似乎都正常。但是，很明显我的程序没有收到三向握手的 SYN-ACK。

这是 uid 1000 的用户运行 curl ifconfig.me 的输出：

21:34:08.585901 IP 10.1.1.4.55707 > www1465.sakura.ne.jp.http: S 342876994:3342876994(0) win 5840 <mss 1460,sackOK,timestamp 2892988166 0,nop,wscale 6>
21:34:08.852160 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892988166>
21:34:11.587175 IP 10.1.1.4.55707 > www1465.sakura.ne.jp.http: S 342876994:3342876994(0) win 5840 <mss 1460,sackOK,timestamp 2892991168 0,nop,wscale 6>
21:34:11.848906 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892991168>
21:34:14.890209 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892991168>
21:34:17.603173 IP 10.1.1.4.55707 > www1465.sakura.ne.jp.http: S 342876994:3342876994(0) win 5840 <mss 1460,sackOK,timestamp 2892997184 0,nop,wscale 6>
21:34:17.863614 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892997184>
21:34:20.901869 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892997184>
21:34:26.962022 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892997184>
21:34:39.099655 IP www1465.sakura.ne.jp.http > 10.1.1.4.55707: S 530223170:3530223170(0) ack 3342876995 win 65535 <mss 1368,nop,wscale 6,sackOK,timestamp 248042701 2892997184>

如您所见，伪装似乎起作用了，我收到了回复。但是，curl 表现得好像没有收到响应。这很快得到验证netstat -an | grep SYN，显示 curl 试图使用我的内部网络，而不是 VPN。

tcp        0      1 172.29.5.10:58000       219.94.163.75:80        SYN_SENT

我尝试将 SNAT 和 DNAT 与 MASQUERADE 进行相同的精确结果。在这一点上，我不确定为什么 curl 没有收到响应。谢谢。

Answer 1

请验证 rp_filter 是否已禁用。请参阅LARTC HOWTO 的第 10.1节。。另请参阅类似问题的答案

另外，如果你这样做，ip route show table main | grep 'dev tun0'你可能会看到如下所示的路线。您需要创建一条像这样的路线您的table 41.

10.1.1.0/24  proto kernel  scope link dev tun0 src 10.1.1.4