☰

特定のインターフェイス（tum1）を介したユーザートラフィックのルーティング

tag-icon • tag-icon ubuntu iptables routing
特定のインターフェイス（tum1）を介したユーザートラフィックのルーティング

Q：特定のユーザーに対してtun1を介してトラフィックをルーティングする方法は？

これまでに試したこと：私は以下に従いました：

1:iptables はすべてのトラフィックをインターフェイスに転送します。

sudo iptables -t nat -A POSTROUTING -m owner --uid-owner user1 -j SNAT --to-source 192.168.1.1

結果：トラフィックはtun1に到達せずにWiresharkに表示され、「host google.com」は結果を提供しません。

2:

sudo iptables -t nat -A POSTROUTING -m owner --uid-owner test --out-interface tun1

結果：トラフィックはデフォルトルートを通過します。つまり、 tun1(vpn) を経ずにインターネットに到達します。

追加情報：

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: enx0c5b8f279a64: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.100/24 brd 192.168.8.255 scope global dynamic noprefixroute enx0c5b8f279a64
       valid_lft 53043sec preferred_lft 53043sec
    inet6 fe80::5f5a:e5de:ae93:e80b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
9: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
    link/none 
    inet 10.0.0.1/24 scope global tun1
       valid_lft forever preferred_lft forever
    inet6 fe80::c626:a226:a66c:2b0/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

ip route list
default via 192.168.8.1 dev enx0c5b8f279a64 proto dhcp metric 100 
10.0.0.0/24 dev tun1 proto kernel scope link src 10.0.0.1 
169.254.0.0/16 dev enx0c5b8f279a64 scope link metric 1000 
192.168.8.0/24 dev enx0c5b8f279a64 proto kernel scope link src 192.168.8.100 metric 100 
linkdown

ベストアンサー1

私はdirkのコメントに完全に同意します。ネットワークネームスペースを使用すると、ルーティングがより簡単になり、特別なケースはありません。しかし、これにはLinuxカーネル> = 4.10が必要な通常とは異なる答えがあることを願っています。

失敗した試みについて：POSTROUTING名前が示すように完了しました後ろにルーティングの決定が完了しました。チェーンは決して方向を変えません。何のために使うべきですか？地域的に始まったトラフィックはmangle/OUTPUT（nftablesの特殊チェーンtype route hook output）です。その後、マーカーを使用してルーティングスタックと対話し、エッジケースを変更する必要があります。CONNMARKそしてMARKそれを動作させることはまだ難しいです。

とにかく方法があります。いいえ2016年に登場したiptablesネットワークルーティングスタック機能を活用uidrangeカーネル 4.10:

UID固有のルーティングのサポートを追加します。これにより、管理者は次の規則を設定できます
# ip rule add uidrange 100-200 lookup 123。すべてのAndroidデバイスは5.0からこの機能を使用しています。主にアプリ固有のルーティングポリシーを実装するために使用されます（Androidでは、アプリごとに一意のUIDがあります）。iptablesでパケットを再ルーティングする必要はありません。、これはgetsockname（）とMTU / MSSの計算を中断し、通常はエンドツーエンドの接続を中断します。犯罪、 犯罪、犯罪

ルーティングスタックはすぐに正しいルートに一致する送信元IPを選択するため、SNATこのIPは必要ありません。それでも小さな「汚れた」部分があります。リバースパスフィルタが緩んでいる~へトゥエンこれは、ターゲットユーザーが他のユーザーとは異なるルーティングテーブルを取得しても、そのインターフェイスの戻りトラフィックはどのユーザーにも属さないため、そのルーティングテーブルを使用しないためです。

この例ではユーザー1UIDは1234になり、ランダムに選択されたテーブル1001234が代替パスとして使用されます。

そのベースパスをテーブル1001234にコピー/変更し、パスを軽減します。これらのパスと設定は、インターフェイスが消えたり終了したりすると失われるため、トンネルがリセットされるたびに再追加する必要があります。

ip route add table 1001234 10.0.0.0/24 dev tun1 src 10.0.0.1
ip route add table 1001234 default dev tun1 #no need of a gateway on a layer 3 interface
sysctl -w net.ipv4.conf.tun1.rp_filter=2

これは一度だけ行われ、ユーザーにすぐに影響を与えます。

ip rule add uidrange 1234-1234 lookup 1001234

NATルールを追加しないでくださいiptables。もちろん、適切なファイアウォールルールはまだ必要です。ユーザーがローカルサービス（127.0.0.1:53で利用可能なローカルDNSキャッシュデーモン）を照会する場合、デーモンのUIDが異なるため、デーモンによって実行された照会はトンネルを使用しません。

おすすめ記事