図から始めましょう。
Workstation -> TrafficShaper -> Internet
| ^
V |
LinuxProxy ---------
私のトラフィックシェーパーには、パケットを別のホスト（図のLinuxProxy）に切り替える機能があります。イーサネット宛先MACアドレスをLinuxProxyのインターフェイスに設定し、LinuxProxyがパケットを受信するネットワークにパケットを配置することによってこれを行います。 LinuxProxy はパケットに対して必要な操作を自由に実行でき、すべての応答は TrafficShaper がイーサネット宛先として設定されたネットワークに配置する必要があります。
たとえば、ワークステーションがTCP SYNをwww.google.comに送信するとします。パケットは TrafficShaper に移動し、LinuxProxy に送信します。 LinuxProxyはSYN-ACK（TrafficShaperに移動してワークステーションに戻る）で応答しようとしますが、LinuxProxyがどのイーサネット宛先MACアドレスを使用するかを知ることができないという問題があります。 TrafficShaper のデータ インターフェイスに IP バインディングがないため、トラフィックを TrafficShaper に直接送り返すパスを設定できないことを前提としています。悪いことに、TrafficShaperのMACアドレスは、要求するワークステーションによって変更されることがあります。最初に送信されたMACアドレスに応答パケットを送信するには、LinuxProxyが必要です。 TCP接続に対してこれを行う場合は、各接続のMACアドレスを覚えていて、常にそのMACに応答パケットを送信する方法はありますか？それとも、ソースIPアドレスのMACアドレスを覚えていて、そのIPに応答するときは常にそのMACを使用しますか？
tcpdumpを使用して更新します（tcpdump -n -nn -i eth1 -e -vvポート80またはarp）：
1) ワークステーションが HTTP 要求を行うときに LinuxProxy でルーティングを構成しない場合、LinuxProxy は以下を確認します。
16:02:02.382023 TrafficShaper:VirtualInterfaceX > LinuxProxy:eth1, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 122, id 30174, offset 0, flags [DF], proto TCP (6), length 52)
Workstation:IP.21875 > RandomWebserver.80: Flags [S], cksum 0x2ffb (correct), seq 1782577522, win 65535, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
ルーティングがなく、LinuxProxyがどのインターフェイスから応答するのかわからないため、SYN-ACKも表示されません。 dmesg では、次の内容も表示できます。
[177553.396852] device eth1 entered promiscuous mode
[177555.286091] IPv4: martian source LinuxProxyIP from WorkstationIP, on dev eth1
[177555.294651] ll header: 00000000: XX XX XX XX XX RT.1....5.:...
[177560.529102] device eth1 left promiscuous mode
2）LinuxProxyがどのインターフェイスに応答するのかを知るためにパスを追加しましょう（トラフィックシェーパにはIPがないので、ここにインターフェイスを入れます）。
route add default dev eth1
私のtcpdumpによると、LinuxProxyはワークステーションのIPに対してARPを試みますが、TrafficShaperはARPに応答せず、ARPを反対側に渡しません。 （とにかくワークステーションMACは役に立ちません）
16:41:14.800321 TrafficShaper:VirtualInterfaceX > LinuxProxy:eth1, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 122, id 30787, offset 0, flags [DF], proto TCP (6), length 48)
Workstation:IP.21975 > RandomWebserver.80: Flags [S], cksum 0xc8cf (correct), seq 2481765147, win 65535, options [mss 1460,nop,nop,sackOK], length 0
16:41:14.800432 LinuxProxy:eth1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has Workstation:IP tell 10.89.14.11, length 28
16:41:15.800890 LinuxProxy:eth1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has Workstation:IP tell 10.89.14.11, length 28
16:41:16.802797 LinuxProxy:eth1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has Workstation:IP tell 10.89.14.11, length 28
16:41:17.792513 TrafficShaper:VirtualInterfaceX > LinuxProxy:eth1, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 122, id 30788, offset 0, flags [DF], proto TCP (6), length 48)
Workstation:IP.21975 > RandomWebserver.80: Flags [S], cksum 0xc8cf (correct), seq 2481765147, win 65535, options [mss 1460,nop,nop,sackOK], length 0
3）TrafficShaperでMACをハードコーディングすると、これが機能することを確認するために偽のARPエントリを作成し、パスを対応するIPに変更しました。注：TrafficShaperには、それぞれ独自のMACを持つ約50の仮想インターフェイスがあり、多くのワークステーションが次のようにロードバランシングされるため、本番環境ではこれを実行できません。
ip neighbor add FAKE_IP lladdr TrafficShaper:VirtualInterfaceX dev eth1
route del default dev eth1
route add default gw FAKE_IP
これで3方向ハンドシェイクが完了しました。
16:52:17.077903 TrafficShaper:VirtualInterfaceX > LinuxProxy:eth1, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 122, id 31076, offset 0, flags [DF], proto TCP (6), length 52)
Workstation:IP.22033 > RandomWebserver.80: Flags [S], cksum 0x5a9f (correct), seq 3325648471, win 65535, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
16:52:17.078024 LinuxProxy:eth1 > TrafficShaper:VirtualInterfaceX, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
RandomWebserver.80 > Workstation:IP.22033: Flags [S.], cksum 0x99ab (incorrect -> 0x18fa), seq 1232307723, ack 3325648472, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
16:52:17.157231 TrafficShaper:VirtualInterfaceX > LinuxProxy:eth1, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 122, id 31077, offset 0, flags [DF], proto TCP (6), length 40)
Workstation:IP.22033 > RandomWebserver.80: Flags [.], cksum 0xfbdb (correct), seq 1, ack 1, win 53248, length 0
16:52:17.165426 LinuxProxy:eth1 > TrafficShaper:VirtualInterfaceX, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 20208, offset 0, flags [DF], proto TCP (6), length 40)
... extras removed ...
各ワークステーションIPがTrafficShaperの特定の仮想インターフェイスに負荷分散されることがわかります。特定のワークステーションIPに対する応答パケットをパケットを受信したMACに送り返す方法がある場合、問題は解決します。私は現在、WorkstationIP-> MACマッピングを事前に保存してからパケットを再送信するときにそのMACを検索する方法があるかどうかを調べるためにnetfilterドキュメントを見ています。