I don't think this went through so I'm sending it again. These are slides from an ApacheCon talk I gave about transparency. Among the details is a nice check list of things to check when it doesn't work.
https://www.dropbox.com/sh/h7erczfbt8ug8kn/AADJAqNz_xizurIHE6hx8Q8ka?preview=ApacheCon-2013.pdf On Mon, Jun 24, 2019 at 12:45 PM Dk Jack <dnj0...@gmail.com> wrote: > Ah! Yeah, I think you are taking about reverse path filter. I remember > checking for it. But I’ll check again. > > Dk. > > > On Jun 24, 2019, at 8:31 AM, SUSAN HINRICHS <shinr...@ieee.org> wrote: > > > > Rp_filter is a reverse proxy filter. If enabled, which it is by default, > it > > will drop packets that show up on unexpected interfaces. May not be an > > issue in the bridge case, but something to look into. > > > >> On Sun, Jun 23, 2019, 11:54 PM Dk Jack <dnj0...@gmail.com> wrote: > >> > >> Hi Susan, > >> yes, I've enabled ip_forward. What's an rp_filter? Haven't checked > >> /var/log/messages... > >> > >> Bhasker. > >> > >> > >>> On Sun, Jun 23, 2019 at 8:01 PM SUSAN HINRICHS <shinr...@ieee.org> > wrote: > >>> > >>> It seems like it takes me a couple days of fiddling each time I have to > >> set > >>> up transparent mode. > >>> > >>> Have you enabled ip_forward? Have you disabled rp_filter? Are you > >> seeing > >>> Martian messages in your /bar/log/messages? > >>> > >>>> On Sun, Jun 23, 2019, 7:23 PM Dk Jack <dnj0...@gmail.com> wrote: > >>>> > >>>> Hi, > >>>> I am trying to test ATS in transparent proxy mode. I am using the > >> inline > >>>> linux bridge mode. It doesn't seem to work even though I made the > >> changes > >>>> as specified in the ATS documentation. My configuration is shown > below. > >>> The > >>>> request seems to come to the bridge device, however, the packet is not > >>>> making up the stack to ATS. The device receive the TCP SYN, however, > >> it's > >>>> not getting forwarded up the stack to ATS. Am I doing something wrong > >> in > >>> my > >>>> configuration or otherwise? Thanks for the help... > >>>> > >>>> Dk. > >>>> > >>>> > >>>> ----- tshark output ---- > >>>> > >>>> [root@testserver03 ~]# tshark -i eth1 port 80 -nn > >>>> Running as user "root" and group "root". This could be dangerous. > >>>> Capturing on 'eth1' > >>>> 1 0.000000000 192.168.20.200 -> 192.168.20.50 TCP 74 54754 > 80 [SYN] > >>>> Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=253488830 TSecr=0 > >> WS=128 > >>>> 2 1.001891063 192.168.20.200 -> 192.168.20.50 TCP 74 [TCP > >>> Retransmission] > >>>> 54754 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 > >>> TSval=253489832 > >>>> TSecr=0 WS=128 > >>>> 3 3.005951357 192.168.20.200 -> 192.168.20.50 TCP 74 [TCP > >>> Retransmission] > >>>> 54754 > 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 > >>> TSval=253491836 > >>>> TSecr=0 WS=128 > >>>> > >>>> ----- Config ----- > >>>> brctl addbr br0 > >>>> brctl stp br0 off > >>>> brctl addif br0 eth1 > >>>> brctl addif br0 eth2 > >>>> ifconfig br0 0.0.0.0 > >>>> ifconfig eth1 0 0.0.0.0 > >>>> ifconfig eth2 0 0.0.0.0 > >>>> ifconfig br0 192.168.10.100 netmask 255.255.255.0 up > >>>> ip route add default via 192.168.10.200 > >>>> 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 eth1 -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 eth2 -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 > >>>> > >>> > >> >
