パケットの一部をローカルアプリケーションにリダイレクトしてパケットを変更するL3スイッチを作成しています。私の目標は、以前と同じMACにさらに送信することです。
簡単な「理由」：すべてのイーサネットに接続され、ポータブルでプロキシとして機能するゼロ構成デバイス。
スイッチは、eth0とeth1の間のイーサネットブリッジ（br-lan）で構成されています。デフォルトでは、br-lanクライアントのゲートウェイはeth0にあると想定されます。
Q：パケットがeth1から来てeth0に移動し、ローカルアプリケーションにリダイレクトされるとします。アプリケーションが出力された後、元のパケットの宛先IPが変更されました。 L3はパケットを新しい宛先にルーティングしようとしますが、デフォルトのゲートウェイはありません（そしてスイッチであるためにはいけません！）。デフォルトゲートウェイのMACアドレスを知っていると仮定すると、どのようにパケットがeth0を介して特定のMACアドレスに送信されるのですか？
厳密に言えば、私はオンラインで「違法」な仕事をするつもりはありません。 eth0からパケットをエクスポートしたい「失われた」のは宛先MACだけですが、元のパケットから取得できます。宛先IPがローカルではないと確信しているため、とにかくMACアドレスを使用してデフォルトゲートウェイに送信されます。だから実行の問題です。
以下を実行して、bridge -t NAT OUTPUTでターゲットMACを変更しようとします。
ebtables -t nat -A 出力 -p ipv4 --ip-proto tcp --ip-src 192.168.1.251 -j dnat --to-dst 04:61:e7:d2:e2:09
しかし、これは役に立ちません。 （この理論をテストするために、04:61:e7:d2:e2:09がデフォルトゲートウェイMACであり、192.168.1.251がクライアントの1つであると仮定）
実際の実装はOpenWRTにあるため、利用可能なパッケージが制限される可能性があります。
この問題が発生した方法は次のとおりです。
ローカルアプリケーションに関する追加情報：ここに0.0.0.0：portにバインドされたss-redirがあります。https://github.com/shadowsocks/shadowsocks-libev
[端末]にユースケースが追加されました。
予想：通常のスイッチに3つのPCクライアントが接続されています。 [デバイス]をインポートして通常のスイッチに接続した後、PCクライアントを[デバイス]に再接続すると、PCクライアントはデバイスを設定せずに[結果]を取得します。
[結果]:
1）「外部」（3つのネットワークノードと他のすべてのノードを除く他のネットワークノード）では、すべてのユーザーは自分のIP / MACペアを維持する必要があります。 DHCPはオフィスで静的に構成されているため、IP / MACペアは変更されない可能性がありますが、管理者はそれを変更できます。そして、デバイスは手動再構成なしですべての変更を処理する必要があります。 （管理者が登録していない場合）新しいIP / MACをネットワークに表示しないでください。
2）「外部」の観点から見ると、すべてのPCクライアントは、それが何であれ（RDP、名前解決のためのNetBIOS、ファイル共有、またはローカル管理者が決定したもの）、ネットワーク上のすべてのプロトコルにアクセスできる必要があります。
3）特定の宛先のSS ipsetプロキシTCPを介している場合を除き、常にデフォルトゲートウェイを介してインターネットにアクセスする必要があります（常に同じゲートウェイを介して）。
このようなユースケースでは、デバイスが最初から既存のネットワークに関するIP / MACの知識を持ってはならないと仮定し（事務所のユーザーは自分で何も設定しないため）、スイッチのように機能する「プロキシブリッジ」を作成しようとしています。 、パケットを傍受して実行ローカルアプリケーションがリダイレクトされ、eth0（WAN）に送信されます。問題は、リダイレクトされたパケットを目的の方向に送信する必要があることです。 MAC-snat / dnatを使用して「動的自動再構成のアイデア」を調査していますが、この問題に遭遇しました。 ebtablesでデフォルトゲートウェイMAC-addrを指定できますが、パケットの生成後にeth0に移動しません。地元から目的地へ。
答え1
許してください推測するいくつかの「オリジナルミッションX」。これは元のタスクXと一致しない可能性がありますが、どのタイプの情報が必要かについてのアイデアを提供できます。
eth01）この装置は、外部スイッチの背後に4つのLANポートがあり、背面に1つのWANポートがある一般的な既製のホームルーターですeth1。 WANポートはローカルネットワークゲートウェイに接続されます。透過プロキシを使用する必要があるすべてのホストは、追加のスイッチを使用してLANポートに接続されます。 LANに接続されている他のホストやポートはありません。他のソックスエンドポイントはWAN側にあります。
この場合は、レベル2を忘れて、iptables次に説明する規則を使用してください。男 ss-radier、NATにのみ適用されますeth0。ルータはプロキシされたSOCKS要求を転送しますeth1。 NATは、eth0正しいIPを持つデバイスに応答を再送信する役割を果たします。 ARP は IP の MAC が使用されていることを確認します。
2）上記のバリエーション：LANポートに接続されている一部のホストはプロキシを使用し、一部はそうではありません。この場合、ハードウェアを詳しく見ると、設定できるスイッチチップがある可能性がありますsw-conf。 2つのLANポートがに接続され、eth0残りの2つがに接続されるように再設定しますeth2。その後、上記のように進みます。必要に応じて、ホストコンピュータを正しいLANポートに接続します。
3）デバイスは、プロキシを使用する必要があるホストと同じ内部LANセグメントに異なるSOCKSエンドポイントを持つより複雑なネットワーク構成の単純ブリッジとして使用されます。この場合、ネットワークの説明が必要です。
待って、ページ。
編集する
ユースケースを正しく読んだ場合、主な問題は、DHCPサーバーがWANポートの背後にあり、それによってIPの静的割り当てを正しく管理する必要があるため、WANポート（eth0）をLANポート（eth1）にブリッジする必要があることです。 DHCP
この場合、ブリッジを次のように構成します。「ブラルト」：LAN（eth1）に到着するパケットを除いて、すべてがブリッジされます（TCPおよび目的の宛先IP範囲内）。これらのパケットはbr-lanブリッジの内部ポートで送信されます。レイヤ3処理では、上記のようにこれを処理できます。特に、接続トラッカーはIPおよびポートごとにそれらを追跡でき、ソックスプロキシからの応答を正しいデバイスに送り返すことができます。
MAC NATは必要なく、L5を介したMACベースの接続追跡もありません。
レシピ全体を公開できるように、いくつかのネットワークネームスペースを試してみたかったのですが、残念ながら今日や今後数日以内にそうする時間はありません。
答え2
汚い解決策が見つかりました。
X コンテキストを忘れて、Y の問題を深く掘り下げると、次のようになります。
アイデアは、パケットを記録してからローカルアプリケーションにリダイレクトする前に解析できることです。 eth1からeth0までのデフォルトゲートウェイにデータパケットが到着するプロセスは次のとおりです。
(CLIENT1_SRC_IP、CLIENT1_SRC_MAC、DEST_IP_ADDR_TO_PROXY、DF_GW_MAC)
ただし、ローカルアプリケーションを通過した後、次の状態に閉じ込められます。
((!)CLIENT1_SRC_IP, (!)CLIENT1_SRC_MAC, SS_SERVER) と DF_GW_MAC が ARP 確認を進行しようとしています (SS_SERVER 隣接エントリとデフォルトゲートウェイ自体がないため、パケットがどこに行くかがないため失敗します)。
だから私はSS_SERVERがconst IPアドレスであるという事実を利用することにしました。ログのDF_GW_MACを解析し、SS_SERVER IPへの静的arpパスを追加するために使用できます。
OpenWRTユーザーのための詳細：
IP ネイバーを正しく機能させるには:
opkg アップデート
opkg インストール IP-完全
それから：
IPネイバーを追加 123.123.123.123 dev eth0 lladdr
IPパスにデフォルトのdev eth0を追加する
これで、問題Yが解決されます。それほど今は他のオプションは表示されません。