☰

127.xxx シリーズの接続問題

tag-icon • tag-icon networking linux-networking linux-kernel ip-routing loopback
127.xxx シリーズの接続問題

Stack Exchange のネットワーク エンジニアリングでこの質問をしたところ、ここにリダイレクトされました。

私は以下の構成のサーバーをいくつか持っています

サーバー1:

eno1: 127.15.0.1/16 scope global
eno2: 5.0.0.1/24

サーバー2:

lo: 127.0.0.1/16 (it had /8. I changed the subnet mask using 'ip addr del 127.0.0.1/8 dev lo; ip addr add 127.0.0.1/16 dev lo')
eno2: 5.0.0.2/24

server1 の eno1 は完全に異なる L2 ネットワークに接続されており、完全に分離されています。

両方のサーバーの eno2 インターフェイスは同じ L2 ネットワークに接続されています。ここで、server2 から 127.15.0.1 にアクセスする必要があります。

Server1 はかなり前にデプロイされたため、いかなる種類の構成も変更する権限がありません。スコープがグローバルの 127.xxx サブネットが使用された理由がわかりません。有効な構成かどうかはわかりませんが、そのまま受け入れるしかありません。server2 を完全に制御でき、何でも変更できます。

どちらのサーバーも Linux ベースです。

5.0.0.1 <-> 5.0.0.2 間の接続は良好です。

私の最初の試みは、以下のようにserver2にルートを追加することでした

ip r add 127.15.0.1/32 via 5.0.0.1 が server2 から 127.15.0.1 に ping しました。server2 の tcpdump で ping 要求と応答が表示されていますが、ping コマンドでは 100% の損失が表示されています。

rp_filtersを無効にしました

sysctl.cnf:

net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.lo.rp_filter=0
net.ipv4.conf.eno2.rp_filter=0

sysctl.conf を更新した後に再起動しました

そして、iptables をフラッシュしました。 (iptables -F)

結果は同じです。サーバー2は127.xxxシリーズの使用を好まないのではないかと思いました。そこでサーバー2に以下のルールを追加しました。

iptables -t nat -A OUTPUT  -d 5.0.0.1 -j DNAT --to-destination 127.15.0.1

このルールは、パケットの宛先が 5.0.0.1 の場合、宛先 IP を 127.15.0.1 に置き換えることになっています。

server2 から 5.0.0.1 に ping しました。iptables は宛先 IP を 127.15.0.1 に置き換えました (server1 の tcpdump で確認済み)。server1 は応答しましたが、応答は再びドロップされました。

この時点では、アイデアが尽きました。メンテナンスのために server1 を停止し、127.15.0.1/26 を 192.168.1.1/16 に置き換えました。この場合、接続は正常に機能しました (iptables の有無にかかわらず)。ここでの疑問は、問題は 127.xxx を使用していることによるものかということです。そうであれば、解決策はありますか? ない場合、他に試せることはありますか?

注: この構成は以前は機能していました。最近、server2 (古い Linux を搭載) が失われ、ゼロから構築しています。また、Windows では、ループバック以外のインターフェイスに 127.xxx を使用することはできません。Linux が lo 以外のインターフェイスでそれを許可する理由はわかりません。何か理由があるのか​​もしれません。

要約すると、次のような質問があります。

  1. 127.xxx を設定しようとすると、Windows は設定を完全に拒否しますが、Linux はそれを許可し、しかもグローバル スコープで許可します。これを使用するケースはありますか?
  2. この場合、server2は127.xxx宛てにリクエストを送信し、server1は実際に応答を送信しています。127.xxxがホスト内部なぜリンク上でパケットを送信するのでしょうか?

答え1

Linuxのsysctlフラグは

/sys/net/ipv4/conf/*/route_localnet

このようなパケットに対する適切な処理を無効にすることを許可します。

route_localnet - ブール値

ルーティング中にループバック アドレスを Martian の送信元または宛先として考慮しません。これにより、ローカル ルーティングの目的で 127/8 を使用できるようになります。デフォルトは FALSE です。

正気な人ならそんなことをする人はまずいないでしょうから、これは今ではうまくいくかもしれませんし、うまくいかないかもしれません (私が最後にテストしたのは数年前です)。

任意の割り当てを行ってくださいこの目的のために予約済み（リンクローカルである可能性はあるが、ホスト内部ではない）または所有問題のインターフェースへの IP 空間。この奇妙な設定を続けると、特に簡単な代替手段が存在する場合には、さらに問題が発生するだけです。

関連情報