☰

このルーティング設定が機能しないのはなぜですか

tag-icon • tag-icon linux routing linux-networking
このルーティング設定が機能しないのはなぜですか

サーバー マシンに 2 つのインターフェイスがあります。出力はip route次のようになります。

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

そしてip address次のようになります（MAC は非表示です）。

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

値/proc/sys/net/ipv4/ip_forwardは 1 です。ファイアウォールは無効です。

私が望むのはアクセスすること192.168.100.1から10.8.0.100. を介して Web サーバー (このマシンのすべてのポートをリッスンしている) にアクセスするとcurl --interface 10.8.0.100 http://10.8.0.1正常に動作します。ただし、curl --interface 10.8.0.100 http://192.168.100.201出力はNetwork unreachable.

CurlはTCPハンドシェイクを開始し、パケットをプッシュします。10.8.0.100パケットはその後、10.8.0.1サーバーはパケットの宛先を調べ、それが192.168.100.201ルーティングテーブルを調べて、192.168.100.201ローカルです。今、回答が返されます。送信者は10.8.0.100ルーティング テーブルを見ると、ローカルの 経由でアクセスできることがわかりますtap0。これで、 にプッシュされてtap010.8.0.100 に到達します。

でも実は -それはそうではないこれは私の考え方が間違っているからでしょうか? 記載されている表で提供される情報は、パケットの転送方法を決定するのに十分だと思いました。これは実際には不完全でしょうか?

答え1

まず、IP アドレスとインターフェースを -I パラメータで指定することはping同義ではありません。 最初に、どちらsource IPを選択するかを指定します。 ローカル アドレスとルーティング テーブルを含むネット フローに従ってルーティングします。 2 番目に、パケットを送信するインターフェースを直接選択するように指定します (最初に割り当てられた IP がソースとして選択されます)。

次に、あなたが行っていることは、パケット転送とはまったく関係ありません。転送とは、パケットが実際に「外部」から到着する必要があることを意味します。このホストからパケットを生成しているため、転送は行われません。これはローカルで生成されたパケットです。宛先 IP はローカルに割り当てられたアドレスの 1 つであるため、ping にパケットを特定のインターフェイス「外部」に送信するように強制していない場合 (-I interfaceオプションを使用)、カーネルはこのパケット フローを内部で処理します。宛先が「すでにここにある」ため、実際のインターフェイスに出力しようとはしません。これが何が起こるかであり、あるケースでは機能し、別のケースでは機能しない理由です。

-rPS: 両方のインターフェースが同じブロードキャスト ドメインに接続されていることが分かっている場合は、ツールのオプションも確認してくださいping(TAP インターフェースではこれが疑わしいです)。

答え2

問題は、--interface IPとの違いを誤解していたことです--interface dev。最初のものはルーティング テーブルを使用します。

パケットは、インターフェイス（この IP が属する）--interface 10.8.0.100に転送されません。代わりに、ルーティング テーブルに従って、（LAN インターフェイス）に転送されます。したがって、ルートは です。SYN が配信されたという事実にもかかわらず、サーバーは奇妙なことに SYN-ACK で応答しません。これが curl が失敗する理由です。tap0192.168.100.5810.8.0.100 -> 192.168.100.58 -> 192.168.100.201

つまり、リンク層アドレスを使用すると--interface tap0、意図したとおりに動作します。SYN 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201-ACK は同じルートを使用して返送されます。

関連情報