私はこの説明をできるだけ簡単にしようとします。
2 つのホストがあります。これらをアリスとボブと呼びます。
- Aliceでは10.242.0.1/32がloに割り当てられ、Bobでは10.242.0.2/32がloに割り当てられます。
- AliceとBobの間には、10.242.0.101/32から10.242.0.102/32までのポイントツーポイントを提供するGreトンネルがあり、両側
a_b_gre
でこのインターフェイスを呼び出します。 - また、Alice は IP アドレス 10.242.1.1/24 をブリッジに割り当てます。
Bobを例にすると、彼は10.242.0.1/32と10.242.1.0/24の両方が10.242.0.101/32でアクセスできることを知っています。ファイアウォールルールがなく、ポリシーが「承認」に設定されています。
私の問題は次のとおりです。 Alice が 10.242.1.1 の src IP を使用して 10.242.0.2 に ping を送信すると、パケットは受信されますが、ルーティングまたは応答しません。今、デバッグ中に試した多くのタスクのいくつかは次のとおりです。
- 10.242.0.101から10.242.0.102までのPing:うまく動作します。
- 10.242.0.1から10.242.0.2までのping:うまく機能
- 10.242.1.1から10.242.0.102へのping:機能しない
tshark -pi any icmp
:到着するパケットを確認し、応答パケットがない場合tshark -i lo icmp
: パケットが見えないSysctl確認:
net.ipv4.conf.all.forwarding = 1 net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_local = 1 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.all.route_localnet = 1 net.ipv4.conf.all.log_martians = 1
iptables TRACEルール:
TRACE: filter:INPUT:policy:1 IN=a_b_gre OUT= MAC= SRC=10.242.1.1 DST=10.242.0.2 ...
入力チェーンをうまく通過したことを示します。- conntrack -L:
icmp 1 29 src=10.242.1.1 dst=10.242.0.2 type=8 code=0 id=29499 [UNREPLIED] src=10.242.0.2 dst=10.242.1.1 type=0 code=0 id=29499 mark=0 use=1
...だから確かに到達します... conntrackエントリを消去することは役に立ちません。 ルート検索の確認:調査結果...
Bob # ip route get 10.242.0.2 from 10.242.0.1 iif a_b_gre local 10.242.0.2 from 10.242.0.1 dev lo table local cache <local> iif a_b_gre Bob # ip route get 10.242.1.1 from 10.242.0.2 iif lo 10.242.1.1 from 10.242.0.2 via 10.242.0.101 dev a_b_gre cache iif lo
今アイデアはありません。 Bobはパケットを明確に受信し、それについて何をすべきかを知っているようです。しかし、何かがパケットに応答したりループバックにルーティングしたりするのではなく、パケットをドロップするようにするようです。ping -I 10.242.0.1 10.242.0.2 10.242.0.3
.3 が最初の 2 つに似た 3 番目のホスト設定に属する行に沿って ping を試み、再度ip route get
正解を提供しようとしたときに同じ動作が現れることを考えると、配信フェーズについては間違いなく疑わしいです.
ああ、私は特にアドレスをNATに接続したくないことを覚えておく必要があります。これは即時の問題を解決しますが、パケットを正しくルーティングする目的も無効にします。
それでは、どこから始めるべきかについてのアイデアはありますか?