Here's an example that works for me:
https://cwiki.apache.org/confluence/display/TS/Traffic+Shaping#TrafficShaping-Example

We route traffic on port 80 to Traffic Server.
We use route vs. DNAT so Traffic Server gets
the client resolved origin address.
Our proxy has one NIC.
If you only need transparency between proxy and clients (tr-in)
you can exempt proxy-origin traffic based on the IP of the proxy.
If you also need transparency between the proxy and origin (tr-full)
we exempt proxy-origin traffic based on the MAC of the proxy
(maybe there are other ways?)

I guess the wrinkle in the OP's problem is that his proxy
is connected to a switch (layer 2) that maybe lacks facilities
to discriminate proxy-origin traffic from proxy-client traffic?

*If* the switch is involved in redirecting/discriminating packets,
what about looking at the switch port where the proxy is connected?
i.e. redirect all packets to the proxy,
except packets originating from the proxy?

If OTOH the external gateway/router redirects/discriminates
(route or DNAT) and you only need proxy-client transparency (tr-in)
you can exempt proxy-origin traffic based on the IP of the proxy.

If you also need proxy-origin transparency (tr-full)
exempt proxy-origin traffic based on the MAC of the proxy
(OP says proxy and gateway are in the same VLAN).

Maybe there are other ways? (e.g. the PCP field? ToS/DiffServ field?)
I'm interested in any criticisms or improvements!

On 25/06/15 02:26 PM, Jason Strongman wrote:
"It's worth mentioning that if the OP has full control over the
clients they can set up the ATS box as the gateway and route all
traffic through it....
(using tproxy to intercept the web traffic)"

given a the OP's single interface, how would you set up your mangle
rules to mark the packets once they reach the ATS server ?

the example iptable rules in Alan's 'routed' scenario assumes two interfaces.

so now you have me curious.

On our proxy (one NIC) we use the following, is this what you mean?

ip route add local default table 1 dev lo
ip rule add fwmark 1/1 table 1

iptables -t mangle -A PREROUTING -m addrtype --dst-type LOCAL -j RETURN
iptables -t mangle -A PREROUTING -p tcp -j TPROXY --on-port 8080 --tproxy-mark 1/1

On Thu, Jun 25, 2015 at 3:51 PM, Uri Shachar <[email protected]> wrote:
It's worth mentioning that if the OP has full control over the clients they can 
set up the ATS box as the gateway and route all traffic through it....
(using tproxy to intercept the web traffic)
Another option would be WCCP -- assuming the external router has this 
capability.

           --Uri

On Thu, 25 Jun 2015 20:14:26 +0000 Alan <[email protected]> wrote:

Probably. In that case you set use iptables to do the DNAT operation
and rewrite the destination address of inbound connections to be the
address:port of an ATS proxy port.

The problem would be in the routing. You would likely need additional
support from an external router. Consider an origin server with address
A. The external router would need to route packets to A from user
agents to the ATS box, but packets to A from the ATS box out to the
internet. That is, some sort of policy or topology based routing (e.g.
if the user agents and ATS are on distinct interfaces on the external
router then you can do this easily).

On Thursday, June 25, 2015 1:59 PM, Jason Strongman
<[email protected]> wrote:

Alan,

In your transparency PDF you mention another 'transparency' approach
using NAT. I think the OP can use
his ATS server with a single interface if some inline device performs
a DNAT on the request(s) in question.
I think you mentioned this approach if one didnt want to mess with the
whole kernel TPROXY stuff.

Also per your notes, this only satisfies inbound transparency and
removes the ability for ATS to use the client resolved origin address.

On Sun, Apr 12, 2015 at 3:24 PM, Alan M. Carroll
<[email protected]<mailto:[email protected]>> wrote:
I'm not sure you can do this. The essence is packets with the same IP
addresses that need to be delivered to different VLAN ports. Let's say
your user agent is address A and the origin server is address S. When
the user agent sends a packet, it is A -> S. This is intercepted by ATS
and then when it wants to connect to the origin server it will send a
packet A -> S and this packet needs to flow out to the Internet, not be
intercepted by ATS again. If you have a router you can do this by doing
policy routing based on which interface handled the packet. With just a
switch I'm not sure you an distinguish the packets sufficiently.

I've never tried do that and I don't know anyone who has, so I have
to just guess.

Reply via email to