Итак, я пытаюсь реализовать маршрутизацию для каждого пользователя, чтобы я мог маршрутизировать весь торрент-трафик btpd через VPN. К сожалению, в настоящее время 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
Теперь, когда я сначала делаю tcpdump на своем интерфейсе VPN, все работает нормально. Но потом стало очевидно, что мои программы не получают SYN-ACK трехстороннего рукопожатия.
Это результат работы пользователя curl ifconfig.me с uid 1000:
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, как было сказано ранее. Но не стоит зря отключать rp_filter. Я попробовал это и обнаружил, что вам нужно отключить его только в интерфейсе "для каждого пользователя", которым в моем случае был ppp0:
echo 0 | sudo tee /proc/sys/net/ipv4/conf/ppp0/rp_filter
Конечно, вы можете сделать это более правильно, поместив его в /etc/sysctl.conf.
Убедитесь, что rp_filter отключен. См. Раздел 10.1 LARTC HOWTO.. Также см этот ответ по аналогичному вопросу
Кроме того, если вы сделаете 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