Linuxサーバーには2つのNICがありますeth0
。eth1
サーバーにIPがあります。
192.168.2.200/24 on eth0
192.168.3.200/24 on eth1
両方のネットワークにはデフォルトのサブネットマスク(255.255.255.0
)とデフォルトゲートウェイがあります192.168.x.254
。
次の構成のTinyproxyがサーバー上で実行されています。
Listen 192.168.2.200
Bind 192.168.3.200
アイデアは、プロキシをインターネットに公に公開し、このプロキシからのトラフィックがeth0
インターネット上で必要なリソースに到達するために別のインターフェイスを介して行う必要があることですeth1
。
192.168.3.0
より低いメトリックがデフォルトパスに設定されている場合にのみ、LANで機能します。ただし、ルータはポートを転送できなくなり、eth0
LAN内でのみプロキシを使用でき、外部からアクセスすることはできません。
逆に、192.168.2.0
より低いメトリックのデフォルトパスをデフォルトパスに設定すると、インターネットからプロキシにアクセスできますが、インターフェイスを介してリソースを取得することはできませんeth1
。
たぶん、ルーティングに助けが必要かもしれません。
私は何が間違っていましたか?
よろしくお願いします。
答え1
初期コメント:
設定の次の部分でネットワーク接続が失われました。これは、リモートロケーションではなく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システムに関連する調整が必要になる場合があります。必要に応じて、特定の状況に応じてこの回答を編集できます。