☰

pfsense: 2 つの内部 LAN 間の接続が 20 秒後に切断されました

tag-icon • tag-icon nat pfsense
pfsense: 2 つの内部 LAN 間の接続が 20 秒後に切断されました

次のような構成です:

LAN 01: 192.168.16.0/24 (LAN for internal servers)
LAN 02: 192.168.67.0/24 (LAN for workstations)
WAN: X.X.X.X

その後：

PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)

ラン01そしてラン02物理的に接続されています (つまり、同じスイッチ内です。別々の LAN を使用するか、少なくとも VLAN を使用する必要があることはわかっていますが、現時点ではこの構成を簡単に変更することはできません)。

私はPFSENSEインストール（2.2）を動作させています。ラン02DHCP サーバーから IP アドレスを取得し、PFSENSE をデフォルト ゲートウェイとして使用します。

私の問題は次のとおりです:

もし私がコンピューターの前に座るとラン02そして、私はSSH（または他の永続的なプロトコル）で、ラン01このような：

$ ssh -l myself 192.168.16.25

問題なく接続できます。接続は 20 秒から 30 秒ほど続きますが、その後は頻繁に切断されます。

私の質問は次のとおりです。接続が切断されないようにするにはどうすればいいでしょうか?

両側から tcpdump を実行したところ、ある時点でパケットが重複し始めました。次のようになります。

Wiresharkで表示されるtcpdumpキャプチャ

このオプションを有効にしましたが、役立つと思いましたが、役に立ちませんでした。

pfsense でオプションを有効にする

LINUX ファイアウォール (iptables) を使用したこれとまったく同じ構成は完璧に機能することを言及しておく必要があります。

何か案は？

答え1

キャプチャを見ると、どうやら 1 つは 192.168.16.0、もう 1 つは 192.168.67.0 であるようですが、両方とも /24 であることを願うばかりです。したがって、LAN1 と LAN2 の両方を 192.168.1.0/24 としてリストしているのは間違っていると思います。

静的ルート フィルタリング オプションはここでは適用されません。

重複したネットワークがある (両方で /24 マスクではなく、一部のホストで /16 である可能性があります) か、影響を受けるシステムの 1 つが両方のネットワークでデュアルホーム化されており、非対称ルーティングが発生していると考えられます。

答え2

私も非常によく似た問題を抱えていましたが、その問題は本質的には非対称ルーティングのバリエーションでした。

私のトポロジでは、2 つの LAN インターフェイス (どちらも /24 ですが、サブネットは明らかに異なります) を備えた PFSENSE ボックスがあります。次に、両方のインターフェイスを異なる VLAN 内のネットワークの残りの部分に接続する L2\L3 スイッチがあります。また、このスイッチには有線ユーザーと、すべてのワイヤレス ユーザーを含むセグメントがあります。有線ユーザーは 1 つのサブネット\VLAN にあり、ワイヤレス ユーザーは別のサブネット\VLAN にあります。これらのサブネットは両方とも、PFSENSE ボックス上に存在します。すべてのエンドポイントは、それぞれのサブネットの PFSENSE IP を DG として使用します。最後に、スイッチには前述の両方のサブネットの IP もあります。

私の問題は、ワイヤレスで接続してスイッチに SSH で接続すると、正常に接続されてから 20 ～ 30 秒で切断されるということでした。おそらくすでにお気づきかと思いますが、スイッチの IP は私のマシンと同じサブネットにあるため、スイッチからの戻りパケットは私のマシンからのパケットと同じパスをたどるのではなく、私のマシンに直接送信されます。スイッチは基本的に PFSENSE ボックスを迂回するだけです。

多くの場合、これは実際には、特に非ステートフルな仲介者や UDP セッションでは問題なく機能します。ただし、PFSENSE ボックスはステートフル デバイスであるため、数秒後に PFSENSE は TCP OPEN への応答がなくなり、状態が強制終了されます。確認するには、PFSENSE の TCP OPEN タイムアウト値 (システム --> 詳細 --> 状態タイムアウト) を微調整し、SSH セッションがドロップするまでの時間が設定値に従うことを確認します。この値のデフォルトは、予想どおり 30 秒です。スイッチから関連する IP を削除すると、問題は解決しました。

OP が説明したトポロジでは特に言及されていませんが、関連するエンドポイント間にスイッチ (または類似のもの) があるのではないかと思います。そうではないかもしれませんが、もしそうなら、ここで私が抱えていたのと同じ問題である可能性があります。あるいは、OP のトポロジ内のサーバーがデュアルホーム化されている場合、この問題が発生します。

関連情報