ループバックインターフェイスの仕組み
奇妙なことがある：
私のvirtualboxで：
centos7
インターフェース：
enp0s3: 192.168.10.110/24
lo:0 10.0.3.110/24 (ip alias)
ルート：
default via 10.0.3.2 dev lo
192.168.10.0/24 dev enp0s3
enp0s3 is plugged in 10.0.3.0/24
Ip_forwardを有効にしました（net.ipv4.ip_forward = 1）
私の質問：
ping 10.0.3.2は機能しますが、なぜですか？
tcpdumpはenp0s3でパケットを取得できませんが、loでパケットを取得します。
デフォルトのルートはloです。 ping 10.0.3.2が機能する理由enp0s3でパケットを取得できないのはなぜですか？
ループバックインターフェイスは仮想インターフェイスです。ループバックインターフェイスの唯一の目的は、送信されたパケットを返すことです。つまり、送信したものはすべて、インターフェイスで受信されます。パケットを送信できる唯一の場所は、インターフェイスの出力から入力にループされている架空のワイヤであるため、ループバックインターフェイスにデフォルトルートを配置してもほとんど意味がありません。ループバックインターフェイスのこの動作を変更できるものは何もありません。それがコード化されています。
10.0.3.2に対してpingを実行すると、一部の外部デバイスからの応答ではなく、ループバックインターフェイス自体からの応答が返されます。たとえば、ループバックインターフェイスにアドレスを追加すると、.
Sudo ip addr add 10.0.3.1/24 dev lo
10.0.3.0/24へのルートが追加されます。あなたはこれを見ることができます
ip route show table local
何かのようなもの
local 10.0.3.0/24 dev lo proto kernel scope Host src 10.0.3.1
表示されるはずです。このルーティングテーブルエントリは、10.0.3.1と10.0.3.254の間のアドレスに送信されたパケットがloインターフェイスを介して送信され、そこからすぐに返されることを示しています。
編集：以下のコメントへの応答としての明確化。
10.0.3.2にpingすると、次のようになります。カーネルは、宛先アドレス10.0.3.2の配信用のIPパケットを取得します。配信されるパケットと同様に、カーネルはルーティングテーブルを調べます。この場合、一致するエントリは次のとおりです：local 10.0.3.0/24 dev lo proto kernel scope Host src 10.0.3.1。これは、パケットがloインターフェースを介してソースアドレス10.0.3.1で配信されることを示します。
これで、パケットがloインターフェイスに渡されたため、ループバックインターフェイスは通常のように動作します。パケットを送信キューから取り出し、受信キューに入れます。カーネルの観点から、ソケットをリッスンしているサーバープロセスが消費する準備ができている着信パケットを受信しました。 （pingの場合、カーネルはそれを内部で処理します。）宛先アドレスが10.0.3.2の「リモート」ICMPパケットを受信しました。これはおそらくローカルアドレスの1つではありませんが、ループバックに配信されました。それにもかかわらず、インターフェース。
次に、カーネルはpingに応答を送信します。ICMP応答パケットのアドレスが逆になっています。10.0.3.2が送信元アドレス、10.0.3.1が宛先です。これは、ループバックインターフェイスを介してpingプログラムに戻され、10.0.3.2から応答があったことを示しています。
「enp0s3でパケットを取得できないのはなぜですか？」という他の質問への回答
192.168.10.0/24のLANを指している
したがって、LANに荷物の配達リクエストに応答するサーバーがない場合は、そのルートを経由してnadaを取得します。