Linux

每使用者路由似乎不起作用

  • January 13, 2012

因此，我正在嘗試實現每使用者路由，以便能夠通過 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 沒有收到響應。謝謝。

請確認 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

解決方案是如前所述禁用 rp_filter。但是您不應該徒勞地禁用 rp_filter。我試過了，發現你只需要在“per-user”界面上關閉它，在我的例子中是 ppp0：

echo 0 | sudo tee /proc/sys/net/ipv4/conf/ppp0/rp_filter

當然你可以把它放到/etc/sysctl.conf.

引用自：https://serverfault.com/questions/304779

相關問答

Linux

具有非對稱路由的 Linux IPTables 目標 NAT？

  • July 26, 2010
檢視問答
Linux

通過特定介面路由應用程序流量

  • April 1, 2010
檢視問答
Linux

如何使用 NAT 將 Linux 伺服器設置為路由器

  • September 12, 2021
檢視問答
Networking

iptables PREROUTING 無效

  • June 7, 2021
檢視問答
Linux

通過firewall-cmd添加埠轉發規則後如何檢查ip-port映射

  • June 1, 2021
檢視問答
Linux

兩個路由器的埠轉發

  • December 14, 2020
檢視問答