web-dev-qa-db-ja.com

ユーザーごとのルーティングが機能していないようです

そのため、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を受信して​​いないことが明らかになりました。

これは、curlifconfig.meを実行しているuid1000のユーザーの出力です。

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は応答を受信して​​いないように動作します。これは、curlがVPNではなく内部ネットワークを使用しようとしていたことを示すnetstat -an | grep SYNですばやく確認されます。

tcp        0      1 172.29.5.10:58000       219.94.163.75:80        SYN_SENT

SNATとDNATをMASQUERADEと比較して、まったく同じ結果を得てみました。この時点で、curlが応答を受信しない理由がわかりません。ありがとう。

linuxnetworkingiptablesroutingnat
6
Nick

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
2
Zoredache

解決策は、前述のようにrp_filterを無効にすることです。ただし、rp_filterを無駄に無効にしないでください。これを試してみたところ、「ユーザーごと」のインターフェイスでのみオフにする必要があることがわかりました。私の場合はppp0でした。

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

もちろん、/etc/sysctl.confに配置することで、より正確に行うことができます。

2
Zouppen