今、デバッグのために何をすべきかわかりません。私は数週間この問題を解決しようとしてきましたが、何が起こっているのか理解できません。
SSHサーバーが管理サブネットからの接続のみを処理しようとしているため、すべてのサブネットから管理サブネットへのトラフィックルーティングをブロックしてはいけません。
これが設定です。 Debian 9 に仮想マシンがあります。仮想マシンには2つのインターフェイスがあります。 eth0 はユーザーのサブネットにあり、eth1 は管理サブネットにあります。どちらのサブネットにもpfsenseというDHCP / DNSサーバーがあります。ホスト名が自動的にDNSに追加されます。
私のsshd設定ファイルはデフォルトでオンになっており、rootログインは無効になっており、ListenAddresseth1 IPに設定されています。
これはこれまで私が見た動作です。
両方のインターフェイスがイネーブルでイネーブルになりListenAddressました。
- pfsenseルーターを介したユーザーネットワークのSSH：接続が確立され、短時間動作してから端末が停止してタイムアウトします。 Wiresharkでは現在、いくつかのTCP再送信があります。
- 管理ネットワークで直接SSHを使用すると、すべてがうまく機能します。
- 2つのネットワークを持つシステムでsshを使用すると、すべてがうまく機能します。
- 3番目のネットワークのssh（ユーザーネットワークへのアクセスを拒否するルール）：すべてがうまく機能します。
両方のインターフェイスが動作中でListenAddress無効になっています。
- すべてがうまく機能しますが、もちろん、ユーザーネットワークインターフェースを介してSSHを使用することもできます。
インターフェイス eth0 がダウンしてListenAddressアクティブになりました。
- すべてが正常です
サーバーには意図的にファイアウォールはありません。ホスト名の代わりに IP アドレスを使用して ssh を使用しますが、両方のインターフェイスでホスト名が同じでも異なっていても同じ結果が得られます。
問題がどこから来るのか本当に分からない。私にとってはpfsenseになることはできません。これは、ユーザーネットワークから管理ネットワークへのすべてのネットワークトラフィックを許可するためです。しかし、おそらく私が間違っている可能性があります。 sshdログにもエラーはありません。
答え1
問題は、サーバーから送信されたTCPパケットが送信したTCPパケットとは異なるパスを使用し、pfsenseが接続がまだ確立されていないと考え、確立された接続テーブルからそのパケットを削除してから着信接続を拒否することです。データパケット。
ユーザーネットワーク上のコンピュータからサーバーに送信されたTCPパケットは、pfsenseルーターに送信され、SSHサーバーに転送されます。 SSH サーバーにはユーザー ネットワークのインターフェイスがあるため、リターン パケットはユーザー ネットワークのインターフェイスを介してコンピュータに直接送信されます。したがって、pfsenseはあなたのコンピュータからサーバーへのパケットのみを報告し、最初のTCP SYNフレームがまだ承認されていないため、しばらくすると接続が切断されたと判断し、その後のパケットを破棄します。
pfsenseの迅速な解決策は、ユーザーネットワークから管理ネットワークにSSHパケットをSNATすることです。したがって、ssh サーバーは pfsense を戻りパスとして使用します。もちろん、SSHサーバーは実際のソースアドレスを知りません。
より良いアプローチは、ソースベースのルーティングを使用することです。バラよりこの問題例えば。