Amos Jeffries wrote > On 13/07/2014 2:35 a.m., freefall12 wrote: >> this is my iptables rules >> >> iptables -A PREROUTING -p tcp -m tcp --dport 30000:60000 -j REDIRECT >> --to-ports 50000 >> >> port 5000 is the squid's listing port. >> >> What i want to do is to assign each user an unique port number and rely >> upon >> the port number in the access log for accounting. >> >> OK,the procedures will be something like this: >> >> 1,When an user register an account at the site, assign the user a random >> port number and associate it to the username in database >> 2,Open the port using iptables >> 3,use the %>lp symbol to record the connected port number in access log. >> 4,Parse the access log and insert relevant accounting data into the >> database >> 5,Automatically ban ip if port scanning is detected >> >> i'm stuck at the step 3 as i'm unable to get the connected port number >> in >> forward proxy mode >> >> Do you think this can work reliably in reality? > > > That REDIRECT is a NAT rule. It will definitely need the "intercept" > option on Squid listening port to fetch the correct client destination > details as the only thing the OS gives to Squid is its own port 50000. > Just like you found. > > Getting the traffic into Squid is not the biggest issue though. Since > you are using NAT to do it you will then face all the traffic > interception security checks which verify the TCP destination IP address > the client is going to matches the Host header rDNS records. If they > dont match, Squid will use the provided IP address directly - which in > your case will loop back at itself. > > > Alternatives: > > You could use the ext_session_acl helper. It was designed for this type > of user management. In active mode it presents a splash page for user > login before access is granted to them by configured signature for a > while. > > The newer ext_session_sql_acl helper is similar, but depends entirely on > an external identification/login system updating the SQL database which > it checks for a configured client signature. > > NP: the default signature for these session helpers in demos is usually > IP address. But there is no technical reason it has to be. > In your current plan it is the destination port, but it could just as > easily be the src-IP and User-Agent header pair for almost unique user > identification. > > > You could also re-build Squid with a larger definition for > MAXTCPLISTENPORTS in src/anyp/PortCfg.h and configuring multiple > http_port lines. But this set of ports is scanned sequentially at least > every 10ms, which could slow down your proxy noticably if the set was > particularly large. > > You could use IPv6 with EUI-64 ACL verification and require your clients > to use their SLAAC IPv6 addresses to contact you. Can be tricky to > ensure the right address is used though. > > Amos Sorry, i don't know much about iptables.what other iptables rules can i use to get the correct client destination details? The 2 alternatives you've suggested appear to be not fit for my plan. To my knowledge, ext_session_acl will still need a page for reauthentication, which doesn't work with mobile apps. is that correct? Also, changing the port range definition a larger may not be a practical solution when users grow to hundreds or thousands. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/how-can-i-get-the-localport-in-forward-proxy-mode-tp4666888p4666892.html Sent from the Squid - Users mailing list archive at Nabble.com.
