Hi
>> So for example I mark clients that have passed a captive portal test
>> with some mark, I need that mark copying up to requests coming from
>> squid so that I know they effectively come from a validated client
> As Amos says, this is probably the wrong way to do it. If you want to
> see an example of how I did it, then check out this page:
>
> http://andybev.com/index.php/PortalShaper
>
> I use iptables to drop (or redirect) all packets that are received from
> clients that have not passed the captive portal.
Technically I don't just track pass/fail...
Users have a choice of gateways to use the internet via (each will have
a cost). Their choice of gateway is marked on packets from their
machine, we then route through the appropriate gateway based on the
connection mark (hence why I need it passed upstream through squid)
Also we mark each connection with a unique per user mark so that
iptables can account for the traffic they consume and bill them.
Technically this could be done inside squid, but all other traffic is
accounted in iptables and there is some hairy calculations needed to
bill differently for different gateways, so I don't want to reproduce
this in multiple locations
Hence I think I need to implement the reverse of the current code?
Now, as for implementation, I don't have the code in front of me, but I
think I noticed there is a single code path to open a new upstream
connection? At present this applies a packet mark based on
tcp_outgoing_mark. Is the client connection information available at
this point, so that I could mark the connection at this point based on
the client connection mark?
However, I think squid uses persistent connections to upstream? (I will
always have another proxy as my upstream). If so then actually I need
to reset the mark for each request? Where would be the correct location
to put the marking code in this case, ie I guess where the packet is
sent to the upstream socket? (I guess I need to be careful about
pipelining also?)
Thanks for your thoughts
Ed W
Received on Thu Mar 28 2013 - 22:52:38 MDT
This archive was generated by hypermail 2.2.0 : Fri Mar 29 2013 - 12:00:06 MDT