Tinyproxy：さまざまなネットワークカード（eth0、eth1）を監視してバインドします。ルーティングの問題

Question

初期コメント：

設定の次の部分でネットワーク接続が失われました。これは、リモートロケーションではなくLANからプロキシサーバーに接続するか、直接コンソールアクセスを介して行う必要があります。
ネットワーク構成ツールとの適切な統合は依然として必要であり、ここでは提供されていません。

現在の設定とアドレス（特に発信ソケット）の使用方法を悪用する可能性があります。ポリシーベースのルーティング目標を達成する。

192.168.2.200で送信されたすべての項目は「左インターネット」を使用します。
192.168.3.200で送信されたすべての項目は「適切なインターネット」を使用します。
バインドされていないソケットから発行されたすべてのエントリ（INADDR_ANYのバインディングとも呼ばれます）は、ベーステーブルの一般的なベースパスにルーティング決定を残します。合理的なオプションは、「正しいインターネット」を使用することです。これは、プロキシサーバーのクライアント部分でもあり、サーバー自体で使用するのが合理的であるためです（パッケージの更新など）。以下のルールとパスは対称であるため、別の選択（3番目のインターフェイスの3番目のゲートウェイを含む）を選択すると、プロキシは期待どおりに機能します。

デフォルトパスを削除して最初から始める

接続損失を防ぐには、コンソールまたはLANアクセスが必要です。もちろん、以下のコマンドは実際にパスを更新するのではなく、ネットワーク構成ツールを使用して実際に統合する必要があります。
```
ip route flush default
```
基本テーブルに「デフォルト」のデフォルトパスを追加します。
```
ip route add default via 192.168.3.254 dev eth1
```
両当事者に対して対称的に代替基本パスを準備します。

任意のルーティングテーブル10000（左）と10001（右）を使用します。 LAN パスでこれらのテーブルを補充する必要はありません。基本ルーティングテーブルは、デフォルトパス抑制子のルールを使用して保持されます（次の箇条書きを参照）。
```
ip route add default via 192.168.2.254 dev eth0 table 10000
ip route add default via 192.168.3.254 dev eth1 table 10001
```
これらのルーティングテーブルを選択するポリシールールを追加します。

ルールから始めて、デフォルトのルーティングテーブルであるLANルートで、デフォルト以外のすべてのルートを見つけます。このルールではデフォルトパスの結果が表示されないため、次の2つのルールで正しいsuppress_prefixlength 0パステーブルと正しいデフォルトパスを選択できます。
```
ip rule add pref 1999 lookup main suppress_prefixlength 0

ip rule add pref 2000 from 192.168.2.200 lookup 10000
ip rule add pref 2001 from 192.168.3.200 lookup 10001
```

それがすべてです。

をする小規模エージェント192.168.2.200 でトラフィックを受信し、192.168.3.200 でトラフィックを送信すると、双方向のすべてのルートが期待どおりに機能します。

プロキシのサーバー側は eth0 からクライアントを受信して応答します。

# ip route get iif eth0 from 192.0.2.2 to 192.168.2.200
local 192.168.2.200 from 192.0.2.2 dev lo table local 
    cache <local> iif eth0 
# ip route get from 192.168.2.200 to 192.0.2.2
192.0.2.2 from 192.168.2.200 via 192.168.2.254 dev eth0 table 10000 uid 0 
    cache

プロキシのクライアントはeth1のサーバーにメッセージを送信し、サーバーから応答を受け取ります。

# ip route get from 192.168.3.200 to 192.0.2.2
192.0.2.2 from 192.168.3.200 via 192.168.3.254 dev eth1 table 10001 uid 0 
    cache 
# ip route get iif eth1 from 192.0.2.2 to 192.168.3.200
local 192.168.3.200 from 192.0.2.2 dev lo table local 
    cache <local> iif eth1

バインドされていないクエリでは、通常どおり基本テーブルが使用されます。

# ip route get to 192.0.2.2
192.0.2.2 via 192.168.3.254 dev eth1 src 192.168.3.200 uid 0 
    cache

特別な場合

右側のLAN側（192.168.3.0/24）にあるクライアント、または左側のLAN側（192.168.2.0/24）にあるサーバーの場合、エージェント自体ではなくLANシステムに関連する調整が必要になる場合があります。必要に応じて、特定の状況に応じてこの回答を編集できます。

Answer 1