6 votos

Por usuario enrutamiento ' t parecen funcionar

Así que, estoy tratando de implementar por usuario de enrutamiento de lo que soy capaz de enrutar todo el btpd torrente de tráfico a través de una VPN. Por desgracia, btpd actualmente no permiten enlazar a una dirección IP específica. :(

Me decidí a tratar de seguir esta guía.

Básicamente, se marcan los paquetes y, a continuación, hacer SNAT o DNAT o de DISFRACES para los paquetes, a continuación, utilizar normas de propiedad intelectual a la fuerza de una ruta específica de la tabla.

En fin, mi configuración:

(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 (aquí es donde me marca los paquetes):

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  

Mi iptables -t nat (Donde puedo cambiar la dirección de origen):

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  

Salida 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 

Y por último, la salida de ip route show table 42:

default via 10.1.1.1 dev tun0 

Ahora, todo parece funcionar bien cuando hago un tcpdump en mi interfaz VPN en primera. Pero, entonces es evidente que mis programas no están recibiendo el SYN-ACK del trio movimiento de la mano.

Este es el resultado de que el usuario con uid 1000 funcionando 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>

Como se puede ver, el enmascarado parece estar funcionando y estoy obteniendo un retorno de la respuesta. Sin embargo, curl de hechos como la no recepción de la respuesta. Esto es rápidamente verificado con un netstat -an | grep SYN que muestra curl estaba tratando de usar mi internel de red, no de la VPN.

tcp        0      1 172.29.5.10:58000       219.94.163.75:80        SYN_SENT

He intentado hacer SNAT y DNAT frente a la MASCARADA para el mismo resultado exacto. En este punto, no estoy seguro de por qué curl es no recibir una respuesta. Gracias.

2voto

Zoredache Puntos 84524

Por favor verificar que rp_filter esté desactivado. Consulte sección 10.1 del HOWTO de LARTC.. También vea esta respuesta en una pregunta similar


También, si haces un ip route show table main | grep 'dev tun0' , probablemente verá una ruta como por debajo. Es necesario crear una ruta como esta su table 41 .

10.1.1.0/24  proto kernel  scope link dev tun0 src 10.1.1.4

2voto

Mel Padden Puntos 653

La solución es desactivar rp_filter como se dijo anteriormente. Pero no debería desactivar rp_filter en vano. Intentó esto y me enteré de que usted necesita apagar solamente a la interfaz "por usuario", que fue ppp0 en mi caso:

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

Por supuesto puede hacerlo más correcto poniendo a /etc/sysctl.conf .

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: