L'instradamento per utente non sembra funzionare

Quindi, sto cercando di implementare il routing per utente in modo che sia in grado di percorrere tutto il traffico torrent btpd su una VPN. Purtroppo, btpd non consente attualmente di legarsi a un determinato indirizzo IP. 🙁

Ho deciso di cercare di seguire questa guida .

  • Impostazione di HP ProCurve 2810-24G per iSCSI?
  • Perché i cavi ethernet hanno 8 fili?
  • Il server smette di rispondere
  • trovare la migliore latenza di networking tra due paesi
  • Aggiunta di un nuovo utente in linux da uno script
  • Uptime per un singolo servizio
  • Fondamentalmente, contrassegnate i pacchetti e fate SNAT o DNAT o MASQUERADE sui pacchetti, quindi usate le regole ip per forzare una tabella di path specifica.

    Alla fine, il mio setup:

    (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 PtP: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 (questo è where contrassegna i pacchetti):

     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 

    Il mio iptables -t nat (where commuto l'indirizzo di origine):

     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 

    L'output della 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 infine, l'output del ip route show table 42 :

     default via 10.1.1.1 dev tun0 

    Ora, tutto sembra funzionare bene quando faccio una tcpdump sulla mia interface VPN in un primo momento. Ma, allora diventa evidente che i miei programmi non stanno ricevendo il SYN-ACK della treccia di tre secondi.

    Questa è l'output dell'utilizzatore con uid 1000 running 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> 

    Come potete vedere, il mascheramento sembra funzionare e sto ottenendo una risposta di return. Tuttavia, la curl agisce come se non ricevesse la risposta. Questo viene verificato rapidamente con un netstat -an | grep SYN netstat -an | grep SYN che mostra che la curl stava cercando di utilizzare la mia networking internel, non la VPN.

     tcp 0 1 172.29.5.10:58000 219.94.163.75:80 SYN_SENT 

    Ho provato a fare SNAT e DNAT contro MASQUERADE allo stesso risultato esatto. A questo punto, non so perché il curl non sta ricevendo una risposta. Grazie.

    2 Solutions collect form web for “L'instradamento per utente non sembra funzionare”

    Verifica che rp_filter sia distriggersto. Vedere la sezione 10.1 del LARTC HOWTO. . Vedi anche questa risposta su una domanda simile


    Inoltre, se si esegue una ip route show table main | grep 'dev tun0' ip route show table main | grep 'dev tun0' probabilmente vedrai un path come sotto. Devi creare un path come quello della tua table 41 .

     10.1.1.0/24 proto kernel scope link dev tun0 src 10.1.1.4 

    La soluzione è distriggersre rp_filter come detto in precedenza. Ma non si deve distriggersre invano il rp_filter. Ho provato questo e ho scoperto che devi distriggersrlo solo sull'interface "per utente", che era ppp0 nel mio caso:

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

    Naturalmente è ansible farlo più corretto mettendolo in /etc/sysctl.conf .

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.