Ich versuche, Apache Trafficserver im transparenten Proxy-Modus, also im Inline-Linux-Bridge-Modus, zum Laufen zu bringen. Sie habenDokumentationwie das geht. Ich habe mein Linux-System gemäß der Dokumentation konfiguriert und hier ist meine Konfiguration:
brctl addbr br0
brctl stp br0 off
brctl addif br0 enp2s0
brctl addif br0 eno1
ifconfig enp2s0 0 0.0.0.0
ifconfig eno1 0 0.0.0.0
ifconfig br0 0.0.0.0
ifconfig br0 192.168.10.100 netmask 255.255.255.0 up
ebtables -t broute -F
ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP
ebtables -t broute -A BROUTING -p IPv4 --ip-proto tcp --ip-sport 80 -j redirect --redirect-target DROP
iptables -t mangle -A PREROUTING -i eno1 -p tcp -m tcp --dport 80 -j TPROXY --on-ip 0.0.0.0 --on-port 8080 --tproxy-mark 1/1
iptables -t mangle -A PREROUTING -i enp2s0 -p tcp -m tcp --sport 80 -j MARK --set-mark 1/1
ip rule add fwmark 1/1 table 1
ip route add local 0.0.0.0/0 dev lo table 1
Diese Konfiguration scheint jedoch nicht zu funktionieren. Laut der Konfiguration fangen die ebtables- und iptables-Regeln den für Port 80 bestimmten Datenverkehr ab und leiten ihn auf Port 8080 um. Basierend auf der Ausgabe von tcpdump scheint die ursprüngliche Anfrage an mein Linux-System zu gehen.
tshark -i eno1 port 80
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
1 0.000000000 192.168.20.200 -> 192.168.20.50 TCP 74 58986 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=345213688 TSecr=0 WS=128
2 1.002013264 192.168.20.200 -> 192.168.20.50 TCP 74 [TCP Retransmission] 58986 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=345214690 TSecr=0 WS=128
3 3.008098848 192.168.20.200 -> 192.168.20.50 TCP 74 [TCP Retransmission] 58986 > http [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=345216696 TSecr=0 WS=128
3 packets captured
Es sieht jedoch so aus, als würden die iptables/ebtables nicht den Stapel hochleiten. Ich habe den iptables-Regeln eine Ablaufverfolgung hinzugefügt und dies ist, was ich in den Protokollen sehe.
[ 5425.095575] TRACE: raw:PREROUTING:policy:2 IN=eno1 OUT= MAC=0c:c4:7a:78:97:c6:0c:c4:7a:b5:be:e9:08:00 SRC=192.168.20.200 DST=192.168.20.50 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=41608 DF PROTO=TCP SPT=58922 DPT=80 SEQ=2153102820 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A1478234C0000000001030307)
[ 5425.095620] TRACE: mangle:PREROUTING:rule:1 IN=eno1 OUT= MAC=0c:c4:7a:78:97:c6:0c:c4:7a:b5:be:e9:08:00 SRC=192.168.20.200 DST=192.168.20.50 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=41608 DF PROTO=TCP SPT=58922 DPT=80 SEQ=2153102820 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405B40402080A1478234C0000000001030307)
Die iptables-Ablaufverfolgung bestätigt, was ich in der tcpdump-Ausgabe sehe. Es sieht so aus, als ob die Anfrage an die iptables geht und dann irgendwo im Linux-IP-Stack abgelegt wird. Ich bin mir nicht sicher, wo oder wie ich das debuggen soll.
Beim Online-Lesen zu diesem Thema hat mir jemand vorgeschlagen,rp_filter. Das Ausschalten von rp_filter hat jedoch nicht geholfen. Jemand anderes hat vorgeschlagen, dass ich die IP-Weiterleitung aktivieren solle, aber das hat auch nicht geholfen. Für jede Hilfe bei der Behebung des Problems oder zumindest einige Hinweise, was oder wo als nächstes zu debuggen ist, wäre ich sehr dankbar.