web-dev-qa-db-ja.com

NAT環境でのxinetdを介したポート転送

NAT環境でサーバーのポートの1つから来るリクエストを他のサーバーのポートにリダイレクトする必要があるセットアップに取り組んでいます（例：192.168.1.100：843から来るすべてのリクエストは192.168.1.200:8443にリダイレクトする必要があります-両方のサーバー専用ファイアウォールの背後にあり、すべてのポートを相互に通信します。）

サーバー192.168.1.200のポート8443でサービスが実行されています。次のように、xinetdを介してサーバー192.168.1.100でポート転送を構成しました。

service serv1
{
        bind            = 192.168.1.100
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 8443
}

これで、LAN内で192.168.1.100 843にtelnetを実行しているときに、192.168.1.200：8443でサービスに接続できます。

-> telnet 192.168.1.100 843
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.

しかし、192.168.1.100のパブリックIPを介して接続しようとすると、「接続が閉じられます」というメッセージが表示されます。

-> telnet 1.2.3.4 843
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
Connection closed by foreign Host.

後でtcpdumpを実行すると、サーバー192.168.1.200自体に要求が届かないことがわかりました。

DCのいずれかで同様の設定が機能しており、正常に機能しています。ここで問題が発生する可能性があるかどうかは不明です。

ありがとう、Meghanand

xinetd
1
vasco.debian

さらに調査したところ、TCPWrappersが原因でブロックされていたことがわかりました。適切なルールを追加した後、正常に機能しました。

以下は/etc/hosts.allowに追加されました

serv1: ALL

ありがとう

1
vasco.debian

ホストに割り当てられたすべてのIPでリッスンする場合は、bind行を削除する必要があります。

しかし、それはあなたの問題の完全な説明ではありません。それがあなたが犯した唯一の間違いである場合、他のIPへの接続は接続が拒否され、確立された接続の後に切断が行われることはありません。

他の何かが他のIPアドレスの同じポート番号でリッスンしている可能性があります。それは別のxinetdサービスでさえあるかもしれません。これに似た別のxinetdサービスがある場合、問題を説明できます。

service serv2
{
        bind            = 192.0.2.42
        protocol        = tcp
        flags           = REUSE
        socket_type     = stream
        port            = 843
        wait            = no
        user            = root
        redirect        = 192.168.1.200 61868
}

ここでの違いは、もう一方が別のIP（ただし同じポート番号）でリッスンしていて、閉じている別のポート番号に接続していることです。それがあなたがしたことなら、他のIPアドレスへの接続は確立された接続を取得し、xinetdのターゲットポートが閉じられたことを認識したらredirectを閉じる必要があります。

最後の部分はただ推測です。 netstat -ntlpWを実行すると、他のIPで実際にリッスンしているものを確認できるはずです。

1
kasperd