O roteamento por usuário não parece funcionar

Question

Então, estou tentando implementar o roteamento por usuário para que eu possa rotear todo o tráfego de torrent do btpd por uma VPN. Infelizmente, o btpd não permite que você se conecte a um endereço IP específico. : (

Eu decidi tentar seguir este guia .

Basicamente, você marca qualquer pacote e então faz SNAT ou DNAT ou MASQUERADE para os pacotes, então usa as regras de ip para forçar uma tabela de rotas específica.

No final, minha configuração:

(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 (é onde eu marco os pacotes):

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  

Meu iptables -t nat (onde eu mudo o endereço de origem):

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  

Saída de 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 

E, finalmente, a saída de ip route show table 42 :

default via 10.1.1.1 dev tun0 

Agora, tudo parece funcionar bem quando eu faço um tcpdump na minha interface VPN em primeiro lugar. Mas, então, tornou-se evidente que meus programas não estão recebendo o SYN-ACK do shake de mão de três.

Esta é a saída do usuário com o uid 1000 executando curvar 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>

Como você pode ver, o mascaramento parece estar funcionando e estou recebendo uma resposta de retorno. No entanto, o curl age como se não estivesse recebendo a resposta. Isso é verificado rapidamente com um netstat -an | grep SYN que mostra que o curl estava tentando usar minha rede interna, não a VPN.

tcp        0      1 172.29.5.10:58000       219.94.163.75:80        SYN_SENT

Eu tentei fazer SNAT e DNAT versus MASQUERADE para o mesmo resultado exato. Neste ponto, não sei por que o curl não está recebendo uma resposta. Obrigado.

    

Answer 1

Por favor, verifique se o rp_filter está desativado. Veja a seção 10.1 do LARTC HOWTO . Veja também esta resposta em uma pergunta semelhante

Além disso, se você fizer um ip route show table main | grep 'dev tun0' , provavelmente verá uma rota como abaixo. Você precisa criar uma rota como esta, seu table 41 .

10.1.1.0/24  proto kernel  scope link dev tun0 src 10.1.1.4

    

Answer 2

A solução é desabilitar o rp_filter como dito anteriormente. Mas você não deve desabilitar o rp_filter em vão. Eu tentei isso e descobri que você precisa desligá-lo apenas na interface "por usuário", que era o ppp0 no meu caso:

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

É claro que você pode fazer isso mais corretamente, colocando-o em /etc/sysctl.conf .