CentOSで再帰パスの検索が可能かどうかを知りたいです。シナリオは次のとおりです。
マイコンピュータには2つのネットワークカードがあります。 NIC1にはデフォルトゲートウェイがあります。 NIC2は、2つのIPサブネット（173.144.4.xおよび172.45.5.x）を介してのみ外部世界と通信できます。そしてNIC2はプロキシ（192.168.1.1）を通過しなければなりません。トラフィックに影響を与えるために、2番目のネットワークカードにこの設定を追加する方法は次のとおりです。
Destination Next-Hop
173.144.4.0/24 172.20.25.1
172.45.5.0/24 172.20.25.1
172.20.25.1 192.168.1.1
上記の最初の2つは、アクセスする必要がある外部サブネットです。 172.20.25.1 -->プロキシサーバーIP。 192.168.1.1 --> NIC2が配置されているサブネットのデフォルトゲートウェイアドレス。
[EDIT2] これは上位トポロジです。
プロキシは透明なプロキシではありません。 CentOSでは、2つの異なるゲートウェイを持つ2つのNICを持つことができないため、NIC1にのみデフォルトゲートウェイが設定されています。 NIC2は、最初の2つのルートが追加されたインターネットを介して2つのサブネットと通信する必要があります。次に、このネクストホップ（このサブネットのゲートウェイ）を使用して、プロキシサーバーに到達するかどうかを示すプロキシサーバーへの別のパスを追加します。
理論的には、マシンが外部サブネットにアクセスしようとすると、ルーティングテーブルを確認し、次ホップをプロキシIPとして表示し、ルーティングテーブルを再確認して、プロキシIPのネクストホップがデフォルトゲートウェイであることを見つけます。
これはLinuxで動作しますか？ Linuxは上記のように再帰パス検索を実行しますか？
よろしくお願いします。
答え1
ポリシールーティングにはより複雑な設定を使用できますが（使用中のように見えます）、デフォルトのバリエーションは1レベルの決定です。
オペレーティングシステムはパケットの宛先アドレスを表示し、一致するルートを見つけ、そのルートのネクストホップにパケットを送信します。
それはすべてです。
ローカルサブネットへのパスが自動的に追加されます。
これの一つの結果はみんなパスのノードには、正しいネクストホップ決定を行うのに十分なルーティング情報が必要です。これは、次のことを行う必要があることを意味します。みんなノードは、元のノードだけでなく、初心者がよく犯す間違いです。
それで、あなたが何をしようとしても（私は完全に理解していませんが）、おそらく効果がないでしょう。
また、両方のサブネットがインターネットに接続されている場合（プロキシまたはその他の手段を介して）、通常、両方のサブネットを同時に使用してインターネットにアクセスすることはできません。
答え2
これに適した 2 種類のプロキシがあります。
- 一般（明示的）プロキシ
- 透明プロキシ（強制プロキシ）
問題は、システムがゲートウェイにパケットを転送すると、パケットがどのようにルーティングされるかを判断できないことです。ゲートウェイは通常、宛先IPアドレスのみに基づいて独自のルーティング決定を行います。ルーティングテーブル。
というメカニズムがありました。ソースルーティングこれはパケットが取るべき経路を指定することができますが、それを使うべき妥当な理由はほとんどなく、多くの邪悪な行為に役立つことが証明されているので、セキュリティ上の理由から、ほとんどすべての最新のルーターとゲートウェイはすべてのソースルーティングオプションを使用します。すべてのパケットに存在するものは無視されます。セキュリティのためにルーター/ゲートウェイを監査している場合、ソースルーティングを有効にすると、ルーターが監査に失敗する可能性があります。
一般的なプロキシの使用
プロキシを使用して何かに接続する必要がある場合は、TCP / IPルーティングの観点から接続する必要があります。到着煙。その後、上位プロトコル層では、クライアントアプリケーションエージェントに聞いてください実際の目的地まで以下の接続を行ってください。
173.144.4.0/24および172.45.5.0/24ネットワークにアクセスするためにプロキシが必要な場合は、最初のステップは、これらのネットワークに接続するためにプロキシが必要であることをクライアントアプリケーションに通知することです。ルーティングテーブルだけではこれを行うことはできません。特定のネットワークに対してプロキシを使用するようにすべてのアプリケーションを構成する統一された方法はありません。各アプリケーションは独自の構成スキームを持つことができます。
クライアントアプリケーションがWebサーバーの場合は、次のものを使用できます。エージェント自動構成ファイル、しばしばwpad.datまたはと呼ばれますproxy.pac。
詳細については、次を参照してください。https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol
透明プロキシの使用
と透明プロキシ、それは状況が異なります。クライアントはターゲットに直接接続されていると思うが（必要に応じて通常どおりゲートウェイを使用して）、一部のルータ、ファイアウォール、または他のネットワークデバイスは接続をプロキシにリダイレクトします。プロキシは実際のターゲットであるふりをする必要があります。これは、TLS 接続、証明書の固定、その他の追加のセキュリティ対策の普遍性によりますます困難になっています。
プロキシがトランスペアレントプロキシの場合、エンドホストのルーティングテーブルは、173.144.4.0/24および172.45.5.0/24ネットワークに移動するすべてのトラフィックをデフォルトゲートウェイに転送するように設定する必要があります。このトラフィックが透過プロキシに移動するようにデフォルトゲートウェイを設定する必要があります。。トランスペアレントプロキシがクライアントと同じネットワークセグメントにある場合は、一部のARPトリックを使用してトラフィックをトランスペアレントプロキシに強制できますが、プロキシがゲートウェイの背後にあるため、リダイレクトを実行するようにゲートウェイを設定する必要があります。
どちらの場合も、2番目のステップは次のように設定することです。代理人宛先が173.144.4.0/24および172.45.5.0/24ネットワークにある場合にのみ、エンドホストからの要求を受け入れ、エンドホストの他の要求は拒否します。