次のルーティングテーブルがあるとします。
ffgrt@srv28:~$ ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 14.2.13.24/32 scope global lo
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 210.41.21.8/27 brd 210.41.21.31 scope global ens3
valid_lft forever preferred_lft forever
ffgrt@srv28:~$
ffgrt@srv28:~$ ip r
default via 210.41.21.30 dev ens3 onlink
210.41.21.0/27 dev ens3 proto kernel scope link src 210.41.21.8
ffgrt@srv28:~$
14.2.13.24サーバーで接続を確立するときは、いつループバックインターフェイスで設定されたアドレスをソースアドレスとして使用しますか？少なくともによるとこのソースアドレス選択ガイド、14.2.13.24このアドレスは、次の理由で手動でバインドする場合にのみ選択する必要があります。
210.41.21.0/27ネットワークに接続すると、カーネルはsrc選択されたルーティングパスのヒントを使用します。210.41.21.8私の場合- これ以外のネットワークに接続すると、
210.41.21.0/27カーネルは宛先アドレスまたはネクストホップルーターと同じネットワーク上のインターフェイスに設定された最初のアドレスを選択します。ネクスト ホップ ルータは via 経由で到達でき、設定のみがあるためens3使用ens3されます。210.41.21.8210.41.21.8
インターフェイスに設定されたIPv4アドレスは、手動でバインドするときにのみ発信接続の送信元アドレスとして使用されますかlo？
答え1
なぜ働くか。
Linux、弱い使用ホストモデル、すべてのインターフェイスに割り当てられているすべてのIPアドレスをホスト全体で使用できるため、他のインターフェイスでも表示できます。
したがって、他のルーティング条件がIPアドレスに到達することを許可している場合は、ループバックインターフェイスにIPアドレスを割り当てることが機能する可能性があります。パスが定義されています）。 IPアドレスにアクセスできるようにしてください。ホストに追加できます）。
あなたの場合、次のことが起こります（デフォルトのインターフェースは次のようになります）。イーサネット0ゲートウェイはMyGW):
1学期：
# ip address add 14.2.13.24/32 dev lo
term2（前のコマンドの前に実行）：
$ ip -4 monitor
1: lo inet 14.2.13.24/32 scope global lo
valid_lft forever preferred_lft forever
local 14.2.13.24 dev lo table local proto kernel scope host src 14.2.13.24
^C
$ ip route get from 14.2.13.24 8.8.8.8
8.8.8.8 from 14.2.13.24 via mygw dev eth0 uid 1000
$ ip route get from 8.8.8.8 iif eth0 14.2.13.24
local 14.2.13.24 from 8.8.8.8 dev lo
cache <local> iif eth0
ルーティングは、次の場合に双方向で動作することもできます。MyGWこのトラフィックはルーティングすることもできます。
この IP アドレスを次に割り当てます。ルオホストに別のIPアドレスを追加するだけです。利点は、デフォルトのインターフェイスを閉じて開くと消えず、そのアドレスを割り当てることができるインターフェイスを推測する必要がないため、一部のスクリプトが単純化されることです。ルオ常に利用可能で、一般的に利用可能です。
バインドなしでこのアドレスを使用する方法
OPがすでに作成したように、選択したパスは宛先に到達するために使用されるインターフェイスのデフォルトのIPアドレスを使用するため、このアドレスはデフォルトでは使用されません。ルオこのインタフェースは絶対ではありません（暗黙のソースである14.2.13.24自体は除く）。
そのアドレスを完全または一部の宛先のソースとして選択するようにルーティングを調整できます。
ターゲットの例：
# ip route add 8.8.8.8 via mygw dev eth0 src 14.2.13.24
8.8.8.8に送信されたパケットは、他のIPアドレスにバインドされていない限り、デフォルトでは14.2.13.24に設定されます。既存のパスを置き換えるか上書きし、このアドレスを重要な場所ごとにデフォルトのソースとして使用できます。
アプリケーションが複数のアドレスを処理する方法
どのルートもこのアドレスを送信元として選択しない場合は、クライアントとして明示的にこのアドレスにバインドしてこのアドレスからトラフィックを送信する必要があります。バインディング(2)例えば、使用前に接続(2)。
サーバー（リスニングサービス）として、次の点によって異なります。
TCPサービスは、追加の操作なしで通常どおり実行されます。つまり、接続は受信したIPアドレスから応答します。
UDPサービスには追加の注意が必要です。これは住所に限定されない。ルオただし、これは割り当てられたインターフェイス以外のインターフェイスから接続できるいくつかのIPアドレスを持つすべてのマルチホームシステムに適用されます。
そのアドレスにバインドし、そのアドレスのパケットのみを受信でき、応答はバインドされたアドレスを送信元として使用します。明示的なバインディングがない場合、デフォルトインターフェイスのアドレスが選択され（例：14.2.13.24ではなく210.41.21.8）、元のクライアントはそのアドレスがクエリと一致しないため応答を拒否します。
それでもバインディングを選択している場合INADDR_ANY、受信したデータパケットのアドレスを事前に知ることはできません（たとえば、210.41.21.8または14.2.13.24？）、カーネルはデフォルトでデフォルトインターフェイスのIPアドレスを応答として選択します。その後、アプリケーションは異なる動作をする必要があります。 Linuxでは、次のように設定する必要があります。IP_PKTINFOUDPソケットのオプション（使用setockopt(2)) 次に使用メッセージを受信する（2）補助情報を受け取るin_pktinfo受け取った地元の住所を教えてください。その後、アプリケーションは以下を使用してこの情報の一部を再利用できます。メッセージを送信(2)（ソケットをバインドせずに）送信するソースアドレスをカーネルに通知します。複雑です。たとえば、次のようになります。UDPソケットのソースIP設定。 （* BSDではIP_RECVDSTADDR同じ方法で使用されます）。
答え2
への接続はありませんlo。これはソースアドレスにはできません。他のデバイスは接続されていません。
私が考えることができる唯一のユースケースは、ネットワーク/他のサーバーがあり、14.2.13.24同じサーバーソフトウェアが現在デバイス上で実行されている場合です。オンラインサーバーで実験せずに構成をテストしようとしています。サーバーのアドレスをloローカルサーバーに割り当て、要求を介さずにそのサーバーに送信しますens3（そしてそれにルーティングを設定する必要があります）。その後、テスト用にDNSエントリ（または/etc/hosts）を変更せずにローカルに接続できます。
ローカルでテストを完了したら、設定を実際の設定に転送して14.2.13.24アドレスを削除するとlo（希望的に）機能します。