私のLinuxシステムにはいくつかのネットワークインターフェースがあります。一部は物理（eth0など）、一部は仮想（tun0たとえばOpenVPNで作成）です。
特定のインターフェイスを介して特定のホスト（IPアドレス）にアクセスできることを確認することは可能ですか？
ping-Iインターフェイスを選択するオプションをサポートします。しかし、ping -I tun0 1.1.1.1うまくいきません。パケットを受信できません。tun0ルーティングテーブルでそのインターフェイスをゲートウェイに設定すると1.1.1.1に達する可能性があるため、これは驚くべきことです。
tun0たとえば、そのパスのホストゲートウェイを変更せずに1.1.1.1に接続できることをどのように確認できますか？
詳しくは：私はこのシステムを使用して、ネットワーク全体のさまざまなインターフェイスを介してインターネットにトラフィックを転送しています。時々インターネットアクセスの提供が中断されることがあります。これをよりよく設定する方法に関する良いガイド/チュートリアルがある場合は、喜んで読んでみましょう。
私のシステム状態を表示するいくつかのコマンドの出力は次のとおりです（個人情報保護のために多少トリミングされ編集されています）。
# ping -c1 -W1 1.1.1.1 -Ieth0 | tail -n2
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.997/8.997/8.997/0.000 ms
# ping -c1 -W1 1.1.1.1 -Itun0 | tail -n2
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# ping -c1 -W1 1.1.1.1 -Itun1 | tail -n2
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 01:23:45:67:89:ab <BROADCAST,MULTICAST,UP,LOWER_UP>
tun1 UNKNOWN <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
tun0 UNKNOWN <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
# ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
12: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
inet 172.16.1.8 peer 172.16.1.9/32 scope global tun1
valid_lft forever preferred_lft forever
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
inet 172.16.0.6 peer 172.16.0.5/32 scope global tun0
valid_lft forever preferred_lft forever
# ip route
10.0.0.0/22 via 172.16.0.5 dev tun0
2.3.4.5 via 192.168.1.2 dev eth0
172.16.0.0/24 via 172.16.0.5 dev tun0
172.16.0.5 dev tun0 proto kernel scope link src 172.16.0.6
172.16.1.0/24 via 172.16.1.9 dev tun1
172.16.1.9 dev tun1 proto kernel scope link src 172.16.1.8
192.168.0.0/16 via 172.16.1.9 dev tun1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
1.2.3.4 via 192.168.1.2 dev eth0
# ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
40000: from 192.168.0.0/28 lookup physical
500000: from all iif lo lookup physical
600000: from 192.168.0.4 lookup physical
900000: from all lookup fallback
# ip -details link show dev tun0
13: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
link/none promiscuity 0
tun numtxqueues 1 numrxqueues 1
# ip -details link show dev tun1
12: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
link/none promiscuity 0
tun numtxqueues 1 numrxqueues 1
# iptables-save -c
# Generated by iptables-save v1.6.2 on Tue Sep 5 10:15:50 2023
*filter
:INPUT ACCEPT [59898142:66144679517]
:FORWARD ACCEPT [82206554:78274304851]
:OUTPUT ACCEPT [26945751:6646653799]
COMMIT
# Completed on Tue Sep 5 10:15:50 2023
# Generated by iptables-save v1.6.2 on Tue Sep 5 10:15:50 2023
*nat
:PREROUTING ACCEPT [2568037:216846789]
:INPUT ACCEPT [2278788:177840950]
:OUTPUT ACCEPT [853479:59465416]
:POSTROUTING ACCEPT [0:0]
[1133282:97570449] -A POSTROUTING -j MASQUERADE
COMMIT
# Completed on Tue Sep 5 10:15:50 2023
# sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -j MASQUERADE
# ip route show table default
# ip route show table physical
default via 192.168.1.2 dev eth0 proto static
# ip route show table fallback
default via 172.16.0.5 dev tun0 metric 5
default via 172.16.1.9 dev tun1 metric 10
答え1
設定
OPのポリシールーティング設定が異常です。
ルールの上にルールはありません基本テーブル
これに比べて、メインテーブルにはデフォルトパスはありません。
追加ルールを評価し、後ろに基本テーブル
ホストの実際の重要なルーティングルールは次のとおりです。
500000: from all iif lo lookup physicalこれはホスト（トラフィック転送ではなくローカルノード）の最初のルールであるため、INADDR_ANY（0.0.0.0/0パスに一致するアドレス0.0.0.0）と一致するため、すべての（TCP、UDP、ICMP ...）クライアントクエリがアドレス私はインターフェイスにバインドされていません。イーサネット0。
同じブロードキャストドメインを共有する2つのネットワークを使用して行われた単一のアームルーティングについては意見はありません。イーサネット0、問題とは関係ありません。
この設定の主な目的は、ホスト自体のトラフィックと（あまりにも）対話する必要なく、ホストのトラフィックが前後にルーティングされてインターネットに到達できるようにすることですtun1。tun0私は同じことをするより簡単でより標準的な方法があるべきだと思いますが、それは設定です。
ルーティング問題の検出
カーネルルーティングスタックの各選択は、次のコマンドで確認できます。ip route get:
ip route get単一パスのインポート
このコマンドはターゲットへの単一パスを使用し、カーネルが表示するものと正確にその内容を印刷します。
インターフェイスにバインドするとき（使用SO_BINDTODEVICE）、追加のセレクタを使用して強制ルーティング効果を照会できます。oif。
パケット転送：
# ip route get oif tun0 to 1.1.1.1
1.1.1.1 via 172.16.0.5 dev tun0 table fallback src 172.16.0.6 uid 0
cache
ルートがあるので、TCPダンプ発信パケットを表示する必要があります。Tun0相互作用。
復帰経路、一目で、また働くべきです:
# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
local 172.16.0.6 from 1.1.1.1 dev lo table local
cache <local> iif tun0
そしてTCPダンプ戻りパケットもキャプチャされます。
しかし、もしrp_filter=1すでに利用可能厳格なリバースパスの転送(SRPF)は次のように変更されます.
# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
RTNETLINK answers: Invalid cross-device link
応答パケット（まだキャプチャされましたが）TCPダンプルーティングスタックによって削除されます。平らな失敗する。
したがって、一般的なルーティング設定では、リターンパスが使用されているルートrp_filter=1と一致すると予想されるため、これらのルーティングは非対称ルーティングと見なされることがあります。500000: from all iif lo lookup physicalイーサネット0。このパケットが示すようにTun0代わりにイーサネット0、SRPF検証に失敗しました。実は平らなルーティング スタックが SRPF 認証を使用している場合、プロセスが実際にインターフェイスにバインドされているかどうかは重要ではありません。往復交通。
修正する
oif tun0SRPF機能を維持するには、172.16.0.6で最後に選択した送信元アドレスと一致するルーティングルールを追加する必要があります。デフォルト設定は500000未満の値にすることができます（以降イーサネット0SRPFアルゴリズムの実装を満たすために選択されます。
ip rule add from 172.16.0.6 lookup fallback
今、私たちは（まだrp_filter=1）次のようになります。
# ip route get from 1.1.1.1 iif tun0 to 172.16.0.6
local 172.16.0.6 from 1.1.1.1 dev lo table local
cache <local> iif tun0
意味：コマンドを介してローカル使用のためのパケットを受け入れて受信しますping。
また、インターフェイスにバインドせずにアドレスでのみ作業できます。
ping -I 172.16.0.6 1.1.1.1
実際に以前にもありました。
# ip route get from 172.16.0.6 to 1.1.1.1
1.1.1.1 from 172.16.0.6 via 192.168.1.2 dev eth0 table physical uid 0
cache
トンネルは使用されません。
しかし：
# ip route get from 172.16.0.6 to 1.1.1.1
1.1.1.1 from 172.16.0.6 via 172.16.0.5 dev tun0 table fallback uid 0
cache
あるいは、ルーティングルールが変更されないように、上記のルールの代わりに使用するトンネルインターフェイスを設定することもできます。緩いRPFどの優先事項SRPF経由：
sysctl -w net.ipv4.conf.tun0.rp_filter=2
これにより、（仮定された）非対称ルーティングにもかかわらず、RPF検査に合格することができます。これにより、ping -I tun0 1.1.1.1他のルーティングを変更せずにpingが機能することができました（ただし、使用されなくなりました）ping -I 172.16.0.6 1.1.1.1。イーサネット0前と同じようにもう一度選択します（上記を参照）。
また利用できます火1。誰でも：
ip rule add from 172.16.1.8 lookup fallback
または：
sysctl -w net.ipv4.conf.tun1.rp_filter=2